模擬問題集一覧

GCP-PCSE 模擬問題集（練習問題）

Professional Cloud Security Engineer 合格に向けた本番形式の模擬問題集。すべての問題に詳しい解説と、ドメイン別の弱点分析つき。

4 練習テスト 200 問 合格ライン 70% 各 120 分

この模擬問題集で身につくこと

  • 本番と同じ形式・難易度の問題で実力を確認
  • 制限時間つきの試験モードで時間配分を体得
  • 演習モードで1問ずつ解説を読みながら学習
  • すべての問題に正解の根拠つきの詳しい解説
  • ドメイン別スコアで弱点分野をひと目で把握
  • 完了後も何度でも復習して本番前に仕上げ

練習テストの内容

4 テスト · 全 200 問
1
模擬問題集①先頭 15 問 無料
50 問 120 分 合格 70%
2
模擬問題集② プラン限定
50 問 120 分 合格 70%
3
模擬問題集③ プラン限定
50 問 120 分 合格 70%
4
模擬問題集④ プラン限定
50 問 120 分 合格 70%

説明

GCP-PCSE（Professional Cloud Security Engineer）の合格に向けた、本番形式の模擬問題集です。全 200 問を4 回の練習テストに分割し、 試験モード／演習モードで受験できます。各問題には正解の根拠と誤答の理由を記した詳しい解説が付き、受験後はドメイン別のスコアで弱点を把握できます。 各試験は先頭の問題から無料でお試しいただけます。

月額 ¥980 で全 200 問＋全解説が受け放題

模試プラン（¥980/月）なら、ロックされた練習テストと詳しい解説、ドメイン別の弱点分析がすべて使い放題。本番に向けて実力を仕上げましょう。

GCP-PCSE の出題範囲（カバーしている分野）

全 200 問を、本番の試験ガイドに沿った次の分野から出題しています。 受験後はドメイン別の正答率が表示され、弱点が特定できます。 難易度・学習時間・合格までの進め方はGCP-PCSE の学習ガイドにまとめています。

GCP-PCSE の無料練習問題（15 問・解説つき）

会員登録なしで、全 200 問のうち 15 問を正解と解説つきでご覧いただけます。 問題をクリックすると選択肢と解説が開きます。

問題 1アクセスの構成アクセスの構成
問題
あなたは、Data Warehouse という名前のフォルダに含まれる一連の Google Cloud プロジェクトを管理しています。新しいデータ分析チームが、Data Warehouse フォルダ内のプロジェクトにあるすべての BigQuery データについてデータ分析を行うことが承認されました。このチームはデータの読み取りのみが可能で、データを変更または削除する権限は持たないようにする必要があります。最小権限の原則を守りつつ、アクセス権のプロビジョニングにかかる運用のオーバーヘッドを削減したいと考えています。どうすればよいですか？

選択肢と解説

  • 1
    Data Warehouse フォルダ内の各プロジェクトについて、プロジェクト レベルで BigQuery データ閲覧者（BigQuery Data Viewer）ロールを付与する。
  • ✓
    Data Warehouse フォルダで BigQuery データ閲覧者（BigQuery Data Viewer）ロールを付与する。
  • 3
    Data Warehouse フォルダ内の各プロジェクトにある各 BigQuery データセットについて、データセット レベルで BigQuery データ閲覧者（BigQuery Data Viewer）ロールを付与する。
  • 4
    Data Warehouse フォルダで BigQuery メタデータ閲覧者（BigQuery Metadata Viewer）ロールを付与する。

解説

【正解】B

【0からの解説】
①前提知識
・Google Cloud のリソース階層は「組織 → フォルダ → プロジェクト → リソース（BigQuery データセットなど）」の構造で、上位で付与した IAM ロールは下位のすべてのリソースに継承されます。フォルダで1回付与すれば、そのフォルダ内の既存のプロジェクトだけでなく、今後追加されるプロジェクトにも自動的に適用されます。
・BigQuery データ閲覧者（roles/bigquery.dataViewer）は、テーブルやビューのデータとメタデータの読み取りを許可するロールで、データの変更・削除の権限は含みません。
・BigQuery メタデータ閲覧者（roles/bigquery.metadataViewer）は、データセットやテーブルのスキーマなどのメタデータだけを参照できるロールで、テーブルのデータ自体は読み取れません。

②要件と制約語の整理
・フォルダ内の「すべてのプロジェクトのすべての BigQuery データ」を読み取れること。
・変更・削除はできないこと（最小権限の原則）。
・プロビジョニングの「運用のオーバーヘッドを削減」すること。

③正解の理由
B はフォルダに BigQuery データ閲覧者ロールを1回付与するだけで、IAM の継承によりフォルダ配下の全プロジェクト・全データセットのデータを読み取れるようになります。読み取り専用のロールなので最小権限を満たし、プロジェクトやデータセットが増えても追加作業が不要なため、運用のオーバーヘッドも最小です。チームに承認された範囲がまさに「フォルダ内のすべての BigQuery データ」なので、フォルダでの付与は過剰な権限にもなりません。なお、実際にクエリを実行するには、ジョブを実行するプロジェクトで BigQuery ジョブユーザー（roles/bigquery.jobUser）なども必要ですが、選択肢の中でデータの読み取り権限を最小の運用負荷で与えるのは B です。

【誤りの選択肢】
A：権限の範囲としては正しいものの、プロジェクトごとに個別に付与する必要があり、プロジェクトが増えるたびに付与作業が発生します。フォルダ1か所で付与できる B に比べて運用のオーバーヘッドが大きく、要件に反します。
C：データセットごとに付与するのは最もきめ細かい方法ですが、全プロジェクトの全データセットに付与作業が必要で、データセットが追加されるたびにも作業が発生します。「すべての BigQuery データ」へのアクセスが承認済みである以上ここまで細かくする必要はなく、運用負荷が最も大きくなります。
D：BigQuery メタデータ閲覧者はスキーマなどのメタデータしか参照できず、テーブルのデータを読み取れないため、データ分析という目的を果たせません。

【参考】
BigQuery の IAM ロールと権限
リソース階層を使用したアクセス制御 | Identity and Access Management (IAM)
この問題のページを開く →
問題 2データ保護の確保データ保護の確保
問題
あなたのグローバルな防衛企業は、最高機密に分類されたデータを BigQuery と Cloud Storage に移行しようとしています。国家安全保障に関する規制により、マスター暗号鍵の鍵マテリアルが、認定済みのオンプレミスの暗号ハードウェアから決して外に出ないことが求められています。また、どのクラウド プロバイダにも依存せずに、データへのアクセスを一方的に取り消せる能力を保持しなければなりません。どうすればよいですか？

選択肢と解説

  • 1
    BigQuery データセットと Cloud Storage バケットに顧客管理の暗号鍵（CMEK）を使用する。鍵は Cloud Key Management Service（Cloud KMS）に保存する。
  • 2
    顧客指定の暗号鍵（CSEK）を使用し、Cloud Storage と BigQuery の各データ操作で独自の暗号鍵を提供する。
  • 3
    既存のオンプレミスのマスター暗号鍵を Cloud Key Management Service（Cloud KMS）にインポートする。インポートした鍵を BigQuery と Cloud Storage の暗号化に使用する。
  • ✓
    BigQuery データセットと Cloud Storage バケットに Cloud External Key Manager（Cloud EKM）を構成する。EKM を既存のオンプレミスのハードウェア セキュリティ モジュール（HSM）と統合する。

解説

【正解】D

【0からの解説】
①前提知識
・Google Cloud の保存データは、データ暗号鍵（DEK）でデータを暗号化し、その DEK を鍵暗号鍵（KEK）でさらに暗号化する「エンベロープ暗号化」で保護されています。誰が、どこで KEK を管理するかによって選択肢が分かれます。
・顧客管理の暗号鍵（CMEK）: 顧客が Cloud KMS（ソフトウェア鍵または Cloud HSM の鍵）で KEK を管理します。鍵マテリアルは Google のインフラ内にあります。
・顧客指定の暗号鍵（CSEK）: 顧客が鍵を API リクエストごとに渡す方式で、Cloud Storage と Compute Engine でのみサポートされ、BigQuery では使えません。
・鍵のインポート: オンプレミスなどで生成した鍵マテリアルを Cloud KMS（ソフトウェアまたは Cloud HSM）にインポートして使う方式で、インポート後は鍵マテリアルが Google 側に存在します。
・Cloud External Key Manager（Cloud EKM）: KEK を Google Cloud の外部にある、サポート対象の外部鍵管理システム（Fortanix、Futurex、Thales などのパートナー製品）で保持し、Google Cloud は暗号化・復号のたびに外部鍵マネージャーに鍵の利用を要求します。鍵マテリアルは外部システムに置かれたまま Google に送られることはなく、顧客はいつでも外部鍵マネージャー側で Google Cloud からのアクセスを取り消せます。取り消せば Google を含め誰もデータを復号できなくなります。BigQuery と Cloud Storage は、Cloud KMS の CMEK 統合を通じて Cloud EKM の鍵を利用できます。

