理解確認：クロスアカウントアクセス設計

アカウント Aの運用チームがアカウント B内のEC2、S3、CloudWatchなど複数サービスを管理する。アカウント B側で運用権限を一元管理したい。最も適切な基本設計はどれか。

アカウント Aのロールからアカウント BのProductionReadRoleを引き受けたい。アカウント Bの信頼ポリシーはアカウント Aのロールを既に信頼しているが、AssumeRoleがアクセス拒否になる。最初に確認すべきものはどれか。

アカウント Aのプリンシパルには対象ロールへのsts:AssumeRoleが許可されている。しかしアカウント Bのロールはアカウント Aを信頼していない。結果として正しいものはどれか。

クロスアカウントロールの信頼ポリシーではアカウント Aを信頼している。ロール権限ポリシーはdynamodb:GetItemだけを許可している。アカウント Aのプリンシパルがロールを正常に引き受けた後、ec2:TerminateInstancesを実行した。結果として最も適切なのはどれか。

アカウント Aのアプリケーションから、アカウント Bの特定S3 バケットだけを読み取らせたい。対象側アイデンティティへ切り替える必要はなく、S3 バケットポリシーを利用できる。最も直接的な設計はどれか。

アカウント Aのロールがアカウント BのSQS キューへ直接クロスアカウントアクセスする。アカウント Bのキューポリシーはアカウント Aのロールを許可しているが、アカウント Aのロールには対象キューへの操作権限がない。最も適切な判断はどれか。

アカウント Aのプリンシパルがアカウント Bのロールを正常に引き受けた。次にAWS STSから受け取るものの説明として最も適切なのはどれか。

要件は「アカウント Aのアプリケーションからアカウント Bの複数リソースを操作する。ただし対象サービスの一部はリソースベースのポリシーに対応していない」である。最も適切な設計はどれか。

ロール信頼ポリシーに次のプリンシパルが指定されている。
arn:aws:iam::111111111111:root
最も正しい解釈はどれか。

クロスアカウントIAMロールとリソースベースのポリシーの使い分けについて正しいものを3つ選択してください。

外部SaaS 提供側が多数の顧客 AWSアカウントを監視している。自社アカウントにも提供側が引き受けるIAMロールを作成するが、別顧客が自社ロール ARNを提供側へ指定することで、自社リソースへ誤ってアクセスされることを防ぎたい。

最も適切な設計はどれか。

アカウント Aのロールがアカウント Bの対象ロールを引き受けられるよう、送信元側の sts:AssumeRole、対象側信頼ポリシー、対象ロール権限ポリシーはすべて許可になっている。しかしOrganizationsのSCPが対象アクションを明示的に拒否している。最終結果として最も適切なのはどれか。