ある金融系企業のプラットフォームチームは、AWS Organizations 配下の複数の開発アカウントで、各アプリケーションチームの開発者が自分たちで IAM ロール（Lambda 実行ロール等）を作成・管理できるようにしたい。一方でガバナンス部門は『開発者が作成するロールには、組織が定義した上限を超える権限（例：iam:* や organizations:* の付与、付与済み Permission Boundary の除去）を絶対に持たせてはならない』『開発者自身が自分の権限を昇格できてはならない』と要求している。開発者のセルフサービス性を維持しつつ、最小の運用負荷でこれを予防的に強制する設計はどれか。
権限の委任（開発者が自分でロールを作成）と昇格防止を両立する標準パターンが Permission Boundary である。 開発者に iam:CreateRole を許可しつつ、iam:PermissionsBoundary 条件キーで特定の境界ポリシーのアタッチを必須化すれば、作成されるロールの実効権限は常に境界以下に制限される。 さらに境界の付け替え・削除（iam:DeleteRolePermissionsBoundary 等）と自身のポリシー変更を Deny することで昇格も防げる。これは予防的かつセルフサービスを維持できる。 選択肢1は iam:CreateRole を全面 Deny するためセルフサービス要件を満たせず、手動払い出しは運用負荷も大きい。 選択肢2は AdministratorAccess を与える時点で昇格を許し、Config による検出は事後的（発見的）で予防にならない。 選択肢3の permission set/ABAC は開発者がログインに使う権限を制御するもので、開発者が新規作成するロールの上限を強制する仕組みではない。