②要件と制約語の整理
・マスター暗号鍵の鍵マテリアルが、オンプレミスの認定済み暗号ハードウェアから「決して外に出ない」。
・クラウド プロバイダに依存せず、データへのアクセスを「一方的に取り消せる」。
・対象サービスは BigQuery と Cloud Storage。

③正解の理由
D の Cloud EKM は、鍵マテリアルを Google Cloud の外（オンプレミスの HSM と統合した外部鍵マネージャー）に保持したまま、BigQuery と Cloud Storage の暗号化に使えます。顧客が外部鍵マネージャー側で鍵へのアクセスを止めればデータは復号できなくなるため、クラウド プロバイダとは独立してアクセスを一方的に取り消せます。2つの要件をどちらも満たすのは EKM だけです。

【誤りの選択肢】
A：CMEK の鍵マテリアルは Cloud KMS（Google のインフラ）内に保存されるため、「鍵マテリアルがオンプレミスのハードウェアから外に出ない」という要件に反します。鍵の無効化は顧客が操作できますが、鍵そのものはクラウド プロバイダ側に存在するため、プロバイダから独立した取り消しとは言えません。
B：CSEK は BigQuery でサポートされていないため、BigQuery の要件を満たせません。また CSEK でも鍵はリクエストごとに Google に送られ、処理中は Google 側で使用されるため、鍵が外に出ないという要件にも合いません。
C：鍵のインポートは、オンプレミスの鍵マテリアルを Cloud KMS にコピーする方式です。インポートした時点で鍵マテリアルがオンプレミスのハードウェアの外（Google Cloud）に出てしまうため、規制要件に真っ向から反します。

【参考】
Cloud External Key Manager | Cloud Key Management Service
Cloud External Key Manager のリファレンス アーキテクチャ | Cloud Key Management Service
この問題のページを開く →
問題 3通信の保護と境界保護の確立通信の保護と境界保護の確立
問題
あなたの会社は、人工知能（AI）モデルを中央のプロジェクトにデプロイしました。このモデルには機密性の高い知的財産が多く含まれており、インターネットから厳格に隔離しておく必要があります。モデルのエンドポイントは、組織内のあらかじめ定義されたプロジェクトのリストに対してのみ公開する必要があります。どうすればよいですか？

選択肢と解説

  • ✓
    モデル プロジェクト内に、モデルのエンドポイントを指す内部アプリケーション ロードバランサを作成する。このロードバランサを Private Service Connect を使用して、構成したプロジェクトのリストに公開する。
  • 2
    モデル プロジェクトと、モデルに接続する必要がある各プロジェクトの両方で、限定公開の Google アクセス（Private Google Access）を有効にする。限定公開の Google アクセスのアドレスへの接続を許可するファイアウォール ポリシーを作成する。
  • 3
    他のすべてのプロジェクトに提供する共有 VPC ネットワークをホストする中央プロジェクトを作成する。このプロジェクトですべてのファイアウォール ルールを一元管理して、モデルへのアクセスを許可する。
  • 4
    モデル プロジェクト内に、モデルのエンドポイントを指す外部アプリケーション ロードバランサを作成する。Cloud Armor ポリシーを作成して、IP アドレスを Google Cloud のものに制限する。

解説

【正解】A

【0からの解説】
①前提知識
・Private Service Connect（PSC）は、サービスを提供する側（プロデューサー）が内部ロードバランサの背後にあるサービスを「サービス アタッチメント」として公開し、利用する側（コンシューマー）が自分の VPC 内の内部 IP アドレス（PSC エンドポイント）経由でそのサービスに接続できる仕組みです。通信は Google のネットワーク内で完結し、インターネットを経由しません。VPC ピアリングのように双方のネットワーク全体をつなぐのではなく、「特定のサービスだけ」を一方向に公開できるのが特長です。
・サービス アタッチメントの接続設定には「自動承認」と「明示的な承認」があり、明示的な承認ではコンシューマーの承認リスト（プロジェクト、VPC ネットワーク、または個々のエンドポイント単位）に載っているコンシューマーからの接続だけを受け入れます。Google はこの明示的な承認を推奨しています。
・内部アプリケーション ロードバランサは内部 IP アドレスだけを持つ L7 のロードバランサで、インターネットからは到達できません。

②要件と制約語の整理
・機密性の高いモデルを「インターネットから厳格に隔離」する。
・エンドポイントを「組織内のあらかじめ定義されたプロジェクトのリストにのみ」公開する。

③正解の理由
A は、モデルのエンドポイントを内部アプリケーション ロードバランサの背後に置いてインターネットに露出させず、そのロードバランサを PSC のサービス アタッチメントとして公開し、承認リストに登録したプロジェクトからの接続だけを受け入れます。インターネットからの隔離と、定義済みのプロジェクトだけへの限定公開という2つの要件を、ネットワーク全体を接続せずに満たす、Google が推奨するプロデューサー / コンシューマー型の構成です。
補足: Vertex AI（現 Gemini Enterprise Agent Platform）のオンライン推論でも、PSC に基づく専用のプライベート エンドポイントを作成し、接続を許可するプロジェクトのリスト（projectAllowlist）を指定できます。考え方は A と同じく「PSC ＋許可リスト」です。

【誤りの選択肢】
B：限定公開の Google アクセスは、外部 IP アドレスを持たない VM が Google の API（storage.googleapis.com など）に到達するための機能です。社内の特定のプロジェクトにデプロイしたモデルのエンドポイントを、指定したプロジェクトにだけ公開する仕組みではなく、公開先のプロジェクトを限定する制御もできません。
C：共有 VPC は、複数のプロジェクトで1つの VPC ネットワークを共有する構成です。「他のすべてのプロジェクト」に同じネットワークを提供すると、モデルは広くネットワーク到達可能になり、定義済みのプロジェクトだけに限定するという要件に反します。また既存プロジェクトのネットワーク構成を大きく作り替える必要があり、目的に対して過大です。
D：外部アプリケーション ロードバランサはインターネットに公開された IP アドレスを持つため、「インターネットから厳格に隔離する」という要件に真っ向から反します。Cloud Armor で「Google Cloud の IP アドレス」に制限しても、Google Cloud 上の他の顧客を含めて誰でもそれらの IP アドレスを使えるため、特定のプロジェクトに限定したことにはなりません。

【参考】
Private Service Connect を使用してサービスを公開する | Virtual Private Cloud
公開サービスへのアクセスの制御について | Virtual Private Cloud
オンライン推論に Private Service Connect に基づく専用プライベート エンドポイントを使用する
この問題のページを開く →
問題 4運用の管理運用の管理
問題
あなたの会社は最近、組織レベルで Security Command Center を有効にしました。本番環境フォルダに属するプロジェクトのコンテナで実行されているアプリケーションに対して、ランタイムの脅威検出を実装する必要があります。具体的には、実行中のコンテナ内で追加のライブラリが読み込まれた場合や、悪意のあるスクリプトが実行された場合に通知を受ける必要があります。検出結果が Security Command Center 内に表示されるようにしつつ、この要件を満たすように Security Command Center を構成する必要があります。どうすればよいですか？

選択肢と解説

  • 1
    本番環境フォルダ内の不審なコンテナ アクティビティについて、Cloud Logging と Cloud Monitoring でログベースの指標とアラートを作成する。
  • 2
    Security Command Center 内の Security Health Analytics を構成し、本番環境フォルダ内のコンテナ ランタイムの脆弱性をモニタリングする。
  • 3
    本番環境フォルダ内のコンテナが、Container-Optimized OS を使用しているホスト上で実行されていることを確認する。
  • ✓
    本番環境フォルダ内のプロジェクトに対して、Security Command Center Premium ティアの Container Threat Detection を有効にする。

解説

【正解】D

【0からの解説】
①前提知識
・Security Command Center（SCC）は Google Cloud のセキュリティとリスクを一元管理するサービスで、各種の組み込みサービス（検出サービス）が見つけた問題を「検出結果（finding）」として SCC に集約します。
・Container Threat Detection（CTD）は SCC の組み込みサービスの一つで、GKE ノードの Container-Optimized OS イメージの状態を継続的にモニタリングし、コンテナのランタイムの振る舞いから攻撃をほぼリアルタイムで検出します。代表的な検出器に「Added Binary Executed（追加されたバイナリの実行）」「Added Library Loaded（追加されたライブラリの読み込み）」「Malicious Script Executed（悪意のあるスクリプトの実行）」「Reverse Shell」などがあり、検出したインシデントは SCC の検出結果として書き込まれます（必要に応じて Cloud Logging にも出力）。
・CTD は SCC の Premium ティア（または Enterprise ティア）でのみ利用でき、組織・フォルダ・プロジェクト単位で有効化できます。なお Added Binary Executed や Added Library Loaded など一部の検出器は、予期しない影響を避けるためにデフォルトで無効になっているので、モジュールの設定で有効にします。通知は SCC の通知構成（Pub/Sub）で受け取れます。

