障害時にAWSに切り替えるには、通常はDirect Connectでつないでいるのが一般的な構成かと思います。

たしかに、社内システムなどの切り替えはDirect Connectで繋ぐのが一般的な構成だと思います。

設問のシステムは「ある会社はオンプレミスでWebアプリケーションを運用している。」なので、Webアプリケーション＝インターネット（外部）からのアクセスがあるシステムです。
なので、今回切り替え対象となるWebアプリケーションは、社内からプライベートでアクセスされるものではなく、インターネットからパブリックにアクセスされるものなので、Direct Connectを使用しません。

EC2は起動している状態でなければならないと判断しました。

起動しっぱなしが一番切り替えが速いというのも分かるのですが、EC2の状態の選択肢は
・ALB配下のEC2インスタンスを停止状態にしておき、障害発生時に起動する
・障害発生時にAWS CloudFormationテンプレートを実行して、ALBとEC2インスタンスを作成する
しかないので、作成して停止しておく方が速いという考え方になると思います。（障害時しか使用しないのに、ずっと起動し続けるのも結構料金がかかりますし、EC2の起動は数分以内に完了するので）

設問からは

同社はデータセンターの自然災害時の影響を考慮して、AWSを利用した災害復旧（DR：Disaster Recovery）を計画している。

のですから、仮にデータ同期やオンプレミスのシステム停止時切り替えのためにDirectConnectで接続していたとしても、そもそもデータセンターが自然災害により使用不可能な（DirectConnectエンドポイントが機能しない）状態を想定しているので

障害時にAWSに切り替えるには、通常はDirect Connectでつないでいるのが一般的な構成かと思います。

だと、「どこのエンドポイントからAWSのバックアップ環境にDirectConnect接続するの？」って観点が不足しているのではないかなと思います。

この問題ですが、Route 53でフェイルオーバーが発生した場合、
停止状態のEC2インスタンスに向いてしまい、結局何も応答がない状態になってしまわないのでしょうか。
それともフェイルオーバー発生時にRoute 53が自動で停止中のEC2インスタンスを起動してくれるのでしょうか。