Question#27(SAP-C02)
ソリューションアーキテクトは、既存の手動で作成された非本番 AWS 環境から AWS CloudFormation テンプレートを作成しています。この CloudFormation テンプレートは必要に応じて破棄して再作成できます。環境には Amazon EC2 インスタンスがあります。EC2 インスタンスは インスタンスプロファイルを持っており、そのインスタンスプロファイルを使用して親アカウントのロールを引き受ける（AssumeRole）ことができます。
ソリューションアーキテクトは、そのロールを CloudFormation テンプレートで再作成し、同じロール名を使用しました。しかし CloudFormation テンプレートを子アカウントで起動すると、EC2 インスタンスが親アカウントのロールを権限不足のため引き受けられなくなりました。 この問題を解決するために、ソリューションアーキテクトはどうすべきですか？正解：A
問題文では次の状況が起きています。
- 子アカウントに存在していた IAM ロールを CloudFormation で再作成した。
- ロール名は同じでも、IAM ロールの ARN は一意の ID を含むため別物になる。
例：
- 再作成前：
arn:aws:iam::123456789012:role/MyRole - 再作成後：
arn:aws:iam::123456789012:role/MyRole（見た目は同じだが内部的には別リソース ID）
- 再作成前：
- 親アカウントの IAM ロールには「どのプリンシパル（誰）が AssumeRole できるか」を定義した 信頼ポリシー（trust policy） がある。
- 再作成によって ARN が変わったため、親アカウントの信頼ポリシーが子アカウントの新しいロールを信頼していない → EC2 インスタンスが AssumeRole できなくなった。
sts:AssumeRole を許可する対象 ARN を正しいものに直す」という解決策です。- つまり、子アカウントで再作成された 新しいロール ARN をポリシーに反映することです。
- これにより、EC2 インスタンスのインスタンスプロファイル経由で
sts:AssumeRoleを呼び出した際に、親アカウントが「このロールを信頼している」と認識でき、引き受け処理が成功します。 - これは 必要最小限の権限付与（Principle of Least Privilege） に基づいたベストプラクティスです。
コメント