【正解】A
【0からの解説】
① 前提知識・
リソース階層: Google Cloud のリソースは「組織 → フォルダ → プロジェクト → 各リソース」という木構造で管理します。上位のノードに設定した
IAM ポリシーと
組織のポリシーは下位に
継承されるため、フォルダ単位でまとめて統制をかけられます。
・
組織のポリシー（Organization Policy Service）: 「何をしてよいか」を制約（constraint）で制限する仕組みです。
リソース ロケーションの制約（constraints/gcp.resourceLocations）を使うと、リソースを作成できるロケーションを us-central1 や europe-west2 などに限定できます。
・
フォルダは部門や環境の境界を表現するのに使い、
プロジェクトは課金・API 有効化・IAM の基本的な分離単位です。本番と開発を別プロジェクトに分けるのが推奨のやり方です。
・
roles/viewer（閲覧者）は、ほぼすべてのリソースを読み取り専用で参照できる基本ロールです。一方
roles/browser（ブラウザ）は、フォルダやプロジェクトなどの階層構造を参照できるだけで、プロジェクト内のリソースの中身は閲覧できません。
② 要件と制約語の整理・Finance: ロケーション制限＋finance-admins グループによる厳格なアクセス管理。
・Marketing: 本番 / 開発の分離と、環境ごとに異なる管理チーム。
・R&D: 柔軟性と、本番からの完全な分離。
・コンプライアンス チーム:
全社のすべてのリソースへの
読み取り専用アクセス。
・「
大規模に適用」「
Well-Architected Framework に従う」「
適切な自律性」→ 継承を活かした一元管理と、部門単位の委任を両立する階層が求められます。
③ 正解 A が要件をどう満たすか・単一の組織の下に
部門ごとのフォルダを作ることで、部門単位で IAM と組織のポリシーを設定・継承できます。
・
Finance フォルダにリソース ロケーションの制約を適用すれば、配下の既存・将来のすべてのプロジェクトに自動的に適用されます。フォルダに finance-admins グループのロールを付与すれば、アクセス管理も一元化できます。
・
Marketing フォルダ内で mktg-prod と mktg-dev を別プロジェクトにすることで、環境ごとに異なるチームへ別々の IAM 権限を付与できます。
・
R&D フォルダは他部門のフォルダと分かれているため、本番システムに影響を与えずに、フォルダ内で自由に実験できます（R&D の管理者にフォルダ内の権限を委任すれば自律性も確保できます）。
・コンプライアンス チームに
組織レベルで閲覧ロールを 1 回付与するだけで、継承により全社のすべてのリソースを読み取り専用で参照できます。なお実務では、最小権限の観点から基本ロールより用途に合った事前定義ロール（例: セキュリティ審査担当者ロールや Cloud Asset 閲覧者ロール）の利用が推奨されますが、選択肢の中では A が要件をすべて満たす唯一の設計です。
【誤りの選択肢】
B：すべてのプロジェクトを組織直下に並べると、部門単位で IAM や組織のポリシーを継承させる仕組みがなく、プロジェクトが増えるたびに個別設定が必要になるため「大規模に適用」できません。ネットワーク タグやサービス アカウントはファイアウォール ルールの適用対象を選ぶ仕組みであり、部門間のガバナンス境界（IAM・ポリシー・課金の分離）にはなりません。
C：部門ごとに別の組織を作ると、組織のポリシーや IAM を全社で一元的に管理できなくなり、監査やセキュリティ統制が分断されます。コンプライアンス チームへのアクセス付与なども組織ごとに個別管理が必要で、管理負荷が増えます。Google は通常、1 つの組織の下でフォルダによって部門を分ける構成を推奨しています。
D：部門ごとに 1 プロジェクトでは、Marketing の本番と開発を分離できず、環境ごとに異なるチームに管理させることもできません。R&D の分離もプロジェクト単位に限られ、組織のポリシーをフォルダ単位で継承させる利点も得られません。さらに roles/browser は階層構造を参照できるだけでリソースの中身を閲覧できないため、監査要件を満たさず、プロジェクトごとの個別付与はスケールもしません。
【参考】
リソース階層について | Resource ManagerGoogle Cloud ランディング ゾーンのリソース階層を決定するリソース階層を使用したアクセス制御 | Identity and Access Management (IAM)