AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

A. 管理アカウントに発行専用の IAM ロールを作成して両方のポリシーをアタッチし、全子会社アカウントとのクロスアカウント信頼関係を設定した上で、認証情報の引き受けを IAM Identity Center に委任する

IAM Identity Center は、許可セットを割り当てた各アカウントに専用の IAM ロールを自動的に作成・管理します。管理者が自前でクロスアカウントの信頼関係を組んだり、引き受けを委任したりする必要はありません。
そもそも失敗の原因は参照先のカスタマー管理ポリシーがメンバーアカウントに存在しないことであり、管理アカウント側にロールを作っても解消しません。
Identity Center の仕組みを自前実装で置き換える、方向性そのものが誤った案です。

正解

B. 割り当て予定の全ての子会社アカウントに、名前とパスが一致するカスタマー管理ポリシーをあらかじめ作成しておく

正解です。許可セットにカスタマー管理ポリシーを含める場合、Identity Center はそのポリシーをメンバーアカウントに作成してくれません。管理者が割り当て先の各 AWS アカウントに、同じ名前（およびパス）の IAM ポリシーをあらかじめ作成しておく必要があります。
Identity Center は許可セットのプロビジョニング時に自動作成した IAM ロールへその名前のポリシーをアタッチしようとするため、1 つでも存在しないアカウントがあると割り当てが失敗します。
18 アカウントに配布する運用では、CloudFormation StackSets などで同名・同パスのポリシーを一括展開するのが定石です。

C. 管理アカウントで設定している SCP（サービスコントロールポリシー）が許可セットの割り当てをブロックしていないかを確認し、必要であれば SCP の制限を緩和する

SCP はアカウント内のプリンシパルが行使できる権限の上限を定めるガードレールであり、許可セットの割り当て（プロビジョニング）操作そのものをブロックするものではありません。
プロビジョニングは Identity Center のサービスにリンクされたロールによって行われ、SCP はサービスにリンクされたロールには影響しません。また管理アカウントは SCP の制限を受けません。
SCP が影響するのは「割り当て後にユーザーが実際に操作できる範囲」であって、今回の割り当て失敗の原因ではありません。

D. 許可セットの変更をいったん取りやめ、対象ユーザーに直接付与されている既存のアクセス許可ロールに、AWS 管理ポリシーとカスタマー管理ポリシーの両方を個別にアタッチする

Identity Center がプロビジョニングした IAM ロールに手作業でポリシーをアタッチしても、次回のプロビジョニングで許可セットの定義どおりに上書き（同期）されてしまい、変更は維持されません。
18 アカウント分を手で当て直す運用は、Identity Center で権限を一元管理するという前提そのものを崩します。
問題の原因（参照先ポリシーの不在）にも触れておらず、回避策としても不適切です。

構成図

許可セット（管理アカウント）
  AWS 管理ポリシー ＋ カスタマー管理ポリシー名
    │ 割り当て・プロビジョニング
    ▼
各子会社アカウント（18 アカウント）
  IAM ロール（自動作成）──名前とパスで参照──▶ カスタマー管理ポリシー
                                            （同名・同パスで事前作成が必須。
                                              無いアカウントがあると割り当て失敗）

正解への思考ルート

問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。

要件	判断ポイント
許可セットに AWS 管理ポリシーとカスタマー管理ポリシーの両方を含めた	AWS 管理ポリシーは全アカウント共通で存在するが、カスタマー管理ポリシーはアカウントごとに実体が必要 →選択肢（B）は候補
複数の子会社アカウントへの割り当て処理が失敗した	Identity Center は参照先のポリシーを作成しない。同じ名前とパスのポリシーが無いアカウントでプロビジョニングが失敗する →選択肢（B）が正解
IAM Identity Center がアカウント側のロールをどう作るか	割り当て先アカウントのIAM ロールは Identity Center が自動作成・管理する。自前のクロスアカウントロールは不要 →選択肢（A）を消す
SCP は割り当て処理を妨げるか	SCP は権限の上限を定めるもので、プロビジョニングを担うサービスにリンクされたロールには影響しない →選択肢（C）を消す
権限を一元管理したいという前提	プロビジョニング済みロールへの手動アタッチは次の同期で上書きされるうえ、18 アカウント分の手作業になる →選択肢（D）を消す

ひっかけポイント

• 「AWS 管理ポリシーとカスタマー管理ポリシーの両方を含めた」という記述が原因の伏線。失敗するのはカスタマー管理ポリシー側だけ（AWS 管理ポリシーはどのアカウントにも存在する）と切り分けられるかが分かれ目
• 選択肢 C の SCP は「Organizations で何かがブロックされている」という定番の連想を突く罠。SCP は割り当て処理ではなく、割り当て後の実効権限に効く
• Identity Center が各アカウントに IAM ロールを自動作成することは知られていても、参照するカスタマー管理ポリシーまでは作らないという非対称性が本問の核心
• 名前だけでなくパスも一致させる必要がある。カスタムパス（例 /security/）を付けたポリシーを一部のアカウントでルートパスに作ると、同じ理由で失敗する

出題バリエーション

同じ知識が本番では条件を変えて出題されます。

問題文がこう変わったら	正解はこう変わる
「許可セットに AWS 管理ポリシーだけを含めた」	事前作成は不要で割り当てはそのまま成功する。原因の切り分け問題に変わる。
「18 アカウントに同名ポリシーを効率よく展開したい」	CloudFormation StackSets による一括デプロイが正解軸に。
「許可セットにアタッチできる管理ポリシーの数の上限に達した」	インラインポリシーへの集約やカスタマー管理ポリシーの利用が正解軸に（許可セットあたりの上限が論点）。
「許可セットで付与できる権限の上限そのものを制限したい」	許可セットのアクセス許可の境界（これも各アカウントに同名で事前作成が必要）や SCP が正解軸に。
「許可セットを更新したのに権限が反映されない」	割り当て済みアカウントへの再プロビジョニングが必要、という運用が正解軸に。

関連サービスの解説

AWS IAM Identity Center (AWS Single Sign-On)
AWS Organizations

リファレンス

この問題を解くために必要な知識を扱う公式ドキュメントです。

知識項目	公式ドキュメント
許可セットのカスタマー管理ポリシーを各アカウントに事前作成する要件	カスタマー管理ポリシーとアクセス許可の境界