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

解説

「そもそもこの設定を許すか」を扱うのは Organization Policy Service の制約で、domain restricted sharing の `constraints/iam.allowedPolicyMemberDomains` は自社ドメイン以外への付与そのものを禁じます。定期点検して手作業で削除する案は、付与が起きたあとの事後対応にすぎず、構造的に起こせなくする要件を満たしません。VPC Service Controls は境界を作りデータの持ち出しを止めるだけで権限は一切与えず、誤った付与そのものを防ぎません。authorized view は提供する形を固定する手段で、社外アカウントへの role 付与を禁じる働きはありません。

解説

column-level security は taxonomy の中に policy tag を作り、その policy tag をテーブルの列に付け、`roles/datacatalog.categoryFineGrainedReader` を持つ principal だけがその列を読める仕組みで、同じテーブルを多数の役割が使う場面に向きます。authorized view は提供する形を固定したいときの手段で、ビューの数だけ管理対象が増え、テーブルを1つのまま保つ要件と噛み合いません。row-level security は行に述語で権限をかける仕組みで、列を隠す用途には使いません。CMEK は鍵を誰が管理するかの話で、列単位の可視範囲を分ける働きはありません。

解説

他クラウド・オンプレミスのワークロードは Workload Identity Federation で外部 ID を短命の Google 資格情報に交換するのが正解の形で、鍵の実体をサーバに置かずに済みます。サービスアカウントキー(JSON キー)をダウンロードして配布するのは試験では基本的に誤答で、資格情報の実体を置かないという要件にも反します。個人にロールを直接付ける案は監査性と運用負荷の両面で不適で、パイプラインは人ではなくサービスアカウントで動かすのが原則です。Cloud VPN は経路の保護であって資格情報の受け渡し方の話ではなく、基本ロールの Editor も答えになりません。

解説

Data Access ログは既定で無効で、「誰がこのテーブルを読んだかを追跡したい」なら明示的に有効化するのが正解の形です。監査ログを見るために Owner を付けるのはよく出る誤りで、正しくは `roles/logging.viewer` と `roles/logging.privateLogViewer` です。Admin Activity は既定で有効かつ無効化不可のログですが記録するのは管理操作で、読み取りの証跡にはなりません。Policy Denied は拒否された記録であって、実際に読めた操作を追跡できません。

解説

各サービスの service agent(BigQuery なら `bq-<project-number>@bigquery-encryption.iam.gserviceaccount.com`)に `roles/cloudkms.cryptoKeyEncrypterDecrypter` を付与しないとテーブル作成やジョブが失敗し、CMEK にしたら Permission denied で落ちる原因はほぼこれです。dataset のロケーションは作成後に変更できず、鍵は保護対象リソースと同じロケーションに置く必要があるため、別ロケーションへ移す案は要件と逆行します。ローテーションしても既存データが再暗号化されるわけではなく、権限不足も解消しません。基本ロールの Editor は答えにならず、service agent の不足も埋まりません。