②要件と制約語の整理
・コンテナの「ランタイム」の脅威検出であること（構成ミスや脆弱性のスキャンではない）。
・追加ライブラリの読み込みと、悪意のあるスクリプトの実行を検出して通知を受けたい。
・対象は本番環境フォルダのプロジェクト。
・検出結果が SCC 内に表示されること。

③正解の理由
D の Container Threat Detection は、まさに「追加ライブラリの読み込み」「悪意のあるスクリプトの実行」を検出する専用の検出器を持ち、結果は SCC の検出結果として表示されます。本番環境フォルダ配下のプロジェクトを対象に有効化でき、通知も SCC の機能で構成できます。すべての要件を満たすマネージドな方法です。

【誤りの選択肢】
A：ログベースの指標とアラートは自前で検知ロジックを作る方法であり、そもそもコンテナ内のライブラリ読み込みやスクリプト実行をカーネル レベルで捉えるログは標準では得られません。また結果は Cloud Monitoring のアラートになり、SCC の検出結果としては表示されないため、「SCC 内で確認できること」という要件を満たしません。
B：Security Health Analytics は、公開バケット、過剰な権限、開放されたファイアウォールなど、リソースの「構成ミス（misconfiguration）」をスキャンするサービスです。実行中のコンテナ内で起きるプロセスの実行やライブラリの読み込みといったランタイムの振る舞いは検出できません。
C：Container-Optimized OS は CTD がモニタリング対象とするノード イメージであり前提条件の一部ですが、OS を使うだけでは脅威検出は行われません。検出サービスを有効にしない限り、通知も SCC の検出結果も得られません。

【参考】
Container Threat Detection の概要 | Security Command Center
Container Threat Detection を使用する | Security Command Center
この問題のページを開く →
問題 5コンプライアンス上の理由から、ベンダーによるすべてのデータアクセスと、Google の担当者による管理アクセスが確実にロ…コンプライアンス要件への対応
問題
あなたの組織は最近、機密性の高い顧客データを Cloud Storage バケットに移行しました。コンプライアンス上の理由から、ベンダーによるすべてのデータアクセスと、Google の担当者による管理アクセスが確実にログに記録されるようにする必要があります。どうすればよいですか。

選択肢と解説

  • 1
    Cloud Storage バケットをホストしているプロジェクトで、Cloud Storage のデータアクセス監査ログ（Data Access audit logs）を構成する。
  • ✓
    組織に対してアクセスの透明性（Access Transparency）を有効にする。
  • 3
    組織レベルで Cloud Storage のデータアクセス監査ログ（Data Access audit logs）を構成する。
  • 4
    Cloud Storage バケットをホストしているプロジェクトに対してアクセスの透明性（Access Transparency）を有効にする。

解説

【正解】B

【0からの解説】
①前提知識：Google Cloud には「誰がデータにアクセスしたか」を記録する仕組みが 2 系統あり、記録の対象となる「人」がまったく違います。
・Cloud Audit Logs（監査ログ）：お客様自身の組織のユーザーやサービス アカウントが Google Cloud の API を呼び出した記録です。このうちデータアクセス監査ログ（Data Access audit logs）は、Cloud Storage のオブジェクトの読み取りなど「データの読み書き」を記録します（BigQuery 以外はデフォルトで無効のため、明示的な有効化が必要です）。
・アクセスの透明性（Access Transparency）：クラウド ベンダーである Google の担当者（サポート エンジニアや運用担当者）が、お客様のコンテンツにアクセスしたり管理操作を行ったりしたときに、その理由（サポートケース番号など）・アクセスした担当者の所属や場所・対象リソースなどをほぼリアルタイムでログに残す機能です。通常の監査ログには Google 側の担当者の操作は記録されないため、この機能が別に用意されています。Access Approval と組み合わせると、Google によるアクセスを事前承認制にすることもできます。

②要件の整理：問題文が記録を求めているのは「ベンダー（＝クラウド事業者である Google）によるデータアクセス」と「Google の担当者による管理アクセス」です。自社のユーザーによるアクセスではありません。したがってアクセスの透明性を使う必要があります。また、コンプライアンス上「すべて」を記録する必要があるため、対象範囲に漏れが出ない設定単位を選ぶことも重要です。

③正解の理由：アクセスの透明性は組織（Organization）単位のセキュリティ制御で、組織内のすべてのプロジェクトのサポート対象サービス（Cloud Storage を含む）に適用されます。組織に対して有効にすることで、バケットがどのプロジェクトにあっても、また今後プロジェクトやバケットが増えても、Google 担当者のアクセスが漏れなく記録されます。なお、現在の公式ドキュメントでは「アクセスの透明性はすべての Google Cloud 組織に対するデフォルトのセキュリティ制御」と説明されており、IAM の［設定］ページで組織に対して有効になっていることを確認する運用になっています。いずれにしても「組織単位で有効にする」が正しい考え方です。

【誤りの選択肢】
A：データアクセス監査ログが記録するのは、お客様の組織のプリンシパル（ユーザーやサービス アカウント）による API 呼び出しです。Google の担当者によるアクセスや管理操作は記録されないため、要件の中心である「ベンダー（Google）によるアクセスの記録」を満たしません。
C：組織レベルでデータアクセス監査ログを構成すると、記録の範囲は組織全体に広がりますが、記録対象は自組織のプリンシパルの操作のままです。Google 担当者のアクセスは記録されないため、A と同じ理由で要件を満たしません。
D：アクセスの透明性は組織全体を対象とするセキュリティ制御として提供されており、特定のプロジェクトだけを対象にする考え方ではありません。仮にバケットのあるプロジェクトだけを対象にしても、他のプロジェクトや今後作成されるプロジェクトの機密データが対象外となり、「すべてを記録する」というコンプライアンス要件に対して網羅性で B に劣ります。

【参考】
アクセスの透明性の概要 | Access Transparency
アクセスの透明性の概要 | Assured Workloads
Cloud Storage での Cloud Audit Logs
この問題のページを開く →
問題 6アクセスはデバイスのセキュリティ状況（セキュリティ ポスチャー）に基づいて制限する必要があり、具体的には最新のオペレーテ…アクセスの構成
問題
あなたの組織はゼロトラスト セキュリティ モデルを導入しており、Chrome Enterprise Premium を使用しています。会社は Cloud Storage に保存されている機密データへのアクセスを統制したいと考えています。ネットワークの場所に関係なく、管理対象デバイスを使用している承認済みユーザーだけがこのデータにアクセスできるように、アクセス制御を構成する必要があります。アクセスはデバイスのセキュリティ状況（セキュリティ ポスチャー）に基づいて制限する必要があり、具体的には最新のオペレーティング システム（OS）パッチとウイルス対策ソフトウェアが必要です。どうすればよいですか。

選択肢と解説

  • 1
    VPC Service Controls に対して特定のユーザーにアクセス権を付与し、Cloud Storage バケットにアクセスするための境界を作成する。Identity-Aware Proxy（IAP）を構成して、ユーザーがデータにアクセスする前に認証する。
  • 2
    IP アドレス範囲に基づく IAM Conditions を構成する。ユーザーに VPN 経由での接続を必須にする。ユーザーのデバイスにエンドポイント検証ソフトウェアを導入し、基本的なコンプライアンスを確認する。
  • ✓
    Access Context Manager で、デバイス ポリシーを必須とするアクセスレベルを作成する。このアクセスレベルを使用してコンテキストアウェア アクセス ポリシーを作成する。そのポリシーを、Cloud Storage バケットを含む VPC Service Controls の境界に適用する。
  • 4
    Cloud Firewall ルールを使用して、送信元 IP アドレスに基づいて Cloud Storage バケットへのアクセスを制限する。ユーザーに多要素認証（MFA）による認証を必須にする。

解説

【正解】C

【0からの解説】
①前提知識：
・ゼロトラスト：社内ネットワークにいるかどうかで信頼を決めず、「誰が（ID）」「どのデバイスで（デバイスの状態）」「どんな状況で」アクセスしているかをリクエストごとに検証する考え方です。Google はこれを BeyondCorp として実践し、製品としては Chrome Enterprise Premium（旧 BeyondCorp Enterprise）で提供しています。
・Access Context Manager：アクセスを許可する条件を「アクセスレベル」として定義するサービスです。アクセスレベルには IP 範囲・地域・ユーザー ID のほか「デバイス ポリシー」を含められ、OS の種類と最小バージョン、画面ロック、ディスク暗号化、会社所有デバイスかどうかなどを条件にできます。デバイスの情報はエンドポイント確認（Endpoint Verification）で収集され、Chrome Enterprise Premium のカスタム アクセスレベル（CEL 式）では、Windows の適用済み修正プログラム（hotfixes）や、インストール済み・有効なウイルス対策製品（av_installed／av_enabled）といった詳細な属性まで条件にできます。
・VPC Service Controls：Cloud Storage などの Google マネージド サービスの周りに「サービス境界」を作り、境界外からの API アクセスを遮断する仕組みです。境界にアクセスレベル（上り（内向き）ルールなど）を適用すると、「この条件を満たすユーザー／デバイスからのアクセスだけは許可する」というコンテキストアウェア アクセスを実現できます。

