GCP PDOのサンプル問題（本番形式・解説付き）

解説

本文は DevOps Engineer 試験で推される既定を application-centric と環境別の組み合わせ、すなわち Org → Folder(部門) → Folder(application) → Project(app-dev / app-staging / app-prod) としており、デプロイの単位と権限の単位が一致すること、本番プロジェクトだけに厳しい組織ポリシーを掛けられること、アプリを廃止するときフォルダごと消せることが理由です。1 プロジェクトにすべてのアプリと全環境を入れてラベルで区別する構成は、ラベルが IAM・クォータ・API 有効化の境界にならないため開発者が本番リソースを操作でき、必ず誤りです。開発者 1 人につき 1 プロジェクトは隔離としては最強でも、組織ポリシーと課金の管理コストが跳ね上がるため恒久環境としては不適です。環境ごとの 3 プロジェクトに接頭辞とラベルで詰め込む構成も、境界がプロジェクトである以上サービス単位の権限分離とフォルダごとの廃止を実現できません。

解説

本文のとおり組織ポリシーは上から下へ継承しますが、下位で `inheritFromParent: false` による上書きが可能で、ここが IAM と決定的に違う点です。IAM は上から下へ継承し、その継承は取り消せず下位で引き算はできないため、IAM で除外する案は成り立ちません。ファイアウォールは通信の可否を決めるもので外部 IP の付与自体は止められず、逆に許可もできないため、外部 IP の制約の代わりになりません。プロジェクトの移動は `gcloud beta projects move` でフォルダ間に行うもので、移動により継承される IAM と組織ポリシーが変わるため、制約回避の手段として扱うのは適切ではありません。

解説

本文は、組織をまたぐ、または別組織のパートナーと繋ぐ場面には VPC Network Peering が向くとし、ルートは交換されてもファイアウォールルールは交換されないため両側で許可が要ると述べています。Shared VPC は同一組織内でしか使えないため、組織をまたぐ要件では不適です。Private Service Connect は消費側から提供側へ向かう片方向で、サービスの入口を内部 IP として公開する仕組みであり、対等な相互通信の要件には合いません。`roles/compute.networkUser` はサブネット単位で Shared VPC の利用を許可するロールで、同一組織内の Shared VPC が前提となるため、この場面では使えません。

解説

本文は Private Service Connect の特徴として、消費側 VPC に内部 IP アドレスのエンドポイントを作ること、CIDR の重複があっても使えること、片方向で消費側から提供側へ向かうことを挙げ、パートナー SaaS への接続で使うとしています。VPC Network Peering は CIDR が重複していると作成できないため、この場面では選べません。Shared VPC は同一組織内でホストのサブネットをサービスプロジェクトへ貸す仕組みで、別組織のベンダーには適用できません。IP 空間の再設計は本文が「IP が重複している 2 拠点を繋ぐ」場面での代替として挙げるものですが、PSC が使える場面で既存リソースを移す必要はありません。

解説

本文は、Shared VPC で付与するロールは組織レベルの `roles/compute.xpnAdmin` とサブネット単位の `roles/compute.networkUser` であり、サブネット単位で `networkUser` を絞ることで「経理チームのプロジェクトは経理サブネットにしか VM を作れない」を実現できると述べています。`roles/compute.xpnAdmin` は Shared VPC を有効化しサービスプロジェクトを紐付ける権限で、サブネットの利用範囲を絞る用途ではありません。ホストプロジェクト全体への `networkUser` はすべてのサブネットの利用を許してしまい、ファイアウォールは通信の可否であってサブネットへの VM 作成自体を止められません。基本ロールの Editor は本番では使わないロールで、`iam.serviceAccounts.actAs` を含むため権限昇格の余地が生まれます。