WEB問題集
ある企業は、Amazon Linux を実行する Amazon EC2 インスタンス群を AWS Systems Manager で管理しています。これらのインスタンスにはすべて SSM Agent がインストールされています。すべての EC2 インスタンスは、インスタンスメタデータサービス バージョン2（IMDSv2）を使用するように構成されており、同じ AWS アカウントと AWS リージョンで稼働しています。会社のポリシーでは、開発者は Amazon Linux のみを使用する必要があります。
企業は、新しい EC2 インスタンスが作成されたときに、自動的に Systems Manager によって管理されるようにしたいと考えています。 次のうち、運用上の効率が最も高い解決策はどれですか？正解：A
この問題では「新しい EC2 インスタンスが作成されたら自動的に Systems Manager で管理される」ことが求められています。つまり、SSM Agent と必要な IAM ロールが確実に設定されるようにする必要があります。
選択肢Aでは、AWS Systems Manager のdefault-ec2-instance-management-role サービス設定を使用しています。これは、デフォルトで新しいインスタンスにアタッチされるロールを指定できる仕組みであり、運用負荷を最小化できます。Amazon Linux には SSM Agent が標準で含まれているため、追加でインストールする必要もありません。そのため、この方法が最も効率的でシンプルです。
AmazonSSMManagedEC2InstanceDefaultPolicy を含む IAM ロールを作成し、Systems Manager サービス設定に紐づけることで、以降に起動するインスタンスには自動的にこのロールがアタッチされます。Amazon Linux には SSM Agent がプリインストール済みなので、追加設定は不要です。運用上の効率が最も高いアプローチです。 ある企業は、AWS Lambda 関数に対して Amazon S3 イベントソースを設定しました。企業は、新しいオブジェクトが作成されたとき、または既存のオブジェクトが変更されたときに、その特定の S3 バケットで Lambda 関数が実行されるようにする必要があります。
Lambda 関数は、受信イベントの S3 バケット名と S3 オブジェクトキーを使用して、新規または変更されたオブジェクトの内容を読み取ります。その後、Lambda 関数は内容を解析し、解析結果を Amazon DynamoDB テーブルに保存します。 Lambda 関数の実行ロールには、S3 バケットから読み取り、DynamoDB テーブルに書き込む権限が付与されています。しかしテスト中に、DevOps エンジニアは、オブジェクトが S3 バケットに追加されたとき、または既存のオブジェクトが変更されたときに、Lambda 関数が実行されないことを発見しました。 この問題を解決できるソリューションはどれですか？正解：B
このシナリオでは、Lambda 関数の実行ロールには S3 読み取り権限と DynamoDB 書き込み権限があります。しかし Lambda が「S3 イベントによって呼び出されない」ことが問題です。つまり、S3 → Lambda の呼び出し権限が不足しています。
AWS Lambda では、外部サービス（今回の場合は Amazon S3）が Lambda 関数を呼び出すために、Lambda 関数側にリソースベースポリシーを設定する必要があります。このリソースポリシーにより、S3 が Lambda 関数を呼び出すことを許可できます。 したがって、最も適切な解決策は B: Lambda 関数にリソースポリシーを追加することです。 Lambda 関数のリソースポリシーを作成し、S3 に呼び出しを許可することで、S3 イベント通知が Lambda を正常にトリガーできるようになります。これが正しい解決策です。ある企業は、AWS Organizations 内に AWS Control Tower を設定しました。企業は既存のすべての AWS アカウントを AWS Control Tower に登録しました。企業は、新しい AWS アカウントが自動的に AWS Control Tower に登録されるようにしたいと考えています。
企業にはすでに新しい AWS アカウントを作成し、アカウント作成の一環として必要なアクションを実行する AWS Step Functions ワークフローがあります。この Step Functions ワークフローは、AWS Control Tower が存在する同じ AWS アカウントに定義されています。 この要件を満たすために、Step Functions ワークフローに追加すべき手順の組み合わせはどれですか？（2つ選択してください）（2つ選択）
正解：C, D
新しい AWS アカウントを Control Tower に登録するには、2つの重要な要素が必要です。
- Service Catalog の「AWS Control Tower Account Factory」プロビジョニング製品を利用すること
Control Tower は内部的に AWS Service Catalog を使用して新しいアカウントを作成・管理します。そのため、Step Functions ワークフローから直接
ProvisionProductAPI を呼び出して、アカウントを Account Factory 経由で作成する必要があります。これにより、新しいアカウントは自動的に Control Tower 管理下に置かれます。 - 新しいアカウントに AWSControlTowerExecution ロールを作成すること
Control Tower の管理者アカウントが新しいアカウントを管理できるようにするためには、必ず
AWSControlTowerExecutionIAM ロールを作成する必要があります。このロールは Control Tower がクロスアカウントで設定を適用するための基本要件です。
ある企業の Web アプリケーションは、Application Load Balancer（ALB）を使用して、3つのアベイラビリティーゾーンにまたがる Amazon EC2 インスタンスへトラフィックを振り分けています。 企業は新しいバージョンのアプリケーションをテスト目的で1つのアベイラビリティーゾーンにデプロイしました。もしアプリケーションに問題が見つかった場合、ロールバックが完了するまで、その影響を受けたアベイラビリティーゾーンにトラフィックを送らないようにしたいと考えています。アプリケーションはロールバック中も可用であり、「静的安定性（static stability）」を維持しなければなりません。
次のうち、運用上の効率が最も高い解決策はどれですか？正解：A
このシナリオでは「影響を受けた AZ へのトラフィックを即座に遮断したい」「ロールバック中もアプリケーションを安定して提供したい」という要件があります。 Zonal Shift（AWS Route 53 Application Recovery Controller の機能） を利用すれば、指定した AZ へのトラフィックを ALB レベルでコントロールし、一時的に完全に隔離することができます。
ただし、ALB の クロスゾーン負荷分散 が有効になっていると、リクエストが残りの AZ にルーティングされる過程で、依然として影響を受けた AZ 内のターゲットにトラフィックが流れる可能性があります。 このため、クロスゾーン負荷分散を無効化し、ALB が各 AZ 内でのみリクエストを処理するように構成しておくことで、Zonal Shift が確実に効力を発揮します。 これにより、影響を受けた AZ を切り離しても、残りの AZ にデプロイされたターゲットだけで安定的にリクエストを処理できるようになり、静的安定性を維持したままロールバックを進めることができます。ある企業には複数の AWS アカウントがあります。各アカウントで Amazon Connect インスタンスが稼働しています。イベント処理には、各アカウントの Amazon EventBridge 既定のイベントバス（default event bus）を使用しています。
DevOps チームは、すべての Amazon Connect のイベントを 1 つの DevOps アカウントで受け取りたいと考えています。 この要件を満たすソリューションはどれですか？正解：C
複数アカウントのイベントを 1 つのアカウントで集中受信するには、受信側（ハブ）となる DevOps アカウントのイベントバスにリソースベースポリシーを設定して、送信元アカウントを許可し、送信元（各アカウント）側に EventBridge ルールを作って、ターゲットとして “DevOps アカウントの既定のイベントバス” を指定します。これが EventBridge のクロスアカウント配信の標準的・推奨的なパターンです。既定バス間のクロスアカウント転送は、ターゲットとして「別アカウントのイベントバス」を指定することで実現します。受信側のバスに対するポリシー許可と、送信側のルール設定という二段構えが要点です。
DevOps アカウントの既定バスにリソースベースポリシーで送信元アカウントを許可し、各送信元アカウントで Amazon Connect のイベントに一致するルールを作ってターゲットに DevOps の既定バスを指定します。これにより全 Connect イベントが DevOps アカウントに集約されます。構成がシンプルで運用効率が最も高い方法です。