②要件の整理：(1) 承認済みユーザーのみ、(2) 管理対象デバイスのみ、(3) ネットワークの場所に依存しない、(4) OS パッチとウイルス対策というデバイスのセキュリティ状況で判定する、(5) 対象は API でアクセスする Google マネージド サービスの Cloud Storage、の 5 点です。

③正解の理由：Access Context Manager でデバイス ポリシーを含むアクセスレベルを作成し、それを Cloud Storage を囲む VPC Service Controls の境界に適用すると、「承認された ID」かつ「セキュリティ状況を満たす管理対象デバイス」からのリクエストだけが Cloud Storage の API に到達できます。判定は IP アドレスに依存しないため、社外からでも条件を満たせばアクセスでき、条件を満たさない端末は社内からでも拒否されます。これは Google が推奨するゼロトラスト（コンテキストアウェア アクセス）の構成そのものです。
補足：選択肢 C の「コンテキストアウェア アクセス ポリシーを境界に適用する」は手順を簡略化した表現です。実際の構成では、「ポリシー」という独立したオブジェクトを境界に付けるのではなく、作成したアクセスレベルをサービス境界の設定に直接指定します。具体的には、境界の「アクセスレベル」の項目にそのアクセスレベルを追加する（境界外からのリクエストのうち、そのアクセスレベルを満たすものを許可する）か、上り（内向き）ルールの送信元（sources）にアクセスレベルを指定し、対象の ID や Cloud Storage のメソッドと組み合わせて許可します。なお、アクセスレベルやサービス境界はいずれも Access Context Manager の「アクセス ポリシー」という入れ物の中に作成されます。こうして境界にアクセスレベルを設定することが、Google Cloud の API に対するコンテキストアウェア アクセスの実体です。

【誤りの選択肢】
A：IAP はロードバランサの背後で動くウェブ アプリケーションや VM への TCP 接続などの前段に置く認証・認可の仕組みで、Cloud Storage の API アクセスを保護するものではありません。また「VPC Service Controls に対してユーザーにアクセス権を付与する」だけでは、デバイスのセキュリティ状況（OS パッチ・ウイルス対策）を判定する要素がなく、要件 (2)(4) を満たしません。
B：IP アドレス範囲と VPN による制御は「ネットワークの場所」に依存する従来型の境界防御で、「ネットワークの場所に関係なく」というゼロトラストの要件 (3) に反します。エンドポイント検証ソフトウェアを導入するだけでは、その結果がアクセスの判定（アクセスレベル）に組み込まれないため、デバイスの状態によってアクセスを制限できません。
D：VPC ファイアウォール ルール（Cloud NGFW）は VM など VPC 内のリソースに出入りするパケットを制御するもので、Google マネージド サービスである Cloud Storage の API アクセスには適用されません。また送信元 IP と MFA だけではデバイスのセキュリティ状況を検証できず、要件 (3)(4) を満たしません。

【参考】
カスタム アクセスレベル | Access Context Manager
Endpoint Verification によって収集されたデバイス属性
上り（内向き）ルールを使用したコンテキストアウェア アクセス | VPC Service Controls
この問題のページを開く →
問題 7情報漏洩を防止し検出するための、安全な Google Cloud 環境を提供する必要があります。データ保護の確保
問題
あなたの組織は、イノベーションを通じて製品を改善するために AI を活用しています。開発者は、あるプロジェクトで Vertex AI の Gemini を使用したいと考えています。情報漏洩を防止し検出するための、安全な Google Cloud 環境を提供する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    Vertex AI プロジェクトの周囲に VPC Service Controls の境界を設定する。コンテンツ検査のために Data Loss Prevention API を有効にする。
  • 2
    開発者と AI エンジニアに Vertex AI ユーザーのロールを付与する。Cloud Logging で監査証跡をモニタリングする。
  • ✓
    Model Armor をデプロイして Vertex AI エンドポイントを保護する。Security Command Center の検出結果を確認して情報漏洩を検出する。
  • 4
    Vertex AI API エンドポイントとの間のすべてのトラフィックを許可するファイアウォール ルールを実装する。

解説

【正解】C

【0からの解説】
①前提知識：
・Vertex AI（現 Gemini Enterprise Agent Platform）：Google の生成 AI モデル Gemini などを API で利用できるプラットフォームです。
・Model Armor：生成 AI アプリケーションのプロンプト（入力）とレスポンス（出力）を検査・サニタイズするフルマネージド サービスです。プロンプト インジェクションやジェイルブレイクの検出、悪意のある URL の検出、責任ある AI（RAI）フィルタに加え、Sensitive Data Protection（旧 Cloud DLP）の機能を組み込んで、プロンプトやモデルの回答に含まれるクレジットカード番号や個人情報などの機密データを検出・秘匿化・ブロックできます。Gemini Enterprise Agent Platform と直接統合でき、フロア設定で組織・フォルダ・プロジェクト単位に最低限の保護を強制することもできます。
・Security Command Center（SCC）：Google Cloud のセキュリティ リスクと脅威を一元的に可視化するサービスです。AI 保護（AI Protection）機能では、Model Armor を有効にして AI 関連のコンポーネントと統合すると、Model Armor の検出結果を SCC で調査できます。

②要件の整理：対象は「Gemini を使う生成 AI ワークロード」で、求められているのは情報漏洩の「防止（prevent）」と「検出（detect）」の両方です。生成 AI 特有の情報漏洩の経路には、利用者が機密情報をプロンプトに入れてしまう、プロンプト インジェクションで機密情報を引き出される、モデルの回答に機密情報が含まれてしまう、といったものがあります。

③正解の理由：Model Armor を Gemini の前段（Gemini Enterprise Agent Platform との統合、またはアプリケーションからの API 呼び出し）に配置すれば、プロンプトとレスポンスをリアルタイムに検査し、機密データの流出やインジェクション攻撃を「防止」できます。さらにその検出結果を SCC の AI 保護で一元的に確認することで、「検出」と対応まで行えます。防止と検出の両方を、生成 AI 向けに設計されたマネージド機能で満たしているのは C です。

【誤りの選択肢】
A：VPC Service Controls は API 経由のデータ持ち出し（境界外へのコピーなど）を防ぐ重要な制御で、Model Armor と併用する価値はあります。しかし正規の利用者がプロンプトやレスポンスを通じて機密情報を漏らすケースは防げません。また「Data Loss Prevention API を有効にする」だけでは何も検査されず、プロンプト／レスポンスに検査を組み込む処理を自前で実装する必要があります。漏洩を検出・可視化する仕組みも示されておらず、生成 AI 向けの防止と検出を備えた C に劣ります。
B：Vertex AI ユーザーのロールの付与は「誰が使えるか」を決める認可であり、情報漏洩そのものを防止する制御ではありません。監査ログをモニタリングしても API 呼び出しの記録が残るだけで、プロンプトやレスポンスに含まれる機密データを検出・ブロックすることはできません。
D：すべてのトラフィックを許可するファイアウォール ルールはセキュリティを弱める設定であり、情報漏洩の防止にも検出にもなりません。そもそも Vertex AI の API は Google マネージド サービスで、VPC ファイアウォール ルールでやり取りの内容を検査することはできません。

【参考】
Model Armor の概要
Model Armor を Gemini Enterprise Agent Platform と統合する
AI 保護の概要 | Security Command Center
この問題のページを開く →
問題 8通信の保護と境界保護の確立通信の保護と境界保護の確立
問題
あなたの会社は、Google Cloud 上で重要なウェブ アプリケーションをホストしています。このアプリケーションでは、クロスサイト スクリプティング（XSS）や SQL インジェクションの試行など、高度なレイヤ 7 攻撃が増加しています。正当なトラフィックへの影響を最小限に抑え、高可用性を確保しながら、これらの攻撃からアプリケーションを保護する必要があります。どうすればよいですか？

選択肢と解説

  • 1
    ウェブ アプリケーションのインスタンスの前段にロードバランサを実装し、Adaptive Protection とスロットリングを有効にして、これらの悪意のあるリクエストの発生を緩和する。
  • 2
    Cloud Next Generation Firewall を構成して、/32 アドレスを対象とする既知の悪意のある IP アドレスをブロックする。
  • 3
    バックエンド サービスで、OWASP Top 10 の脆弱性に対応する Google Cloud Armor の事前構成済み WAF ルールを有効にする。
  • ✓
    ロードバランサで、OWASP Top 10 の脆弱性に対応するカスタマイズされた WAF ルールと事前構成済みの WAF ルールを含む Cloud Armor セキュリティ ポリシーを構成する。

解説

【正解】D

