理解確認：Centralized MonitoringとProactive Recovery

複数AWSアカウントのアプリケーションについて、送信元アカウントのCloudWatch メトリクスを中央運用アカウントから監視し、中央でアラーム判定も行いたい。アプリケーションは同一リージョンにある。最も適切な候補はどれか。

CloudWatch クロスアカウントオブザーバビリティを1つのリージョンで構成した。別リージョンにも同じアプリケーションがある。最も正しい評価はどれか。

CloudWatch アラームを自動化された復旧のトリガーとして設計するとき、適切な判断を3つ選択してください。

正常時も1分ごとにハートビート メトリクスを送るアプリケーションがある。メトリクスがまったく届かなくなること自体を障害シグナルとして扱いたい。最も適切な設計はどれか。

デプロイ中には想定内のエラー率上昇があるが、通常運用中の同じエラー率上昇では自動化された復旧を開始したい。最も適切な候補はどれか。

単一CloudWatch アラームがOKからALARMへ遷移したときにLambdaを1回起動する単純な復旧要件である。ALARM状態が続く間に同じLambdaを毎分再実行する必要はない。最も適切な設計はどれか。

CloudWatch アラームとAmazon EventBridgeを利用した復旧ワークフローについて正しいものを3つ選択してください。

CloudWatch アラームの状態変更をEventBridge ルールが受信し、復旧対象を呼び出した。最も正しい説明はどれか。

AWS Organizations配下の多数アカウントで、スケジュールされた変更や必要なアクションを中央運用から把握し、必要なワークフローへ接続したい。最も適切な候補はどれか。

自動化された復旧ワークフローを安全に設計するために適切なものを4つ選択してください。

監視アカウントから送信元アカウントのCloudWatch メトリクスは確認できるが、送信元リソースを再起動する自動化がAccessDeniedになる。最も適切な評価はどれか。

復旧自動化がEC2インスタンスを置換し、自動化実行自体は成功になった。しかしアプリケーションエラー率は改善していない。最も適切な判断はどれか。

20個のAWSアカウントを中央監視している。ワークロード特性の違いでアラームしきい値は異なるが、運用では重要の意味を「重大なビジネス影響」に揃えたい。また複数アカウントのシグナルを複合アラームへまとめたい。最も適切な設計はどれか。

複数アカウントの重要サービスについて、障害を中央検知しつつローカル自己修復も活かして安全に復旧したい。適切な設計を4つ選択してください。

重要アプリケーションで、ユーザーから認識可能な停止後だけでなくキャパシティ低下やAWS スケジュールされた変更も早期に検知して復旧を開始したい。ただし一時的なメトリクス 急増による不要な復旧は避けたい。最も適切なアーキテクチャはどれか。