グローバル展開する製造企業が AWS Organizations を使用して以下の構造でアカウントを管理しています。Root → 本番 OU（30 アカウント）、開発 OU（20 アカウント）、共有サービス OU（5 アカウント）。同社のセキュリティチームは以下の問題を発見しました。 ①開発者が本番アカウントで意図せず高額なリソース（例：p3.16xlarge インスタンス）を起動している。 ②一部のアカウントで us-east-1 以外のリージョンにリソースが作成されている（コンプライアンス違反）。 ③開発 OU のアカウントが本番データベースに直接アクセスしている。 ④ルートユーザーが MFA なしで使用されているアカウントが存在する。これらすべての問題を解決するために SCP を設計する場合、最も効率的なアプローチはどれですか？（2つ選択）
SCP（サービスコントロールポリシー）は OU 単位で対象を絞って適用することが効率的です。SCPはIAM APIレベルで権限の上限を定義するものであり、ネットワーク層のCIDRベース接続制御（DBへのTCP接続拒否など）はSCPの対象外です。クロスアカウントアクセスの制御には aws:ResourceAccount 条件でAPI呼び出し先アカウントを限定します。 正解②の解説：本番 OU のリージョン制限は AllowOnlyApprovedRegions SCP で実装し、IAM・STS・CloudFront などグローバルサービスを NotAction または StringNotEquals + aws:RequestedRegion で除外します。開発 OU から本番 DB への不正アクセス（問題③）は、aws:ResourceAccount 条件で本番アカウント ID 宛の RDS・Secrets Manager API 呼び出しを拒否することで防止します。 正解④の解説：問題①の本番アカウントでの高額インスタンス起動防止には、本番 OU に DenyExpensiveInstancesInProd SCP を適用し、ec2:RunInstances に StringNotEquals + ec2:InstanceType 条件で許可リスト外のインスタンスタイプを拒否します。問題②のリージョン制限は本番・開発両 OU に適用します。 選択肢Aは Root 全体への一律適用は共有サービス OU など管理不要なアカウントにも影響が及び過剰制限になりやすい。また aws:MultiFactorAuthPresent 条件は管理アカウントの root ユーザーには適用されません。 選択肢Cはaws:PrincipalType が Root かつ aws:MultiFactorAuthPresent が false の場合に拒否する構成はメンバーアカウントの root ユーザーには技術的に機能しますが、問題①② ③の解決策にはなりません。問題④（ルートユーザーMFA）の恒久対策は AWS Organizations の「Centralized root access」機能や IAM Identity Center の利用が推奨されます。 選択肢Eは Config + Lambda による事後検出・自動削除は、リソース作成後の対応であるため予防的制御として不十分であり、意図しない削除による業務影響リスクも伴います。