【0からの解説】
①前提知識
・Google Cloud Armor は、外部アプリケーション ロードバランサなどの前段（Google のネットワークのエッジ）で動作する WAF（Web Application Firewall）兼 DDoS 防御サービスです。「セキュリティ ポリシー」にルールを優先度順に並べ、ロードバランサのバックエンド サービスに関連付けて使います（事前構成済み WAF ルールは、ロードバランサの背後にあるバックエンド サービスでのみ使用できます）。
・事前構成済み WAF ルールは、OWASP ModSecurity Core Rule Set（CRS）をもとにした SQL インジェクション（sqli）、クロスサイト スクリプティング（xss）などのルールです。感度レベル（低いほど確度の高いシグネチャだけを使い誤検知が少ない）の選択、誤検知の原因になるリクエスト フィールドの検査対象からの除外、プレビュー モードでの事前検証といったチューニングが可能です。Google は、まず感度レベル1をプレビュー モードで試し、アプリケーションへの影響を把握してから適用することを推奨しています。
・カスタムルールは、CEL 式でパス・ヘッダー・地域・IP アドレスなどを条件にした独自の許可 / 拒否ルールで、事前構成済みルールと組み合わせて誤検知を抑えたり、アプリ固有の攻撃パターンに対応したりします。
・Adaptive Protection は機械学習で L7 の DDoS（大量リクエスト）の異常を検知してルールを提案する機能、Cloud Next Generation Firewall（Cloud NGFW）は VPC ネットワーク内の VM などへのトラフィックを制御するファイアウォールです。

②要件と制約語の整理
・XSS や SQL インジェクションといった高度な L7 攻撃を防ぐ。
・「正当なトラフィックへの影響を最小限に」抑える（誤検知を抑えるチューニングができること）。
・「高可用性を確保」する（グローバルなエッジで動作するマネージドな防御）。

③正解の理由
D は、ロードバランサに Cloud Armor セキュリティ ポリシーを適用し、OWASP Top 10 向けの事前構成済み WAF ルールで XSS・SQL インジェクションをブロックしつつ、アプリケーションに合わせてカスタマイズしたルール（感度レベルの調整、フィールドの除外、独自の条件や例外）で誤検知を抑えます。事前構成済みルールを既定のまま有効にするだけでは正当なリクエストを誤ってブロックすることがあるため、カスタマイズと組み合わせるのが Google の推奨する導入方法です。Cloud Armor は Google のエッジで分散して動作するため、高可用性も確保できます。

【誤りの選択肢】
A：Adaptive Protection は主に L7 の DDoS（ボリューム型の異常トラフィック）を検知する機能で、スロットリング（レート制限）もリクエストの量を抑えるものです。XSS や SQL インジェクションのように、1件のリクエストの中身に含まれる攻撃ペイロードを検査してブロックする仕組みではありません。
B：特定の悪意ある IP アドレスを /32 単位でブロックしても、攻撃者は IP アドレスを簡単に変えられるため、高度な L7 攻撃は防げません。XSS や SQL インジェクションの防御にはリクエストの内容を検査する WAF が必要で、IP アドレスのブロックだけでは不十分です。
C：事前構成済み WAF ルールを有効にする方向性は正しく、XSS や SQL インジェクションの検知自体はできます。しかし C は「事前構成済みルールを有効にするだけ」で、D との違いは誤検知を抑えるための調整が含まれていない点です。事前構成済みルールは、感度レベルを指定せずに有効にすると既定で最も厳しい感度レベル4（ルールセット内のすべてのシグネチャを評価）で動作するため、アプリケーションによっては正当なリクエスト（たとえば SQL に似た文字列を含む検索語やフォーム入力）まで攻撃と判定してブロックしてしまいます。D のように、①感度レベルを下げる・誤検知の原因になるシグネチャやリクエスト フィールド（特定の Cookie やパラメータなど）を検査対象から除外する、②カスタムルールで信頼できる送信元や特定のパスを例外として扱ったり、アプリ固有の攻撃パターンを追加でブロックしたりする、といった調整を加えてはじめて「正当なトラフィックへの影響を最小限に」という要件を満たせます。なお、C の「バックエンド サービスで有効にする」も実際にはセキュリティ ポリシーをバックエンド サービスに関連付けて行うもので、適用場所の違いが正誤の決め手ではありません。

【参考】
Cloud Armor の事前構成 WAF ルールの概要 Armor
事前構成済みの WAF ルールを設定する Armor
この問題のページを開く →
問題 9運用の管理運用の管理
問題
あなたは規制対象の業界の企業に勤務しており、クラウド環境の継続的なセキュリティを担当しています。特定のコンプライアンス ポリシーに基づいて、特定のフォルダ内の構成ミスを防止し、検出する必要があります。業界固有のコンプライアンス ポリシーと、社内独自のポリシーの両方を遵守する必要があります。どうすればよいですか？

選択肢と解説

  • ✓
    カスタムおよび事前定義の SHA（Security Health Analytics）または組織のポリシーを使用して、ポスチャー ファイルを作成する。フォルダ レベルでポスチャーを適用する。
  • 2
    特定のビジネス要件に従うカスタムの組織のポリシーを作成する。フォルダ レベルでポリシーを適用する。
  • 3
    業界の規制に適した特定のコントロール パッケージ（control bundle）を使用して、フォルダ レベルで Assured Workloads を有効にする。
  • 4
    カスタムの Rego ポリシーを使用した Workload Manager を使用して、フォルダ レベルで環境を継続的にスキャンし、構成ミスを検出する。

解説

【正解】A

【0からの解説】
①前提知識
・Security Command Center（SCC）のセキュリティ ポスチャー サービスでは、「ポスチャー」（YAML のポスチャー ファイルとして定義するポリシーの集合）を作成し、組織・フォルダ・プロジェクトにデプロイ（適用）できます。ポスチャーには次の2種類のポリシーを含められます。
　- 予防用: 組織のポリシーの制約（事前定義の制約とカスタム制約）。違反する構成変更そのものを拒否します。
　- 検出用: Security Health Analytics（SHA）の検出器（事前定義の検出器とカスタム モジュール）。違反している構成を検出結果として報告します。
・CIS Google Cloud Computing Platform Benchmark、NIST SP 800-53、ISO 27001、PCI DSS などのコンプライアンス標準に対応した事前定義のポスチャー テンプレートが用意されており、これに社内独自のカスタム ポリシーを追加できます。さらにデプロイ後にポスチャーからの逸脱（ドリフト）が起きると、SCC の検出結果として報告されます。セキュリティ ポスチャー サービスは SCC の Premium ティア（または Enterprise ティア）で利用できます。

②要件と制約語の整理
・対象は特定のフォルダ。
・構成ミスを「防止」し、かつ「検出」する（予防と検出の両方）。
・「業界固有のコンプライアンス ポリシー」と「社内独自のポリシー」の両方を遵守する。

③正解の理由
A のポスチャーは、事前定義のポリシー（業界標準のテンプレート）とカスタム ポリシー（社内独自のルール）を1つのポスチャー ファイルにまとめ、組織のポリシーで「防止」、SHA の検出器で「検出」を同時に実現し、フォルダ レベルにデプロイできます。ドリフトの検出により継続的なセキュリティ管理にもなります。すべての要件を1つのマネージドな仕組みで満たすのは A だけです。

【誤りの選択肢】
B：カスタムの組織のポリシーは構成ミスの「防止」には有効ですが、既存のリソースの構成ミスを継続的に「検出」する仕組みではありません。また社内のビジネス要件だけを対象にしており、業界固有のコンプライアンス ポリシー（事前定義の標準）への準拠をカバーしていません。
C：Assured Workloads は、FedRAMP、ITAR、データ主権などの規制に必要なデータ所在地や担当者のアクセス制御などを、コントロール パッケージとしてフォルダに適用する仕組みです。業界規制への対応には役立ちますが、社内独自のポリシーを定義して構成ミスを防止・検出する機能ではなく、要件の一部しか満たしません。
D：Workload Manager は SAP などのワークロードのベスト プラクティス評価や、Rego で書いたカスタムルールによるリソース構成の定期評価ができるサービスですが、行えるのは評価（検出）だけで、違反する構成変更を「防止」することはできません。業界標準の事前定義テンプレートを予防・検出の両面で適用できるポスチャーに比べて要件を満たしません。

【参考】
セキュリティ ポスチャーの概要 | Security Command Center
セキュリティ ポスチャーを管理する | Security Command Center
この問題のページを開く →
問題 10組織のユーザーが、他の Google Cloud 組織にある Cloud Storage バケットにアクセスできないよう…アクセスの構成
問題
あなたは組織の Google Cloud 環境における Identity and Access Management（IAM）の構成を担当しています。組織のユーザーが、他の Google Cloud 組織にある Cloud Storage バケットにアクセスできないように制限する必要があります。どうすればよいですか。

選択肢と解説

  • ✓
    適切な適用バージョン（enforcement version）を指定したプリンシパル アクセス境界（PAB）ポリシーを設定する。そのポリシーを組織のプリンシパルにバインドする。
  • 2
    環境に組織内アクセス制限（organization restriction）ヘッダーを構成する。許可するリソースのリストには自組織の組織 ID のみを含める。
  • 3
    組織外の Cloud Storage バケットへのアクセスを禁止する IAM 拒否ポリシーを組織レベルで作成する。
  • 4
    組織でドメインで制限された共有（domain restricted sharing）を適用する。マネージド制約を構成し、自組織のプリンシパルのみを含める。

解説

【正解】A

【0からの解説】
①前提知識：IAM の主なポリシーは「どこに付けるか」と「何を制御するか」で区別すると理解しやすくなります。
・許可ポリシー／拒否ポリシー：リソース（組織・フォルダ・プロジェクト・バケットなど）に付け、「このリソースに誰がアクセスできるか／できないか」を決めます。つまり自分が管理するリソースへのアクセスしか制御できません。
・プリンシパル アクセス境界（PAB）ポリシー：プリンシパル（ユーザーやサービス アカウントの集合＝プリンシパル セット）の側に付け、「このプリンシパルがアクセスできる可能性のあるリソースの範囲」を定義します。境界外のリソースに対しては、たとえ相手の組織が許可ポリシーで権限を付与していてもアクセスがブロックされます。公式ドキュメントでも、自組織のプリンシパルが他の組織のリソースにアクセスするのを防ぐ（フィッシングやデータ漏洩のリスクを下げる）用途が挙げられています。バインド先には組織のプリンシパル セット、Workforce Identity プール、Google Workspace ドメインなどを指定できます。
・適用バージョン（enforcement version）：PAB ポリシーがブロックできる権限の範囲はポリシーの適用バージョンで決まります。Cloud Storage では、バージョン 1 に storage.googleapis.com/objects.get や buckets.get などの主要な権限が含まれ、バージョン 2 で objects.* や buckets.* などのワイルドカードに広がります。新しい権限が意図せずブロックされないよう、latest ではなく必要なバージョンを明示することが推奨されています。

②要件の整理：「IAM の構成」の範囲で、「自組織のユーザー」が「他組織の Cloud Storage バケット」にアクセスするのを防ぐ必要があります。つまり、自分が管理していない（他組織の）リソースへのアクセスを、プリンシパル側から制限しなければなりません。

③正解の理由：自組織のリソースだけを含めた PAB ポリシーを作成し、Cloud Storage の権限をブロックできる適用バージョンを指定して、自組織のプリンシパル セットにバインドします。これにより、自組織のユーザーは他組織のバケットに対して権限を付与されていてもアクセスできなくなります。ネットワーク構成に依存せず、IAM の機能だけで実現できる点が要件に合致します。なお、プリンシパル アクセス境界は比較的新しく追加された IAM の機能です。それ以前は、他組織のリソースへのアクセスを制限する代表的な手段は B の組織内アクセス制限でした。

【誤りの選択肢】
B：組織内アクセス制限（organization restriction）は、社内の下り（外向き）プロキシで HTTP ヘッダー（X-Goog-Allowed-Resources）を付与し、許可した組織以外のリソースへのアクセスを拒否する仕組みです。外部の組織へのアクセスを制限できるという点では、この方法でも目的は果たせます。違いは「何を基準に制限するか」です。組織内アクセス制限は「社内の管理対象ネットワーク・デバイスから出ていく通信」を基準にし、そのプロキシを通る通信であれば誰のアカウント（個人の Google アカウントなど自組織以外のアカウントを含む）でも外部組織へのアクセスを止めます。データ持ち出し対策として社内ネットワークを守りたい場合に向いています。一方、PAB は「自組織のプリンシパル」を基準にし、そのユーザーがどのネットワークからアクセスしても外部組織のリソースに届かないようにします。本問の要件は「IAM の構成」として「組織のユーザー」を制限することなので、プロキシの導入とヘッダー挿入というネットワーク側の構成を前提とし、そのプロキシを経由しない通信（社外ネットワークや個人端末からのアクセスなど）には効かない B より、プリンシパル自体に境界を設定できる A が適しています。
C：IAM 拒否ポリシーは、ポリシーを付けたリソース（自組織の組織・フォルダ・プロジェクト）とその配下へのアクセスを拒否するものです。他組織のバケットは自組織のリソース階層の外にあるため、自組織に付けた拒否ポリシーでは制御できません。
D：ドメインで制限された共有は、自組織のリソースの許可ポリシーに外部ドメインのプリンシパルが追加されるのを防ぐ組織のポリシーの制約です。防ぐのは「外部のユーザーが自組織のリソースに入ってくること」であり、制御の方向が逆です。自組織のユーザーが他組織のリソースへアクセスすることは防げません。

【参考】
プリンシパル アクセス境界ポリシー | Identity and Access Management (IAM)
プリンシパル アクセス境界ポリシーの作成と適用 | Identity and Access Management (IAM)
組織内アクセス制限の概要 | Resource Manager
この問題のページを開く →
問題 11コンプライアンス要件を満たすため、既存のデータを顧客管理の暗号鍵（CMEK）を使用するように更新する必要があります。データ保護の確保
問題
あなたの組織は、規制対象のデータを Cloud Storage に保存しています。Cloud Storage バケット内のデータは Google が管理する暗号鍵で暗号化されています。コンプライアンス要件を満たすため、既存のデータを顧客管理の暗号鍵（CMEK）を使用するように更新する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    Cloud Key Management Service で新しいキーリングと鍵を作成する。各 Cloud Storage バケットの構成で、暗号化タイプを顧客管理の暗号鍵に変更する。
  • 2
    規制対象のデータを含む Cloud Storage バケットがどのプロジェクトにあるかを特定する。特定したプロジェクトまたはその親フォルダに restrictNonCmekServices 組織のポリシーの制約を適用する。
  • 3
    Cloud Key Management Service で新しいキーリングと鍵を作成する。規制対象のデータを含む Cloud Storage バケットがどのプロジェクトにあるかを特定する。バケット内のすべての既存オブジェクトに対して書き込み操作を実行する。
  • ✓
    顧客管理の暗号鍵を作成する。各 Cloud Storage バケットの構成で、暗号化タイプを新しく作成した鍵に変更する。バケット内のすべての既存オブジェクトに対して書き込み操作を実行する。

解説

【正解】D

【0からの解説】
①前提知識：
・Cloud Storage のデータは、何も設定しなくても Google が管理する暗号鍵で保存時に自動的に暗号化されています。
・顧客管理の暗号鍵（CMEK）：Cloud Key Management Service（Cloud KMS）で自社が作成・管理する鍵を使って暗号化する方式です。鍵のローテーション周期、無効化・破棄、鍵へのアクセス権を自社で制御でき、規制対応でよく求められます。Cloud Storage で使うには、Cloud Storage のサービス エージェントに鍵の暗号化／復号のロール（Cloud KMS 暗号鍵の暗号化／復号）を付与します。
・バケットのデフォルトの鍵（default KMS key）：バケットに CMEK をデフォルトの鍵として設定できます。ただしこの設定が適用されるのは「設定後に新しく書き込まれるオブジェクト」で、既存のオブジェクトは自動では再暗号化されません。既存のオブジェクトを CMEK に切り替えるには、オブジェクトを書き換える（rewrite する。例：gcloud storage objects update に --encryption-key を指定する）必要があります。

②要件の整理：求められているのは「既存のデータ」を CMEK で暗号化された状態に更新することです。あわせて、今後書き込まれるデータも CMEK で暗号化されることが望まれます。

③正解の理由：(1) Cloud KMS で CMEK を作成し、(2) 各バケットのデフォルトの暗号鍵をその CMEK に変更して今後の書き込みを CMEK で暗号化し、(3) 既存のオブジェクトに書き込み（書き換え）操作を行って CMEK で再暗号化する、という手順で既存データと新規データの両方が CMEK で保護されます。D はこの必要な手順をすべて含んでいます。

【誤りの選択肢】
A：バケットのデフォルトの鍵を変更するだけでは、変更後に書き込まれるオブジェクトにしか CMEK が適用されません。既存のオブジェクトは Google 管理の鍵のままなので、「既存のデータを更新する」という要件を満たしません。
B：restrictNonCmekServices（constraints/gcp.restrictNonCmekServices）は、指定したサービスで CMEK を使わないリソースの「新規作成」を禁止する予防的な組織のポリシーの制約です。既存のバケットやオブジェクトを再暗号化する効果はないため、要件を満たしません。
C：鍵を作成しても、バケットのデフォルトの鍵として設定しておらず、書き込み時にも鍵を指定していないため、既存オブジェクトを書き換えても再び Google 管理の鍵で暗号化されるだけです。CMEK への切り替えが行われません。

【参考】
顧客管理の暗号鍵を使用する | Cloud Storage
顧客管理の暗号鍵 | Cloud Storage
この問題のページを開く →
問題 12クラウド上のフロントエンドとオンプレミスのバックエンドおよびデータベースとの間で、レイテンシを最小限に抑え可用性を最大化…通信の保護と境界保護の確立
問題
あなたの会社は、3 層構造のウェブ アプリケーションを Google Cloud に移行しています。アプリケーションは、ウェブ フロントエンド、アプリケーション バックエンド、データベースで構成されています。規制要件と既存のオンプレミス インフラストラクチャへの依存関係により、ハイブリッド クラウド アーキテクチャを実装する必要があります。ウェブ フロントエンドは Google Cloud でホストし、アプリケーション バックエンドとデータベースは当初はオンプレミスに残します。クラウド上のフロントエンドとオンプレミスのバックエンドおよびデータベースとの間で、レイテンシを最小限に抑え可用性を最大化しながら、安全かつ効率的な通信を確保する必要があります。どうすればよいですか。

選択肢と解説

  • ✓
    Google Cloud の VPC ネットワークとオンプレミス ネットワークの間に Dedicated Interconnect 接続を確立する。3 つの層の間の通信を許可するファイアウォール ルールを構成する。
  • 2
    ウェブ フロントエンドをホストする Google Cloud の VPC ネットワークと、バックエンドとデータベースをホストするオンプレミス ネットワークとの間に、直接のインターネット接続を確立する。3 つの層の間の通信を許可するファイアウォール ルールを構成する。
  • 3
    オンプレミスのバックエンドとデータベースを Google Cloud に複製する。プライマリにはハイブリッド接続ネットワーク エンドポイント グループを使用する。ゾーン ネットワーク エンドポイント グループにバックアップする。
  • 4
    公共のインターネットを経由する高可用性の Cloud VPN 接続を使用して、Google Cloud の VPC ネットワークをオンプレミス ネットワークに接続する。

解説

【正解】A

【0からの解説】
①前提知識：オンプレミスと Google Cloud の VPC ネットワークをプライベートに接続する主な方法は 2 つです。
・Cloud Interconnect（Dedicated Interconnect／Partner Interconnect）：オンプレミスと Google のネットワークを物理回線で直接（Partner Interconnect はサービス プロバイダ経由で）接続します。公式ドキュメントでも「低レイテンシで高可用性の接続」と説明されており、トラフィックは公共のインターネットを経由しません。Dedicated Interconnect は 10 Gbps／100 Gbps などの回線単位で大きな帯域を確保でき、Google が定義する冗長トポロジで構成すると 99.9％／99.99％ の SLA が提供されます。なお Cloud Interconnect はデフォルトでは通信を暗号化しないため、必要に応じて MACsec や HA VPN over Cloud Interconnect で暗号化を追加します。
・Cloud VPN（HA VPN）：公共のインターネット上に IPsec トンネルを張る方式です。通信は暗号化され、HA VPN は構成に応じて 99.99％ の SLA がありますが、インターネットを経由するためレイテンシや帯域が変動しやすく、トンネルあたりの帯域にも上限があります。帯域の要件が小さく低コストで済ませたい場合に向いています。

②要件の整理：フロントエンド（クラウド）とバックエンド／データベース（オンプレミス）の間で、(1) 安全、(2) 効率的、(3) レイテンシを最小限、(4) 可用性を最大化、の通信が必要です。ウェブ アプリの各リクエストがオンプレミスのバックエンドやデータベースを呼び出すため、特にレイテンシと安定性が重要です。

③正解の理由：Dedicated Interconnect は公共のインターネットを経由しない専用のプライベート接続で、低レイテンシ・高帯域・安定した品質を提供し、冗長構成により高い可用性も確保できます。さらにファイアウォール ルールで各層の間に必要な通信だけを許可することで、ネットワークのセグメンテーションも実現できます。これが「レイテンシ最小」「可用性最大」「安全」「効率的」という要件全体を最もよく満たします（本番では 99.99％ の冗長トポロジで構成し、暗号化の要件があれば MACsec などを追加するのがベスト プラクティスです）。
補足（「安全」の根拠）：Dedicated Interconnect の回線自体は、デフォルトでは通信を暗号化しません。それでもここで「安全」と言えるのは、通信が公共のインターネットを通らず、自社と Google の間の専用の物理回線だけを流れるため、インターネット上での盗聴や攻撃にさらされないからです。規制などで経路上の暗号化も必須な場合は、(1) Cloud Interconnect 用の MACsec を有効にしてオンプレミスのルーターと Google のエッジ ルーターの間（レイヤ 2）を暗号化する、(2) HA VPN over Cloud Interconnect を構成して Interconnect の上に IPsec トンネルを張る、のいずれかを追加します。どちらもインターネットを経由しないまま暗号化を加えられるため、D のようにインターネット経由の VPN を選ぶ必要はありません。

【誤りの選択肢】
B：「直接のインターネット接続」では、バックエンドやデータベースとの通信を公共のインターネットにさらすことになり、安全性の要件を満たしません。レイテンシや可用性も保証されません。
C：バックエンドとデータベースを Google Cloud に複製するのは、「当初はオンプレミスに残す」という前提（規制要件・依存関係）に反します。またハイブリッド接続ネットワーク エンドポイント グループ（NEG）は、ロードバランサからオンプレミスなどのエンドポイントにトラフィックを振り分けるための仕組みで、それ自体がクラウドとオンプレミスの間の接続回線を提供するものではありません（Cloud VPN や Cloud Interconnect が別途必要です）。
D：HA VPN は暗号化され高い SLA もある安全な選択肢ですが、公共のインターネットを経由するためレイテンシが変動しやすく、帯域にも制約があります。「レイテンシを最小限に」「効率的」という要件では、専用の物理接続である Dedicated Interconnect に劣ります。

【参考】
Network Connectivity プロダクトの選択
Cloud Interconnect を介した HA VPN の概要
Cloud VPN の概要
この問題のページを開く →
問題 13脆弱性のリスクと管理作業を最小限に抑えるため、すべての GKE ノードが常に最新のリリースを実行するようにする必要があり…運用の管理
問題
あなたの組織は、異なるフォルダとプロジェクトにまたがって、ビジネス アプリケーションを実行する多数の Google Kubernetes Engine（GKE）クラスタをデプロイする予定です。脆弱性のリスクと管理作業を最小限に抑えるため、すべての GKE ノードが常に最新のリリースを実行するようにする必要があります。どうすればよいですか。

選択肢と解説

  • 1
    クラスタの作成後に、Google Cloud コンソールで gcloud container node-pools describe NODE_POOL_NAME --cluster=CLUSTER_NAME コマンドを使用する。出力の upgradeSettings と UpdateInfo を確認する。
  • ✓
    デプロイ前に、組織レベルで、アクション タイプを ALLOW としたカスタムの組織のポリシーの制約 resource.management.autoUpgrade == true を作成する。
  • 3
    各クラスタで新しいバージョンの新しいノードプールを作成する。ワークロードを移行する。古いノードプールを削除する。
  • 4
    新しく作成したクラスタに対して、Google Cloud コンソールで gcloud container clusters upgrade CLUSTER_NAME --node-pool=NODE_POOL_NAME --cluster-version VERSION コマンドを定期的に手動で実行する。

解説

【正解】B

【0からの解説】
①前提知識：
・GKE のノードの自動アップグレード：ノードプールの設定 management.autoUpgrade を有効にすると、GKE がコントロール プレーンのバージョンやリリース チャンネルに合わせてノードを自動的にアップグレードし、セキュリティ パッチが適用されたバージョンを維持します。Google はセキュリティ パッチを迅速に反映するため、自動アップグレードの利用を推奨しています。
・カスタムの組織のポリシー（カスタム制約）：組織のポリシー サービスで、リソースのフィールドに対する条件を CEL 式で記述し、リソースの作成時（CREATE）や更新時（UPDATE）に強制できる機能です。GKE では container.googleapis.com/Cluster や container.googleapis.com/NodePool のフィールドを条件にできます。actionType が ALLOW の場合は「条件を満たすリソースだけを許可（それ以外はブロック）」、DENY の場合は「条件を満たすリソースを拒否」となります。組織やフォルダに適用したポリシーは、配下のすべてのプロジェクトに継承されます。

②要件の整理：多数のクラスタがさまざまなフォルダ・プロジェクトに作られる予定で、(1) すべてのノードが常に最新のリリースを実行して脆弱性リスクを下げる、(2) 管理作業を最小限にする、という 2 つの要件があります。「デプロイ前に」「大規模に」「漏れなく」強制できる仕組みが必要です。

③正解の理由：resourceTypes に container.googleapis.com/NodePool、condition に resource.management.autoUpgrade == true、actionType に ALLOW を指定したカスタム制約を作成し、組織レベルで適用すると、ノードの自動アップグレードが無効なノードプールは作成できなくなります（GKE の公式ドキュメントにも「すべてのノードプールでノードの自動アップグレードを有効にする」例としてこの制約が掲載されています）。これにより、どのチームがどのフォルダ・プロジェクトでクラスタを作っても必ず自動アップグレードが有効になり、以降のアップグレードは GKE が自動で行うため手作業も不要です。

【誤りの選択肢】
A：describe コマンドはノードプールの設定やアップグレードの情報を「確認」するだけで、最新リリースの実行を強制も自動化もしません。多数のクラスタを個別に確認する作業も発生し、管理作業の最小化にも反します。
C：新しいノードプールを作ってワークロードを移行し、古いノードプールを削除する方法（手動の Blue/Green 移行）は、アップグレードの手段としては有効です。しかしクラスタごと・リリースごとに繰り返す必要があり管理作業が非常に大きく、「常に最新」を継続的に保証する仕組みにもなりません。
D：upgrade コマンドを定期的に手動で実行する方法は作業負荷が大きく、実行漏れや遅れがあるとその間は脆弱なバージョンのまま残ります。多数のクラスタを対象とし、管理作業を最小限にするという要件に適しません。

【参考】
カスタム制約を作成する | Organization Policy
セキュリティ パッチ | GKE security
この問題のページを開く →
問題 14この特定のワークロードについて、EU 以外の場所でのリソースの作成を制限する必要があります。コンプライアンス要件への対応
問題
あなたの組織には、欧州の法律によって規制されているワークロードがあります。この特定のワークロードについて、EU 以外の場所でのリソースの作成を制限する必要があります。他のグローバル アプリケーションに支障を与えることなく、このセキュリティ管理策を実装する効果的な方法を見つけなければなりません。どうすればよいですか。

選択肢と解説

  • 1
    アセットの作成時にトリガーされ、EU 以外のリソースを検出して削除する Cloud Function を作成する。
  • 2
    ワークロードのすべてのアセットを、1 つのプロジェクトまたはフォルダ内の EU のリージョン サブネットに作成する。
  • 3
    VPC Service Controls を使用して、ワークロードを 1 つのプロジェクトまたはフォルダとして EU 内にセグメント化する。
  • ✓
    ワークロードのプロジェクトまたはフォルダに対して、ロケーションとして EU のみを許可する組織のポリシーを実装する。

解説

【正解】D

【0からの解説】
①前提知識
・組織のポリシー サービス：組織・フォルダ・プロジェクトというリソース階層に対して、作成できるリソースや使える設定を一元的に制約する仕組みです。ポリシーは階層の下位へ継承され、特定のフォルダやプロジェクトにだけ設定することもできます。
・リソース ロケーションの制限（制約 gcp.resourceLocations）：ロケーションを持つリソースを作成できる場所を制限する組織のポリシーの制約です。例えば値グループ in:eu-locations を許可値にすれば、EU のロケーション（EU のリージョンやマルチリージョン eu など）だけを許可でき、それ以外のロケーションでの作成リクエストは実行時にエラーで拒否されます。既存のリソースには遡って適用されない点に注意します。

②要件の整理
・欧州の法律で規制されたワークロードについて、EU 以外でのリソース作成を「制限」したい（予防的な統制）
・このワークロードだけに適用し、他のグローバル アプリケーションには支障を与えない
・効果的な方法

③正解の理由
規制対象のワークロードを専用のプロジェクトまたはフォルダにまとめ、そこにだけ gcp.resourceLocations で EU のロケーションのみを許可する組織のポリシーを設定すれば、EU 以外でのリソース作成は作成時点で拒否されます。ポリシーはそのフォルダ／プロジェクト（とその配下）にのみ適用されるため、他のグローバル アプリケーションには影響しません。コード不要の宣言的な設定で、Google が推奨するデータ所在地（データ レジデンシー）の対策です（より厳格な要件には、同様の制約をまとめて適用する Assured Workloads も利用できます）。

【誤りの選択肢】
A：Cloud Functions（現 Cloud Run functions）で作成後に検出して削除するのは事後対応（検出型）の仕組みであり、作成そのものを制限できません。削除されるまでの間はデータが EU 外に存在し得るうえ、独自コードの開発・保守が必要で、検出漏れや削除失敗のリスクもあります。組織のポリシーに比べて効果的とはいえません。
B：EU のリージョン サブネットに作成するのは運用上の取り決めにすぎず、Cloud Storage バケットや BigQuery データセットなどサブネットと関係のないリソースは任意のロケーションに作成できてしまいます。EU 外での作成を技術的に禁止する仕組みになっていません。
C：VPC Service Controls は、サービス境界によって Google Cloud サービスの API へのアクセスを制御し、データの引き出し（流出）を防ぐ仕組みです。リソースを作成できる地理的なロケーションを制限する機能ではないため、要件を満たしません。

【参考】
リソースのロケーションを制限する | Organization Policy
この問題のページを開く →
問題 15Cloud Identity の特権管理者（Super admins）に対して、2 段階認証プロセス（2SV）を適用する…アクセスの構成
問題
あなたの組織では現在、ユーザー名とパスワードのみで認証を行うサードパーティの ID プロバイダ（IdP）を使用しています。Cloud Identity の特権管理者（Super admins）に対して、2 段階認証プロセス（2SV）を適用する必要があります。どうすればよいですか。

選択肢と解説

  • ✓
    特権管理者用の組織部門（OU）を作成し、その OU に対して Cloud Identity で 2SV を有効にする。
  • 2
    現在の Cloud Identity の構成を維持したまま、サードパーティ IdP と連携して特権管理者の 2SV を有効にする。
  • 3
    特権管理者が Cloud Identity で使用している認証方法を追跡する監視ツールを導入する。2SV を使用していない場合にアラートを出す。
  • 4
    サードパーティ IdP と Cloud Identity の両方が特権管理者向けに提供している 2SV のオプションを評価する。最も強力な 2 番目の要素を提供するソリューションを実装する。

解説

【正解】A

【0からの解説】
①前提知識
・Cloud Identity：Google Cloud のユーザーやグループを管理する ID サービス（IDaaS）です。管理コンソールで、組織部門（OU）やグループ単位にセキュリティ設定（2SV の適用など）を行えます。
・特権管理者（Super admin）：Cloud Identity / Google Workspace アカウントのすべてを操作できる最も強い権限を持つアカウントです。Google は、特権管理者アカウントに多要素認証を適用し、セキュリティ キーなどの物理的な認証デバイスで 2SV を強制することを推奨しています。
・サードパーティ IdP によるシングル サインオン（SSO）と特権管理者：SSO を構成していても、特権管理者が admin.google.com からログインする場合は IdP にリダイレクトされず、Google アカウントのメールアドレスと Google のパスワードで直接サインインします。また、特権管理者の SSO は従来の SSO プロファイルの一部のケースでしかサポートされず、新しい SSO プロファイルではサポートされていません。つまり特権管理者の認証は Cloud Identity（Google）側で行われるため、2SV も Cloud Identity 側で適用する必要があります。
・2SV の適用範囲：Cloud Identity では、2SV の有効化と「適用（強制）」を OU 単位またはグループ単位で設定できます。

②要件の整理
・現在の IdP はユーザー名とパスワードのみ（2 つ目の要素がない）
・Cloud Identity の特権管理者に 2SV を「適用（強制）」したい

③正解の理由
特権管理者は IdP を経由せずに Google で直接認証されるため、IdP 側の設定では特権管理者のログインを制御できません。特権管理者用の OU を作成して特権管理者を配置し、その OU に対して Cloud Identity の 2SV を有効化・適用すれば、一般ユーザーの SSO 構成に影響を与えずに、特権管理者だけに 2SV を確実に強制できます。2 つ目の要素にはセキュリティ キーを指定するのが推奨です。

【誤りの選択肢】
B：特権管理者は admin.google.com へのログイン時に IdP を経由せず Google のパスワードで認証されるため、IdP 側で 2SV を有効にしても、その経路のログインには 2SV がかかりません（現在の IdP がパスワードのみであることも踏まえると、IdP 側の対応だけでは不十分です）。「Cloud Identity の構成を維持したまま」では要件を満たせません。
C：監視とアラートは事後に検知する仕組みにすぎず、2SV を「適用（強制）」するものではありません。2SV を使っていない特権管理者のログイン自体は防げないため、要件を満たしません。
D：一見もっともらしい選択肢ですが、評価したうえで「どちらか一方」を実装する方針です。IdP 側の 2SV を選んだ場合、IdP を経由しない特権管理者のログインには効きません。Google は特権管理者の SSO を使う場合でも IdP と Google の両方で 2SV を有効にするよう推奨しており、少なくとも Cloud Identity 側での適用は必須です。要件である「Cloud Identity で特権管理者に 2SV を適用する」に直接答えているのは A です。

【参考】
特権管理者アカウントのベスト プラクティス | Resource Manager
シングル サインオン
この問題のページを開く →

GCP-PCSE 模擬問題集についてよくある質問

GCP-PCSE の練習問題は無料で試せますか？

はい。GCP-PCSE は先頭 15 問を会員登録なしで、正解と全選択肢の解説つきでご覧いただけます。16 問目以降は模試プラン（月額 ¥980）または Pro プラン（月額 ¥4,980）でご利用ください。

問題は何問ありますか？

GCP-PCSE は本番形式の練習テスト 4 回・全 200 問を収録しています。全問に解説が付いています。

解説は付いていますか？

全ての問題に、正解の理由と各選択肢がなぜ誤りなのかの解説を付けています。ドメイン（出題分野）別の正答率も受験後に確認できます。