模擬問題集一覧

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

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

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

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

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

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

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

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

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

問題 1クラウド ソリューション アーキテクチャの設計と計画クラウド ソリューション アーキテクチャの設計と計画
問題
あなたの勤務先は金融サービス企業で、最近、人気のフィンテック スタートアップを買収しました。このスタートアップの中核アプリケーションは、Compute Engine 仮想マシンのマネージド インスタンス グループ上で稼働するモノリシックな Python アプリケーションで、単一の大規模な PostgreSQL データベースを使用しています。開発チームはデプロイ サイクルの遅さに苦しんでおり、スタートアップの中核アプリケーションのモノリシックな設計が、ML を活用した新しい不正検出モデルの統合を困難にしています。開発者の俊敏性を向上させ、将来のイノベーションに向けて Google Cloud の高度なデータ機能と AI 機能を活用できる体制を整える、長期的な戦略が必要です。 どうすればよいですか？

選択肢と解説

  • 1
    ML 不正検出モデルを Vertex AI エンドポイントにデプロイする。モデル用の REST API を作成し、リアルタイムの不正分析のためにこのエンドポイントを呼び出すようにモノリシックな Python アプリケーションを変更する。
  • 2
    アプリケーションをコンテナ化して Google Kubernetes Engine（GKE）にデプロイし、PostgreSQL データベースを Cloud SQL for PostgreSQL に移行する。
  • ✓
    マイクロサービス アーキテクチャへの段階的なイベント駆動型の移行を提案する。非同期通信には Pub/Sub を使用し、不正検出モデルは Vertex AI エンドポイントにデプロイする。
  • 4
    PostgreSQL データベースを Cloud SQL for PostgreSQL に移行する。Datastream を使用してデータを BigQuery に複製し、BigQuery ML を使用して BigQuery 内で直接、不正検出モデルをトレーニングしてデプロイする。

解説

【正解】C

【0からの解説】
① 前提知識
・モノリス: すべての機能が 1 つのアプリケーションにまとまった構成です。一部を変更しても全体をビルド・テスト・デプロイし直す必要があり、チームが大きくなるほどデプロイが遅くなります。
・マイクロサービス: 機能ごとに小さな独立したサービスへ分割し、それぞれを個別に開発・デプロイ・スケールできるようにする構成です。モノリスから一度に作り直すのではなく、機能を少しずつ切り出して移行する段階的なやり方（ストラングラー フィグ パターン）が推奨されます。
・イベント駆動型アーキテクチャと Pub/Sub: Pub/Sub はフルマネージドな非同期メッセージング サービスです。「取引が発生した」などのイベントを Pub/Sub に発行し、関心のあるサービス（不正検出、通知、分析など）がそれぞれ購読することで、サービス同士を疎結合に保てます。新しい機能はイベントを購読するサービスを追加するだけで組み込めます。
・Vertex AI（現 Gemini Enterprise Agent Platform）エンドポイント: トレーニング済みモデルをデプロイし、オンライン予測（リアルタイム推論）を API として提供するマネージドな仕組みです。

② 要件と制約語の整理
・課題: デプロイ サイクルが遅い／モノリシックな設計が ML 不正検出モデルの統合を妨げている。
・求められているのは「長期的な戦略」であり、「開発者の俊敏性の向上」と「将来のイノベーションに向けて Google Cloud の高度なデータ・AI 機能を活用できる体制」の両方を満たす必要があります。目先の機能追加ではなく、アーキテクチャの根本的な改善が問われています。

③ 正解 C が要件をどう満たすか
・段階的なマイクロサービス化により、サービスごとに独立してデプロイできるようになり、デプロイ サイクルの遅さという根本原因を解消します。段階的に進めるため、買収直後の本番システムを止めるリスクも抑えられます。
・Pub/Sub によるイベント駆動の疎結合な構成にすることで、不正検出モデルを含む新しい ML 機能を、既存サービスを改修せずにイベントの購読者として追加できます。同じイベントを BigQuery などの分析基盤へ流すことも容易で、将来のデータ・AI 活用の土台になります。
・不正検出モデルは Vertex AI エンドポイントにデプロイし、マネージドなスケーリング、モデルのバージョン管理、モニタリングを活用できます。

【誤りの選択肢】
A：モデルを Vertex AI エンドポイントで提供すること自体は有効ですが、モノリスはそのまま残るため、デプロイ サイクルの遅さという根本課題は解決しません。将来新しい AI 機能を追加するたびにモノリスを改修する必要があり、「長期的な戦略」「開発者の俊敏性の向上」の要件を満たさない短期的な対処にとどまります。
B：コンテナ化して GKE で動かし、データベースをマネージドな Cloud SQL に移すことで運用面は改善しますが、アプリケーションはモノリスのままです（いわゆるリフト＆シフトに近い移行）。1 つの大きなコンテナを丸ごとデプロイし直す構造は変わらず、デプロイの遅さや ML モデル統合の難しさは解消されません。
D：Datastream で BigQuery にデータを複製し、BigQuery ML でモデルを作るのはデータ分析基盤としては有効ですが、アプリケーションのモノリシックな構造や開発者の俊敏性には一切手を付けていません。また、BigQuery ML の予測は BigQuery 上の SQL で実行する形が基本で、取引処理の流れの中でのリアルタイム不正検出をアプリケーションに組み込む課題も解決しません。

【参考】
学習プログラム: モノリスを GKE アプリに変換する - 概要 | Google Kubernetes Engine (GKE)
Pub/Sub とは
Agent Platform の概要
この問題のページを開く →
問題 2クラウド ソリューション インフラストラクチャの管理とプロビジョニングクラウド ソリューション インフラストラクチャの管理とプロビジョニング
問題
【ケーススタディ: KnightMotives Automotive】 ■会社概要 KnightMotives は、バッテリー式電気自動車（BEV）、ハイブリッド車、従来型の内燃機関（ICE）車を含む、自律走行（自動運転）車を専門とする自動車メーカーです。KnightMotives は BEV 車両群の車内体験では大きな進歩を遂げてきましたが、ハイブリッド車と ICE 車にはまだこれらの新しいシステムが実装されておらず、評論家やドライバーからの評価は低いままです。ハイブリッド車と ICE 車に最新の車載テクノロジーが欠けていることが、販売台数と顧客満足度の低下を招いています。 KnightMotives は、5 年以内にすべての車両で消費者体験をモダナイズしたいと考えています。人工知能（AI）は、車内体験だけでなく、ショッピング、購入、サービス / メンテナンスの体験に革命を起こす特別な機会をもたらします。この新しいテクノロジーへの投資には、グローバル規模での財務上の優先順位の転換が必要になります。 KnightMotives は、信頼性の低いオンライン注文システムの改善も望んでいます。顧客がオンラインで車両の仕様を組み立て（ビルドし）、ディーラーを通じて購入するためのシステムは、ディーラーが必要とするデータや信頼性を提供できておらず、KnightMotives とディーラーとの関係に緊張を生んでいます。サービス技術者や営業スタッフは、受注生産（ビルド トゥ オーダー）車両を含め、ディーラーの成功を後押しするためのより良いツールを必要としています。 ■ソリューションのコンセプト KnightMotives は、自動車の製造から、完全で魅力的な「自動車体験（automotive experience）」の創出へと転換したいと考えています。その戦略では、全モデルで一貫した体験の提供、AI を活用した機能の開発、データの収益化による新たな収益の創出、競合他社とブランドを差別化するためのデジタル重視の姿勢、そして整備士と営業担当者向けのより良いツールの開発を優先しています。 ■既存の技術環境 KnightMotives の IT は大部分がオンプレミスにあり、一部のアプリケーションが主要なクラウド プラットフォーム上で稼働しています。サプライチェーンは旧式のメインフレームで稼働しており、エンタープライズ リソース プランニング（ERP）も旧式であるため、新しいプロモーションやディーラー向け割引の実施が困難です。ディーラーには新しい機器を導入する予算がありません。車両ごとに複数のコードベースが存在する断片化があり、後方互換性のサポートによる多大な技術的負債を抱えています。製造工場へのネットワーク接続と、地方部での車両の接続性が課題となっています。 ■ビジネス要件 主なビジネス要件には、ドライバーとのパーソナライズされた関係を育むことと、全モデルで統一感のある体験を提供することが含まれます。より良い受注生産（ビルド トゥ オーダー）モデルを構築することで、車両がディーラーの在庫として留まる期間を短縮し、ディーラーと顧客の双方に透明性を提供します。さらに KnightMotives は、現在の AI インフラストラクチャが時代遅れで、企業データがサイロ化したままであるため、新しいテクノロジーへの投資資金を賄うために企業データを収益化しようとしています。過去のデータ侵害により、セキュリティは最重要の関心事です。特に新たに登場しつつある自動運転プラットフォームについては、欧州連合（EU）のデータ保護規制の遵守が不可欠です。 KnightMotives は完全自動運転機能に多額の投資を行う計画で、最初の導入は規制環境が好ましい地域を対象としています。従業員のスキルアップ、一流の人材の獲得、ビジネス チームと技術チームの間のより良いコミュニケーションの促進も、重要な目標です。 ■技術要件 ・車内体験のモダナイズには、全モデルで AI を活用した機能をシームレスに統合する一貫したユーザー エクスペリエンス（UX）の開発、新しい UX 機能と AI 機能をサポートするための旧モデルの車載ハードウェアとソフトウェアの更新、そしてリアルタイムの AI 機能とデータ送信をサポートするための、特に地方部での信頼性の高いネットワーク接続の確保が含まれます。 ・増加するデータ トラフィックに対応し、工場と本社の間の接続性を向上させるために、ネットワークのアップグレードが必要です。 ・IT インフラストラクチャのモダナイズには、オンプレミスとクラウドの両方のインフラストラクチャの利点を活用するハイブリッド クラウド戦略の採用と、効率性と俊敏性を向上させるためのレガシー システムの段階的なモダナイズまたは置き換えが必要です。 ・自動運転車の開発とテストには、最先端の AI と機械学習（ML）テクノロジーへの投資、堅牢なシミュレーション環境の構築、そして自動運転車に関する進化し続ける規制への準拠の確保が必要です。 ・データの収益化とインサイトの獲得には、堅牢なデータ管理プラットフォーム、厳格なデータ セキュリティとプライバシー対策、そしてスケーラブルな AI / ML インフラストラクチャの実装が必要です。 ・セキュリティとリスク管理への注力強化には、サイバー脅威とデータ侵害から保護するための包括的なセキュリティ フレームワークの実装、インシデント対応計画の策定、従業員へのセキュリティ意識向上トレーニングの提供が含まれます。 ・ディーラーと顧客に満足度の高い体験を提供するには、オンラインの受注生産（ビルド トゥ オーダー）システムの改善、販売・サービス・在庫管理を含むディーラー業務を効率化する最新のディーラー向けツールの開発、そして顧客とのやり取りを追跡し、体験をパーソナライズし、顧客満足度を向上させる包括的な顧客関係管理（CRM）システムの導入が必要です。 ■経営陣の声明 KnightMotives は、運転、道路状況、行動調査、衝突安全統計を網羅する膨大なデータを活用し、ドライバーにとって魅力的なデジタル体験を生み出すことで、安全性を高め、人命を救うことに尽力しています。当社の AI は一貫して国の安全統計を上回る成果を上げており、KnightMotives ならではの誰もが憧れる体験を、全車種でそろって提供できるようにしています。 ――KnightMotives CEO　Michael Knight 【設問】 この問題では、KnightMotives Automotive のケーススタディを参照してください。あなたは、Google Cloud 上の KnightMotives の新しい環境のネットワーク インフラストラクチャ アーキテクチャを設計する責任者です。新しい VPC トポロジを設計する必要があります。工場と Google Cloud リソースの間で、帯域幅の保証と低レイテンシを確保したいと考えています。 どうすればよいですか？

選択肢と解説

  • 1
    Standard Tier の VPC を作成し、工場に最も近いリージョンにサブネットが用意されていることを確認する。各サブネットと現地の工場の間に Cloud Interconnect を確立する。
  • 2
    Standard Tier の VPC を作成し、工場に最も近いリージョンにサブネットが用意されていることを確認する。Google のエッジ ネットワークと現地の工場の間に Direct Peering（ダイレクト ピアリング）を確立する。
  • ✓
    Premium Tier の VPC を作成し、工場に最も近いリージョンにサブネットが用意されていることを確認する。各サブネットと現地の工場の間に Cloud Interconnect を確立する。
  • 4
    Premium Tier の VPC を作成し、工場に最も近いリージョンにサブネットが用意されていることを確認する。Google のエッジ ネットワークと現地の工場の間に Direct Peering（ダイレクト ピアリング）を確立する。

解説

【正解】C

【0からの解説】
① 前提知識
・Network Service Tiers（ネットワーク サービス ティア）: Google Cloud のネットワーク品質の選択肢です。Premium Tier（デフォルト）では、トラフィックが可能な限り Google の高品質なグローバル バックボーン上を通り、ユーザーや拠点に最も近い Google のエッジから出入りするため、低レイテンシで安定した通信になります。Standard Tier はコストを優先し、トラフィックを一般のインターネット（ISP の網）経由でリージョンまで運ぶため、性能と安定性は Premium より劣ります。
・選択肢の「Premium Tier の VPC」「Standard Tier の VPC」という表現の読み替え: 実際の Google Cloud では、VPC ネットワーク自体にティアの設定項目はありません。ティアはプロジェクト単位（そのプロジェクトの既定ティア）とリソース単位（外部 IP アドレス、ロードバランサの転送ルール、VM インスタンスなど。両方設定した場合はリソース単位の設定が優先）で指定します。また、ティアが効くのは外部 IP アドレスを使うインターネット向けの通信で、VPC 内で内部 IP アドレスを使う通信は常に Premium Tier 相当の Google のネットワーク基盤を通ります。したがって本問の「〇〇 Tier の VPC を作成する」は、「その VPC を置くプロジェクトの既定ティアと、VPC 内のリソースの外部 IP アドレスを〇〇 Tier で構成する」という意味、つまり「ネットワーク全体を性能重視の Premium でそろえるか、コスト重視の Standard にするか」という設計方針の選択と読み替えて解きます。
・Cloud Interconnect: オンプレミス拠点と Google Cloud の VPC を、公共のインターネットを経由せずに接続するサービスです。物理回線を直接引き込む Dedicated Interconnect（10 Gbps / 100 Gbps 回線）と、サービス プロバイダ経由の Partner Interconnect（50 Mbps〜50 Gbps）があり、契約した帯域が確保され、冗長構成をとれば SLA（最大 99.99%）で可用性が保証されます。VPC の内部 IP アドレスで直接通信でき、VLAN アタッチメントと Cloud Router を通じて、リージョン内のサブネットへ経路が広告されます。
・Direct Peering（ダイレクト ピアリング）: Google のエッジ ネットワークと直接 BGP ピアリングを行い、Google Workspace や Google API の公開 IP アドレスへのトラフィックを効率化する仕組みです。Google Cloud の外側にある仕組みで、VPC 内のプライベート IP へは到達できず、SLA もありません。

② 要件と制約語の整理
・ケーススタディには「製造工場へのネットワーク接続が課題」「工場と本社の間の接続性を改善するネットワークのアップグレードが必要」「ハイブリッド クラウド戦略を採用」とあります。
・問題文の制約語は「帯域幅の保証（guaranteed bandwidth）」と「低レイテンシ」です。

③ 正解 C が要件をどう満たすか
・Cloud Interconnect は契約した容量の専用 / パートナー接続を提供し、SLA に裏付けられた安定した帯域で工場と VPC を内部 IP で結べます。インターネットの混雑の影響を受けないため「帯域幅の保証」を満たします。
・Premium Tier により、Google Cloud 側のトラフィックが Google のグローバル バックボーン上を通るため、レイテンシが最小化されます。
・各工場の最寄りのリージョンにサブネットを置き、そのリージョンで Interconnect を終端することで、工場から Google Cloud リソースまでの物理的な距離も短くなり、低レイテンシ要件を補強します。

【誤りの選択肢】
A：Cloud Interconnect の選択は正しいものの、Standard Tier はコストを優先してトラフィックを一般のインターネット経由で運ぶティアで、レイテンシと安定性は Premium Tier より劣ります。「低レイテンシ」の要件を最大限に満たす設計とは言えません。
B：Direct Peering は Google Workspace や Google API の公開 IP 向けの接続で、VPC 内のリソースへプライベートに接続する手段ではなく、SLA もないため帯域幅を保証できません。加えて Standard Tier では低レイテンシ要件も満たしにくく、二重に要件を外しています。
D：Premium Tier の選択は適切ですが、Direct Peering は帯域保証や SLA がなく、VPC 内のプライベート リソースへも到達できないため、「工場と Google Cloud リソースの間の帯域保証」という要件を満たせません。Google は Google Cloud リソースへのハイブリッド接続には Cloud Interconnect または Cloud VPN を推奨しています。

【参考】
Cloud Interconnect の概要
ダイレクト ピアリングの概要 | Network Connectivity
Network Connectivity プロダクトの選択
この問題のページを開く →
問題 3セキュリティとコンプライアンスのための設計セキュリティとコンプライアンスのための設計
問題
ある大規模な多国籍企業が Google Cloud への移行を進めています。この会社には、財務（Finance）、マーケティング（Marketing）、研究開発（R&D）という独立した複数の事業部門があります。中央のセキュリティ チームは、事業部門ごとに次のガバナンス要件を義務付けています。 ・Finance: リソースのデプロイは、コンプライアンスに準拠した特定のリージョン（us-central1 と europe-west2）のみに制限されなければならない。プロジェクトへのアクセスは、専任の finance-admins グループによって厳格に管理されなければならない。 ・Marketing: 本番環境と開発環境を分離し、それぞれの環境を異なるチームが管理する必要がある。 ・R&D: 新しいサービスを試すために最大限の柔軟性が必要だが、本番システムに一切影響を与えないよう完全に分離されていなければならない。 ・全社監査（Global Auditing）: 中央のコンプライアンス チームは、監査目的で全社のすべてのリソースを閲覧できる読み取り専用アクセスを必要とする。 Google Cloud Well-Architected Framework に従って、これらのセキュリティ ポリシーを大規模に適用しつつ、各事業部門に適切なレベルの自律性を与えるリソース階層を設計する必要があります。 どうすればよいですか？

選択肢と解説

  • ✓
    ルートの組織ノードの下に部門ごとのフォルダを作成する。Finance フォルダにリソース ロケーションの組織のポリシーを適用する。Marketing フォルダ内に mktg-prod と mktg-dev の別々のプロジェクトを作成する。コンプライアンス チームに組織レベルで roles/viewer ロールを付与する。
  • 2
    すべてのプロジェクトを組織ノードの直下に配置する。ネットワーク タグとサービス アカウントを使用して、異なる部門のワークロード間のセキュリティ境界を適用する。Finance のプロジェクトにリソース ロケーションの組織のポリシーを適用する。
  • 3
    部門（Finance、Marketing、R&D）ごとに別々の Google Cloud 組織を作成する。各組織でコンプライアンス チームに roles/viewer ロールを付与する。
  • 4
    部門ごとに 1 つのプロジェクトを作成する。Finance のプロジェクトにリソース ロケーションのポリシーを直接適用する。各プロジェクトでコンプライアンス チームに roles/browser ロールを個別に付与する。

解説

【正解】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 Manager
Google Cloud ランディング ゾーンのリソース階層を決定する
リソース階層を使用したアクセス制御 | Identity and Access Management (IAM)
この問題のページを開く →
問題 4技術プロセスとビジネス プロセスの分析と最適化技術プロセスとビジネス プロセスの分析と最適化
問題
あなたは、Terraform と Cloud Build を使用して、組織向けの一元化された自動インフラストラクチャ デプロイ プロセスを設計しています。セキュリティ チームは、あらゆる CI/CD パイプラインで有効期間の長い静的なサービス アカウント キーを使用することを禁止しています。また、開発者はインフラストラクチャの変更をピアレビューのために提案することはできますが、本番プロジェクトに変更を直接適用する権限を持ってはなりません。セキュリティ チームの要件を満たし、適切なガバナンスを確保する、Terraform の変更を適用するための安全で自動化されたワークフローを設計する必要があります。 どうすればよいですか？

選択肢と解説

  • 1
    Cloud Build パイプラインがサービス アカウントの権限借用を使用するように構成する。プル リクエストがマージされたときに terraform apply を自動的に実行するトリガーを設定する。
  • ✓
    Cloud Build でサービス アカウントの権限借用を使用する。プル リクエストに対して terraform plan を実行するようにパイプラインを構成し、terraform apply を実行する前に手動承認を必須にする。
  • 3
    パイプラインは terraform plan のみを実行するように構成する。プル リクエストが承認された後、権限を持つ開発者がセキュリティ保護されたワークステーションから terraform apply を実行する。
  • 4
    特権を持つサービス アカウントを作成し、その JSON キーを Secret Manager に保存する。Cloud Build パイプラインが実行時にこのキーを取得して Terraform を認証するように構成する。

解説

【正解】B

【0からの解説】
① 前提知識
・Terraform はインフラストラクチャをコードで定義するツール（IaC）です。terraform plan は「どのリソースがどう変わるか」という変更内容をプレビューするだけのコマンド、terraform apply は実際に変更を適用するコマンドです。
・Cloud Build は Google Cloud のマネージド CI/CD サービスです。Git リポジトリのプル リクエストやブランチへの push をきっかけにトリガーでビルドを起動できます。トリガーには「承認を必須にする」設定があり、承認者（Cloud Build 承認者ロール roles/cloudbuild.builds.approver を持つユーザー）が承認するまでビルドの実行を保留できます。
・サービス アカウントの権限借用（impersonation）: あるプリンシパル（ここでは Cloud Build のサービス アカウント）が、別のサービス アカウントの有効期間の短いアクセス トークンを発行して、そのサービス アカウントとして操作する仕組みです。キー ファイルを作成・保管する必要がなく、Terraform の google プロバイダでも impersonate_service_account として使えます。

② 要件と制約語の整理
・有効期間の長い静的なサービス アカウント キーの禁止 → キーレスの認証が必要。
・開発者は変更を提案（ピアレビュー）できるが、本番に直接適用する権限を持たない → 適用はパイプラインだけが行い、職務分離を徹底する。
・安全で自動化され、適切なガバナンスが確保されていること → 人手による操作ではなく自動化しつつ、適用前に統制ポイントを設ける。

③ 正解 B が要件をどう満たすか
・Cloud Build は自身のサービス アカウントで実行され、本番プロジェクトへの権限を持つデプロイ用サービス アカウントを権限借用して短期トークンで Terraform を実行します。静的キーは一切存在しません。
・プル リクエスト時に terraform plan を自動実行し、その結果をレビュアーが確認できるようにすることで、ピアレビューの質が上がります。
・terraform apply の前に手動承認を必須にすることで、権限のある承認者が確認するまで本番への変更は適用されません。開発者には本番プロジェクトの IAM 権限も承認者ロールも付与しないため、開発者が自分で本番に変更を適用することはできません。Google が推奨する Terraform・Cloud Build・GitOps によるインフラ管理の考え方に、承認ゲートによるガバナンスを加えた構成です。

【誤りの選択肢】
A：権限借用によってキーレスにしている点は正しいものの、マージと同時に terraform apply が自動実行されるため、本番適用の前に明示的な統制ポイントがありません。マージできる開発者は実質的に本番への変更を適用できることになり、plan の結果を確認せずにマージされる危険もあります。B の承認ゲートと比べてガバナンスが弱くなります。
C：本番適用が人手に戻るため「自動化されたワークフロー」の要件に反します。さらに、apply を実行する開発者に本番への権限を与えることになり、「開発者は本番に直接適用する権限を持たない」というルールと矛盾します。ワークステーションごとの環境差異や認証情報の管理、操作の追跡性の面でも、パイプラインによる一元的な適用より劣ります。
D：JSON キーを Secret Manager に保存しても、有効期間の長い静的なサービス アカウント キーを使うことに変わりはなく、セキュリティ チームの禁止事項に正面から違反します。キーの漏えいやローテーション管理のリスクも残ります。

【参考】
Terraform、Cloud Build、GitOps を使用してインフラストラクチャをコードとして管理する
サービス アカウントの権限借用 | Identity and Access Management (IAM)
ビルドトリガーの作成と管理 | Cloud Build
この問題のページを開く →
問題 5実装の管理実装の管理
問題
ある金融サービス企業が、オンプレミスのデータセンターの 1 つを廃止しようとしています。この取り組みの一環として、同社は 500 TB の過去の取引アーカイブを、長期保存のために Cloud Storage バケットへ 1 回限りで移行する必要があります。データセンターのインターネット下り（外向き）帯域は 1 Gbps で、この回線は重要な業務処理と共用されています。廃止期限に間に合わせるため、60 日以内に安全なデータ転送を完了させる必要があります。 どうすればよいですか？

選択肢と解説

  • 1
    データ転送を高速化するために 10 Gbps の容量を持つ Partner Interconnect 接続をプロビジョニングし、その後 Storage Transfer Service を使用する。
  • 2
    gcloud storage cp --parallel コマンドを使用するスクリプトを作成し、オフピーク時間帯に公共のインターネット経由でデータを分割してアップロードする。
  • 3
    Storage Transfer Service を使用して、オンプレミスのファイル サーバーから Cloud Storage バケットへ直接データを移動するエージェント ベースの転送ジョブを作成する。
  • ✓
    Transfer Appliance を注文し、高速なローカル ネットワークを使ってアプライアンスにデータをコピーした後、Google に返送して Cloud Storage バケットにデータをアップロードしてもらう。

解説

【正解】D

【0からの解説】
① 前提知識
・Transfer Appliance は、Google から物理的なストレージ アプライアンス（TA40 / TA300 などのモデル）を借り、データセンター内の高速な LAN でデータをコピーしてから Google に返送し、Google が Cloud Storage にアップロードするオフライン転送サービスです。データは AES-256 で暗号化され、Cloud KMS の顧客管理の暗号鍵（CMEK）も使えます。アップロード後のアプライアンスは NIST 800-88 準拠で消去されます。
・公式ドキュメントでは「ネットワーク経由でのアップロードに 1 週間以上かかる場合」が Transfer Appliance の適用目安とされています。目安の所要期間は、アプライアンスの受け取りと 300 TB のデータ取り込みで約 25 日、その後 Cloud Storage でデータが使えるようになるまで約 10 営業日です（容量に応じて複数台を注文します）。
・Storage Transfer Service はオンライン転送サービスです。オンプレミスからの転送では社内にエージェントを置き、既存のネットワーク回線経由でデータを送ります。

② 要件と制約語の整理
・500 TB を1 回限り移行する（継続的な同期ではない）。データセンターは廃止予定。
・回線は 1 Gbps で、重要な業務処理と共用されている（＝転送で帯域を使い切れない）。
・60 日以内に安全に完了させる。
・計算してみると、500 TB = 500×1012 バイト = 4×1015 ビットです。1 Gbps（109 ビット/秒）を 24 時間 100% 使い切っても 4×106 秒 ≒ 約 46 日かかります。実際にはプロトコルのオーバーヘッドがあり、しかも業務と共用のため帯域の一部しか使えないので、60 日以内の完了は現実的ではありません。

③ 正解 D が要件をどう満たすか
・Transfer Appliance へのコピーはデータセンター内の高速 LAN で行うため、業務と共用の 1 Gbps インターネット回線をまったく消費しません。
・約 25 日＋約 10 営業日という目安から、60 日の期限内に収まる見込みが立ちます。
・AES-256 暗号化（CMEK も可）と返却後の確実なデータ消去により、金融データの「安全な転送」の要件も満たします。1 回限りの大容量移行に新しい回線契約などの恒久的な投資が不要な点も、廃止予定のデータセンターに適しています。

【誤りの選択肢】
A：10 Gbps の Partner Interconnect があれば転送時間自体は短縮できますが、サービス プロバイダとの契約、データセンターからプロバイダまでの物理回線の手配、VLAN アタッチメントや Cloud Router の構成など、開通までに数週間単位のリードタイムがかかり、60 日の期限に対して大きなリスクになります。また、廃止するデータセンターのために 1 回限りの転送用として専用接続を調達するのは費用対効果も悪く、過剰な対応です。
B：公共のインターネット経由で、しかもオフピーク時間帯だけに限定してアップロードすると、利用できる帯域と時間がさらに減るため、帯域を 100% 使っても約 46 日かかる 500 TB の転送を 60 日以内に終えることはできません。手作りのスクリプトでは再試行・整合性検証・進捗管理も自前になり、運用負荷も高くなります（なお、gcloud storage cp は既定で並列転送を行い、--parallel というフラグを指定する使い方は一般的ではありません）。
C：エージェント ベースの Storage Transfer Service は再試行や整合性検証を備えたマネージドな転送ですが、データは結局、重要な業務と共用している 1 Gbps の回線を通ります。帯域を使い切れば業務に影響し、帯域を制限すれば 60 日に間に合いません。回線容量そのものがボトルネックである点を解決できません。

【参考】
Transfer Appliance
データ転送オプション | Storage Transfer Service
この問題のページを開く →
問題 6サイト信頼性エンジニア（SRE）として、インシデントを迅速にトリアージする必要があります。ソリューションと運用の卓越性の確保
問題
あなたは、Cloud Monitoring ワークスペースで Google Kubernetes Engine（GKE）クラスタをモニタリングしています。サイト信頼性エンジニア（SRE）として、インシデントを迅速にトリアージする必要があります。どうすればよいですか。

選択肢と解説

  • ✓
    1. Cloud Monitoring ワークスペースの事前定義済みダッシュボードを確認する。2. 指標を追加し、アラート ポリシーを作成する。
  • 2
    1. GKE ノードから指標を収集するシェル スクリプトを作成し、それらの指標を Pub/Sub トピックにパブリッシュする。2. データを BigQuery にエクスポートし、Data Studio のダッシュボードを作成する。
  • 3
    1. インシデントごとに Cloud Monitoring ワークスペースでカスタム ダッシュボードを作成する。2. 指標を追加し、アラート ポリシーを作成する。
  • 4
    1. Cloud Monitoring ワークスペースの事前定義済みダッシュボードを確認する。2. カスタム指標を作成し、Compute Engine インスタンスにアラート ソフトウェアをインストールする。

解説

【正解】A

【0からの解説】
①前提知識
・Cloud Monitoring は Google Cloud Observability の一部で、指標（メトリクス）の収集・可視化・アラートを提供するフルマネージド サービスです。かつて「Cloud Monitoring ワークスペース」と呼ばれていた単位は、現在は指標スコープ（観測対象のプロジェクトの範囲）として管理されています。
・GKE クラスタでは、システム指標（ノード・Pod・コンテナの CPU / メモリ使用量、再起動回数など）が自動的に Cloud Monitoring に送られ、GKE 用の事前定義済み（すぐに使える）ダッシュボードで、クラスタ・ノード・ワークロード・Pod 単位の状態をドリルダウンして確認できます。
・アラート ポリシーは、指標がしきい値を超えたときなどに通知チャネル（メール、Slack、PagerDuty など）へ自動通知する仕組みです。
・トリアージとは、インシデント発生時に影響範囲と優先度を素早く判断し、原因の切り分けを始めることです。

②要件の整理
・GKE をすでに Cloud Monitoring でモニタリングしている。
・SRE として「インシデントを迅速にトリアージ」したい → すぐに使える可視化と、問題を早期に検知する仕組みが必要。自作の仕組みを構築している時間はない。

③正解が要件をどう満たすか
A は、まず GKE 用の事前定義済みダッシュボードを使ってクラスタ全体からワークロード・Pod まで状態を即座に把握し、さらに必要な指標を追加してアラート ポリシーを作成します。これにより、異常が発生したらすぐに通知を受け、ダッシュボードで影響範囲を確認するという流れが、追加のインフラや開発なしで実現できます。Google の SRE のプラクティス（重要な指標に対するアラートとダッシュボードによる迅速な状況把握）にも沿った、最も迅速かつ運用負荷の小さい方法です。

【誤りの選択肢】
B：シェル スクリプト、Pub/Sub、BigQuery、Data Studio（現 Looker Studio）で独自の監視基盤を作るのは、Cloud Monitoring がすでに標準で提供している機能の再発明です。構築・保守の負担が大きいうえ、データがエクスポートされるまでの遅延があり、アラート機能もないため「迅速なトリアージ」に向きません。
C：インシデントのたびにカスタム ダッシュボードを作成していては、インシデント発生後に可視化の準備から始めることになり、対応が遅れます。事前定義済みダッシュボードという即座に使える手段を使わない点で、迅速なトリアージという要件に反します。
D：事前定義済みダッシュボードを使う前半は正しいものの、Compute Engine インスタンスに独自のアラート ソフトウェアをインストールする必要はありません。Cloud Monitoring のアラート ポリシーを使えばマネージドで通知でき、別途インスタンスを運用するのは不要な運用負荷であり、そのインスタンス自体が障害点にもなります。

【参考】
Cloud Monitoring の概要
指標の収集を構成する | Google Kubernetes Engine (GKE)
インシデントと問題を管理する
この問題のページを開く →
問題 7（2 つ選択してください）クラウド ソリューション アーキテクチャの設計と計画
問題
あなたの e コマース Web アプリケーションには、画像や動画を含む多数の商品が掲載されています。アプリケーションのページ読み込み速度を改善し、顧客のリクエストに対するレイテンシを短縮する必要があります。どうすればよいですか。（2 つ選択してください）

選択肢と解説

  • 1
    アプリケーションを Cloud Run にデプロイし、同時実行（concurrency）を有効にする。
  • ✓
    Memorystore for Redis を使用する。
  • ✓
    アプリケーションの外部 HTTPS ロードバランサで CDN を実装する。
  • 4
    データベースを Bigtable から Spanner に変更する。
  • 5
    通常の GKE クラスタではなく、GKE Autopilot クラスタにアプリケーションをデプロイする。

解説

【正解】B、C

【0からの解説】
①前提知識
・Cloud CDN（コンテンツ配信ネットワーク）は、外部アプリケーション ロードバランサ（旧称: 外部 HTTP(S) ロードバランサ）のバックエンド サービスやバックエンド バケットで有効化するだけで、Google が世界中に持つエッジ拠点に静的コンテンツ（画像・動画・CSS・JavaScript など）をキャッシュし、ユーザーに近い場所から配信するマネージド サービスです。オリジン（アプリケーション サーバーや Cloud Storage）まで往復する必要がなくなるため、ページ読み込みが速くなり、オリジンの負荷も下がります。
・Memorystore for Redis は、フルマネージドのインメモリ データストアです。データベースへの問い合わせ結果、商品情報、セッション情報などをメモリ上にキャッシュしておくことで、ミリ秒未満の応答でデータを返せます。毎回データベースにアクセスするよりも、動的なリクエストのレイテンシを大きく短縮できます。

②要件の整理
・商品の「画像や動画」が多い → 大きな静的コンテンツの配信がボトルネックになりやすい。
・「ページ読み込み速度の改善」と「顧客リクエストのレイテンシ短縮」の 2 点が目的。
・2 つ選ぶ問題なので、静的コンテンツ側と動的リクエスト（データ取得）側の両方を高速化する組み合わせが最適です。

③正解が要件をどう満たすか
・C：外部 HTTPS ロードバランサで Cloud CDN を有効にすると、画像や動画がエッジにキャッシュされ、地理的に離れた顧客にも低レイテンシで配信されます。ページ読み込み時間の大部分を占めるメディアの配信が速くなるため、「ページ読み込み速度の改善」に直接効きます。
・B：Memorystore for Redis を、データベースの手前のキャッシュ（キャッシュアサイド パターン）として使うことで、商品一覧や商品詳細などの頻繁に読まれるデータをメモリから即座に返せます。これにより、動的な API リクエストのレイテンシが短縮されます。
このように「静的コンテンツは CDN」「頻繁に読まれるデータはインメモリ キャッシュ」という 2 層のキャッシュは、Google Cloud の Web アプリケーションのパフォーマンス改善における定番の構成です。

【誤りの選択肢】
A：Cloud Run の同時実行は、1 つのコンテナ インスタンスで複数のリクエストを並行処理できるようにしてインスタンス数やコストを抑える設定です（しかも Cloud Run ではデフォルトで有効）。リクエストごとの処理時間やメディア配信の速さそのものを改善するものではなく、画像・動画の配信速度という本問の課題を解決しません。
D：Bigtable も Spanner もどちらも低レイテンシのデータベースであり、Spanner に変更してもレイテンシが改善するとは限りません（Spanner はグローバルな整合性を持つリレーショナル DB で、強整合性のための書き込みコストもあります）。データベースの大規模な移行は手間が大きく、画像・動画の配信という本問の課題とも関係しません。
E：GKE Autopilot は、ノードの管理を Google に任せて運用負荷を下げるための運用モードです。運用面のメリットはありますが、アプリケーションのレスポンスやページ読み込み速度を改善する仕組みではありません。

【参考】
Cloud CDN の概要
Memorystore for Redis の概要
コンテンツ配信のベスト プラクティス | Cloud CDN
この問題のページを開く →
問題 8クラウド ソリューション インフラストラクチャの管理とプロビジョニングクラウド ソリューション インフラストラクチャの管理とプロビジョニング
問題
あなたの会社の機械学習（ML）エンジニアは、データの準備、モデルのトレーニング、ファインチューニングなどの作業にセルフホストの Jupyter ノートブックを使用しています。その後、運用チームがこれらのモデルをさまざまな環境にデプロイしています。Google が推奨するプラクティスに従いながら、ML エンジニアに最大限の柔軟性を提供し、共通のツールセットによるコラボレーションを促進し、Google Cloud のスケーラビリティを活用したいと考えています。 どうすればよいですか？

選択肢と解説

  • 1
    機械学習には AutoML を使用し、モデルのデプロイには Cloud Deploy を使用する。
  • 2
    機械学習には Colab Enterprise を使用し、モデルのデプロイには DevOps を使用する。
  • ✓
    機械学習には Vertex AI を使用し、モデルのデプロイには機械学習オペレーション（MLOps）を使用する。
  • 4
    機械学習には TensorFlow を使用し、モデルのデプロイには Cloud Deploy を使用する。

解説

【正解】C

【0からの解説】
① 前提知識
・Vertex AI（現 Gemini Enterprise Agent Platform）: Google Cloud の統合 ML / AI プラットフォームです。マネージドな Jupyter 環境である Vertex AI Workbench（現 Agent Platform Workbench）や Colab Enterprise、任意のフレームワーク（TensorFlow、PyTorch、scikit-learn など）やカスタム コンテナを使えるカスタム トレーニング、ハイパーパラメータ調整、Vertex AI Pipelines（現 Agent Platform Pipelines）、Model Registry、エンドポイントによるオンライン予測 / バッチ予測、Model Monitoring までを 1 つのプラットフォームで提供します。トレーニングや推論の計算資源は必要に応じて GPU / TPU を含めてスケールします。
・MLOps（機械学習オペレーション）: DevOps の考え方を ML に拡張したプラクティスです。コードだけでなくデータとモデルのバージョン管理、パイプラインによるトレーニングの自動化、モデルの継続的なデプロイ、本番モデルのモニタリングと再トレーニングまでを含み、データ サイエンティスト / ML エンジニアと運用チームの協業を仕組み化します。
・選択肢の粒度の違いに注意: 選択肢 C の「モデルのデプロイには MLOps を使用」の MLOps は、Cloud Deploy や AutoML のような特定のサービス名ではなく、プラクティス（考え方・進め方）を指す概念です（選択肢 B の「DevOps」も同様に概念です）。そのため選択肢同士で粒度がそろっていませんが、C は「Google Cloud 上では Vertex AI の Pipelines（ワークフローの自動化）、Model Registry（モデルのバージョン管理）、エンドポイント（デプロイ）、Model Monitoring（本番モデルの監視）といった機能を使い、MLOps のプラクティスに沿ってデプロイと運用を行う」という意味に読み替えると、具体的な設計として理解できます。

② 要件と制約語の整理
・現状: セルフホストの Jupyter ノートブックで開発し、運用チームが別途デプロイしている（ツールがばらばらで、スケールしにくい）。
・要件: ML エンジニアへの最大限の柔軟性／共通のツールセットによるコラボレーション／Google Cloud のスケーラビリティの活用／Google 推奨のプラクティス。

③ 正解 C が要件をどう満たすか
・Vertex AI はノートブック（Workbench / Colab Enterprise）から、任意のフレームワークによるトレーニング、ファインチューニング、デプロイまでを網羅し、ML エンジニアは慣れた Jupyter のワークフローを保ちながら最大限の柔軟性を得られます。
・開発チームと運用チームが同じプラットフォーム（Pipelines、Model Registry、エンドポイント）を共通のツールセットとして使うため、協業が容易になります。
・計算資源はマネージドにスケールし、Google Cloud のスケーラビリティを活用できます。
・モデルのデプロイを MLOps のプラクティス（パイプラインによる自動化、モデルのバージョン管理、継続的なデプロイとモニタリング）で行うことは、Google がアーキテクチャ センターで推奨している方法です。

【誤りの選択肢】
A：AutoML はコードをほとんど書かずに高品質なモデルを作れる反面、モデル構造やトレーニング処理を細かく制御できず、ファインチューニングなどを自由に行いたい ML エンジニアにとって「最大限の柔軟性」を損ないます。Cloud Deploy はアプリケーションを GKE や Cloud Run などへ継続的にデリバリーするサービスで、ML モデルのデプロイやモニタリング、再トレーニングといった ML 固有の運用を扱うものではありません。
B：Colab Enterprise はマネージドなノートブック環境として有用ですが（Vertex AI の一部）、ノートブックだけではトレーニングの自動化、モデル管理、デプロイといった ML ライフサイクル全体はカバーできません。また、一般的な DevOps はコードの CI/CD が中心で、データやモデルのバージョン管理、モデル性能の劣化検知と再トレーニングといった ML 固有の要素が欠けているため、Google は ML には MLOps を推奨しています。
D：TensorFlow は ML のフレームワーク（ライブラリ）であり、プラットフォームではありません。特定のフレームワークに限定すると柔軟性が下がり、それ自体ではマネージドなスケーラビリティやチームの共通基盤も提供しません。Cloud Deploy も A と同じ理由で ML モデルのデプロイ手段として適切ではありません。

【参考】
Agent Platform の概要
Google Cloud で ML を実装するためのベスト プラクティス
ノートブック
この問題のページを開く →
問題 9セキュリティとコンプライアンスのための設計セキュリティとコンプライアンスのための設計
問題
あなたの会社は、コンプライアンス監査を実施するために外部の監査法人を雇いました。会社のガバナンス ポリシーでは、外部監査人は単一の Google グループで管理し、そのグループに audit-evidence-bucket という名前の Cloud Storage バケットへの一時的な読み取り専用アクセスを付与することが求められています。アクセスは個々の監査人の ID まで追跡可能でなければならず、また監査業務の期間中（10 月の 1 か月間全体）のみ有効でなければなりません。管理上のオーバーヘッドを避け、会社のガバナンス ポリシーに準拠した、安全なアクセス制御戦略が必要です。 どうすればよいですか？

選択肢と解説

  • ✓
    Google グループに roles/storage.objectViewer ロールを付与する IAM ポリシー バインディングを適用する。このバインディングに、10 月 1 日から 11 月 1 日までアクセスを自動的に許可する時間ベースの IAM Condition を構成する。
  • 2
    サービス アカウントを作成し、バケットに対する roles/storage.objectViewer ロールを付与する。バケット内の各オブジェクトについて、有効期限を 11 月 1 日とする署名付き URL を生成して共有する。
  • 3
    Cloud Scheduler を使用して、10 月 1 日に Google グループへの roles/storage.objectViewer の IAM バインディングを追加する Cloud Run functions のスクリプトと、11 月 1 日にその IAM バインディングを削除するもう 1 つのスクリプトを実行する。
  • 4
    Workforce Identity 連携を使用して、監査人のグループを Google グループにマッピングする。roles/storage.objectViewer ロールをこの Google グループにバインドする。プロバイダでセッションの有効期間を 1 か月に構成する。

解説

【正解】A

【0からの解説】
① 前提知識
・IAM ポリシー バインディング: 「誰に（プリンシパル）」「どのロールを」付与するかの組み合わせです。Google グループをプリンシパルにすると、グループのメンバー全員にロールが付与され、メンバーの追加・削除だけでアクセスを管理できます。
・IAM Conditions: ロールの付与に条件を付ける機能です。日時の属性 request.time を使えば、例えば request.time >= timestamp("…-10-01T00:00:00Z") && request.time < timestamp("…-11-01T00:00:00Z") のように、指定した期間だけ有効な一時的アクセスを宣言的に設定できます。Cloud Storage で IAM Conditions を使うには、バケットで均一なバケットレベルのアクセス（uniform bucket-level access）を有効にします。
・roles/storage.objectViewer（Storage オブジェクト閲覧者）: オブジェクトの一覧表示と読み取りだけができる読み取り専用ロールです。
・グループ経由でアクセスしても、Cloud Audit Logs のデータアクセス監査ログ（Cloud Storage では有効化が必要）には実際にアクセスした個人のアカウントが記録されるため、個人単位で追跡できます。

② 要件と制約語の整理
・外部監査人は単一の Google グループで管理する（ガバナンス ポリシー）。
・一時的な読み取り専用アクセス、対象は audit-evidence-bucket。
・個々の監査人の ID まで追跡可能であること。
・10 月の 1 か月間だけ有効であること。
・管理上のオーバーヘッドを避けること。

③ 正解 A が要件をどう満たすか
・Google グループに roles/storage.objectViewer を付与することで、ガバナンス ポリシーどおり「単一のグループ」「読み取り専用」を満たします。
・時間ベースの IAM Condition により、10 月 1 日から 11 月 1 日までの間だけアクセスが有効になり、期限が来れば自動的にアクセスが失効します。誰かが手動でロールを外す必要も、スクリプトを保守する必要もないため、管理上のオーバーヘッドが最小です。
・各監査人は自分の Google アカウントでアクセスするため、監査ログで個人を特定できます。

【誤りの選択肢】
B：署名付き URL は、URL を知っている人なら誰でもアクセスできる「持参人払い」型の仕組みで、アクセスは署名したサービス アカウントの権限で行われるため、個々の監査人の ID まで追跡できません。オブジェクトごとに URL を生成・配布する手間もかかり、新しく追加された証跡ファイルにも対応できません。さらに V4 署名付き URL の有効期限は最長 7 日間であり、1 か月後の 11 月 1 日を有効期限にすること自体ができません。
C：スケジュールに合わせて IAM バインディングを追加・削除すれば動作はしますが、Cloud Scheduler や Cloud Run functions（旧 Cloud Functions）のコードを自前で作成・保守する必要があり、ジョブの失敗で権限が外れないなどのリスクもあります。IAM Conditions で宣言的に実現できることを独自実装で置き換えるもので、「管理上のオーバーヘッドを避ける」要件に反します。
D：Workforce Identity 連携は、外部の ID プロバイダ（IdP）のユーザーを Google Cloud に直接サインインさせる仕組みで、外部 IdP の属性を「Google グループにマッピングする」ものではありません。プロバイダのセッション有効期間は最長でも 12 時間であり、1 か月には設定できません。またセッション時間はアクセス期間（10 月中のみ）を制限する仕組みでもないため、期間限定アクセスの要件を満たせません。IdP 連携の構築という不要な管理負荷も発生します。

【参考】
IAM Conditions の概要 | Identity and Access Management (IAM)
Identity and Access Management | Cloud Storage
この問題のページを開く →
問題 10技術プロセスとビジネス プロセスの分析と最適化技術プロセスとビジネス プロセスの分析と最適化
問題
ある大手医療機関の主要な電子健康記録（EHR）アプリケーションは、Cloud SQL for PostgreSQL データベースを使用する Compute Engine インスタンス上で稼働しており、すべて us-west1 リージョンに配置されています。新たな規制により、事業継続計画（BCP）の実装と文書化が義務付けられました。この計画では、目標復旧時間（RTO）2 時間、目標復旧時点（RPO）15 分で、EHR アプリケーションを地理的に異なるリージョンで完全に復旧し、稼働可能にできることを保証しなければなりません。これらの厳格な BCP 要件を満たす障害復旧（DR）戦略を設計する必要があります。 どうすればよいですか？

選択肢と解説

  • 1
    us-west1 と us-east1 の両方にアクティブなマネージド インスタンス グループ（MIG）をデプロイし、その前段にグローバル外部 HTTP(S) ロードバランサを配置する。データベースには us-east1 のクロスリージョン リードレプリカを使用し、障害時にはロードバランサのヘルスチェックによってすべてのトラフィックが自動的にフェイルオーバーされることに任せる。
  • ✓
    Terraform を使用してアプリケーションのコンピューティング インフラストラクチャを定義する。障害発生時には、us-west1 の Cloud SQL データベースが us-east1 のクロスリージョン リードレプリカを使用するように構成し、us-east1 に環境を構築して、レプリカを昇格する。
  • 3
    Compute Engine のディスクと Cloud SQL データベースのスナップショットを毎日取得する。これらのスナップショットを us-east1 の Cloud Storage バケットにコピーする。障害発生時には、最新のスナップショットから仮想マシン（VM）とデータベースを手動で復元する。
  • 4
    高可用性のために us-west1 にリージョン MIG をデプロイし、リージョンがオンラインであり続けることについては Google Cloud の SLA に頼る。

解説

【正解】B

【0からの解説】
① 前提知識
・RTO（目標復旧時間）: 障害発生からサービスを再開するまでに許容される時間。本問では 2 時間。
・RPO（目標復旧時点）: 失ってもよいデータの量を時間で表したもの。本問では 15 分＝障害発生時点から遡って 15 分より前のデータは失ってはならない。
・Google の障害復旧計画ガイドでは、DR のパターンをコールド（障害時にゼロから構築）、ウォーム（データは常時複製し、計算資源は最小限または必要時に構築）、ホット（両リージョンで常時稼働）に分類し、RTO / RPO とコストのバランスで選ぶよう推奨しています。
・Cloud SQL のクロスリージョン リードレプリカ: プライマリから別リージョンのレプリカへ非同期で継続的にデータを複製します。通常のレプリケーション遅延は数秒程度です。プライマリのリージョンで障害が起きたときは、レプリカを昇格（promote）すると、書き込み可能な独立したプライマリになります。レプリカは平常時から作成しておく必要があります（障害で us-west1 が使えなくなった後では作成できません）。
・Terraform でインフラをコード化しておくと、障害時に別リージョンへ同じ構成を短時間・確実に再構築できます。

② 要件と制約語の整理
・地理的に異なるリージョンで完全に復旧・稼働できること。
・RTO 2 時間: 2 時間以内に別リージョンでサービスを再開。
・RPO 15 分: データ損失は 15 分以内 → 1 日 1 回のバックアップでは不十分で、継続的なデータ複製が必要。

③ 正解 B が要件をどう満たすか
・まず選択肢 B の文面に注意が必要です。文面どおりに読むと「障害発生時に」クロスリージョン リードレプリカの構成も行うように読めます。しかし、us-west1 が障害で使えなくなった後では、そのプライマリからレプリカを新たに作成することはできず、仮にできてもレプリカの作成と初期データのコピーに時間がかかり、それまでのデータも守れません。そのため実際の設計としては、レプリカは平常時から us-east1 に作成しておき、障害時に行うのは us-east1 での環境構築とレプリカの昇格、と解釈する必要があります。文面には不正確な点がありますが、データの継続的な複製（ウォーム スタンバイ）と IaC による再構築という方針を示しているのは B だけで、他の選択肢はいずれも要件を根本的に満たさないため、B が最も適切な答えになります。
・Cloud SQL のクロスリージョン リードレプリカを us-east1 に置いておくことで、データは数秒程度の遅延で継続的に複製され、RPO 15 分を十分に満たします。
・コンピューティングは Terraform で定義しておき、障害発生時に us-east1 へ環境を構築し、レプリカを昇格してアプリケーションの接続先を切り替えます。VM の構築とレプリカの昇格は数十分程度で完了するため、RTO 2 時間に収まります。
・平常時に us-east1 で稼働させるのはデータベースのレプリカだけなので、両リージョンで常時フル稼働させるホット構成よりコストを抑えられます。手順を文書化してテストしておけば、BCP として文書化の要件にも対応できます。

【誤りの選択肢】
A：ロードバランサのヘルスチェックが自動で切り替えるのは HTTP(S) トラフィックの送信先（バックエンドの MIG）だけで、データベースのフェイルオーバーは行いません。us-east1 のクロスリージョン リードレプリカは読み取り専用のままなので、昇格しない限りアプリケーションは書き込みができず、「完全に稼働」した状態になりません。さらに両リージョンで MIG を常時稼働させるため、RTO 2 時間という要件に対して過剰なコストもかかります。
C：スナップショットが 1 日 1 回では、最悪で約 24 時間分のデータを失うため、RPO 15 分を満たせません。障害時に手動で VM とデータベースを復元する手順は時間がかかり、ミスのリスクもあります（なお、ディスク スナップショットや Cloud SQL のバックアップは Cloud Storage バケットにコピーして管理するものではなく、それぞれの保存ロケーションの設定で管理します）。
D：リージョン MIG は us-west1 内の複数ゾーンに VM を分散するため、ゾーン障害には強くなりますが、リージョン全体の障害には対応できません。「地理的に異なるリージョンでの復旧」という要件を満たしていません。また SLA は障害時に利用料金のクレジットが返還されるといった契約上の取り決めであり、可用性を保証する技術的な対策や DR 戦略の代わりにはなりません。

【参考】
障害復旧計画ガイド
データの障害復旧シナリオ
アプリケーションの障害復旧シナリオ
この問題のページを開く →
問題 11すべての環境にわたって構成管理を効率化し、セキュリティ ポリシーを適用し、一貫したアプリケーションのデプロイを確実にする…実装の管理
問題
あなたの組織は、Google Kubernetes Engine（GKE）と Amazon Elastic Kubernetes Service（EKS）を使用して、複数のクラウド プロバイダにまたがる複雑な Kubernetes 環境を管理しています。すべての環境にわたって構成管理を効率化し、セキュリティ ポリシーを適用し、一貫したアプリケーションのデプロイを確実にするソリューションをデプロイする必要があります。Google が推奨するプラクティスに従いたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    GitOps ベースの継続的デリバリーには Argo CD を、ポリシーの適用には Open Policy Agent（OPA）を活用し、マルチクラスタの構成管理用のコントローラを開発する。
  • 2
    クラウド リソースを Kubernetes オブジェクトとして管理するために Crossplane を、GitOps ベースの構成同期に FluxCD を、ポリシーの適用に Kyverno をデプロイする。
  • 3
    構成のカスタマイズに Kustomize を、複数の Git リポジトリと組み合わせた Config Sync を、セキュリティ ポリシーの適用にスクリプトをデプロイする。
  • ✓
    GKE の一部である Config Sync を利用して一元化されたリポジトリから構成を同期し、Policy Controller を利用して OPA Gatekeeper によるポリシーを適用する。

解説

【正解】D

【0からの解説】
①前提知識
・フリート：GKE では、複数の Kubernetes クラスタを「フリート」という論理的なグループとして登録し、一元的に管理できます。Google Cloud 上の GKE だけでなく、GKE attached clusters の仕組みを使うことで Amazon EKS や Azure AKS などの他社クラウドのクラスタもフリートに登録できます。
・Config Sync：Git リポジトリ（または OCI イメージ）を「信頼できる唯一の情報源」として、Kubernetes の構成（Namespace、RBAC、Deployment など）を多数のクラスタに自動的に同期する、Google 提供の GitOps ツールです。クラスタ上で誰かが手動で変更しても、リポジトリの状態に自動的に戻す（ドリフトの是正）ため、すべての環境で構成の一貫性を保てます（旧 Anthos Config Management の機能）。
・Policy Controller：オープンソースの OPA Gatekeeper をベースにしたポリシー適用機能で、「特権コンテナを禁止する」「必須ラベルを付ける」といったポリシーを、Kubernetes API へのリクエスト時（アドミッション コントロール）に強制し、既存リソースの違反も監査します。CIS ベンチマークなどの事前構築済みポリシー バンドルも利用できます。

②要件の整理
・GKE と EKS のマルチクラウド環境。
・「構成管理の効率化」「セキュリティ ポリシーの適用」「一貫したアプリケーション デプロイ」の 3 つすべてを満たす必要がある。
・「Google が推奨するプラクティス」→ Google が提供・サポートするマネージドな機能を優先し、自作のコントローラやスクリプトは避ける。

③正解が要件をどう満たすか
D は、EKS を含むすべてのクラスタをフリートに登録したうえで、Config Sync により一元化された Git リポジトリから構成とアプリケーション マニフェストを全クラスタへ同期し（構成管理の効率化と一貫したデプロイ）、Policy Controller によって OPA Gatekeeper ベースのポリシーを全クラスタで強制・監査します（セキュリティ ポリシーの適用）。Config Sync と Policy Controller は GKE attached clusters 上でも利用でき、Google Cloud コンソールから全環境の同期状態やポリシー違反を一元的に確認できます。Google が推奨するマルチクラウドの Kubernetes 管理方法であり、すべての要件を満たします。

【誤りの選択肢】
A：Argo CD や OPA はそれぞれ有力なオープンソース ツールですが、「マルチクラスタの構成管理用のコントローラを開発する」という自作部分が含まれ、その開発と保守に大きな負担が生じます。Google が提供・サポートする統合ソリューション（Config Sync と Policy Controller）を使う D に比べ、Google の推奨プラクティスとは言えません。
B：Crossplane、FluxCD、Kyverno の組み合わせでも同様の機能を構築できますが、3 つの異なるオープンソース ツールを自社で導入・統合・運用する必要があり、Google のサポートやコンソールでの一元的な可視化も得られません。「Google が推奨するプラクティス」という条件に合いません。
C：Config Sync を使う点は良いものの、セキュリティ ポリシーの適用を「スクリプト」で行うのは、アドミッション時の強制や継続的な監査ができず、抜け漏れや保守負担が生じます。ポリシーの適用には Policy Controller を使うのが Google の推奨であり、C はその点で劣ります。

【参考】
フリート管理 | Google Kubernetes Engine (GKE)
Google Cloud を使用してハイブリッド アーキテクチャとマルチクラウド アーキテクチャを構築する
この問題のページを開く →
問題 12クラウド ソリューション アーキテクチャの設計と計画クラウド ソリューション アーキテクチャの設計と計画
問題
あなたの組織は、アプリケーションを Kubernetes に移行し、マネージド クラウド サービスを使用してアプリケーションをデプロイする予定です。あなたのチームは Kubernetes に不慣れであり、エンジニアを迅速に立ち上げ（オンボーディング）させたいと考えています。運用のオーバーヘッドを削減し、エンジニアリング チームがインフラストラクチャの保守ではなく、顧客の要件に応える開発に集中できるようにしたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    アプリケーションを Docker イメージにパッケージ化し、Compute Engine 上の Kubernetes にデプロイする。
  • 2
    Cloud Build を活用してコンテナ イメージを作成し、Compute Engine 上の Kubernetes に自動的にデプロイする。
  • 3
    コンテナ化に向けてアプリケーションと依存関係を評価する。Standard モードの GKE へのデプロイに向けた移行戦略を策定する。
  • ✓
    コンテナ化に向けてアプリケーションと依存関係を評価する。Autopilot モードの GKE へのデプロイに向けた移行戦略を策定する。

解説

【正解】D

【0からの解説】
①前提知識
・Google Kubernetes Engine（GKE）は、Google Cloud のマネージド Kubernetes サービスです。GKE には 2 つの運用モードがあります。
　- Standard モード：コントロール プレーンは Google が管理しますが、ノード（ノードプール）の構成・サイズ設定・スケーリング・セキュリティ設定などは利用者が管理します。柔軟性が高い反面、Kubernetes とインフラの知識が必要です。
　- Autopilot モード：コントロール プレーンに加えて、ノードのプロビジョニング、スケーリング、アップグレード、セキュリティ強化の設定まで Google が管理します。利用者は Pod（ワークロード）の定義に集中でき、課金も原則として Pod が要求したリソース単位です。Google はほとんどの本番ワークロードに Autopilot を推奨しています。
・移行では、いきなりデプロイするのではなく、まずアプリケーションと依存関係を評価してコンテナ化が可能か（ステートの扱い、OS 依存、外部接続など）を確認し、移行戦略を立てるのが Google の推奨する進め方（評価 → 計画 → デプロイ → 最適化）です。

②要件の整理
・チームは Kubernetes に不慣れ → 学習コストが低い方がよい。
・「運用のオーバーヘッドを削減」「インフラ保守ではなく開発に集中」→ インフラ管理を可能な限り Google に任せたい。
・「マネージド クラウド サービスを使用」→ 自前で Kubernetes を構築する案は不適。

③正解が要件をどう満たすか
D は、まずアプリケーションと依存関係をコンテナ化の観点で評価し、そのうえで GKE Autopilot への移行戦略を策定します。Autopilot ではノード管理・スケーリング・アップグレード・セキュリティのベスト プラクティスが Google によって自動的に適用されるため、Kubernetes に不慣れなチームでも、ノード設計などのインフラ作業を意識せずにワークロードのデプロイに集中できます。運用負荷の最小化と迅速なオンボーディングの両方を満たすのは D です。

【誤りの選択肢】
A：Compute Engine 上に Kubernetes を自前で構築すると、コントロール プレーンを含むクラスタ全体のインストール、アップグレード、パッチ適用、可用性の確保を自社で行う必要があります。「マネージド サービスを使用」「運用のオーバーヘッドを削減」という要件に反し、Kubernetes に不慣れなチームには最も負担が大きい選択肢です。また、事前の評価・移行計画もありません。
B：Cloud Build でイメージ作成とデプロイを自動化する点は良いものの、デプロイ先が Compute Engine 上の自前 Kubernetes であるため、A と同じくクラスタの保守運用がすべて自社の責任になります。CI/CD を自動化しても、インフラ保守の負担という根本課題は解決しません。
C：評価と移行戦略の策定という進め方は正しいものの、GKE Standard モードではノードプールの設計、マシンタイプの選択、スケーリングやアップグレードの設定などを利用者が管理する必要があります。Autopilot と比べて運用のオーバーヘッドが大きく、Kubernetes に不慣れなチームを迅速に立ち上げるという要件には D の方が適しています。

【参考】
GKE Autopilot の概要 | Google Kubernetes Engine (GKE)
Autopilot クラスタと Standard クラスタの機能を比較する | Google Kubernetes Engine (GKE)
この問題のページを開く →
問題 13Prometheus Query Language（PromQL）のクエリ、指標のすばやい表示、効率的な問題の診断をサポ…ソリューションと運用の卓越性の確保
問題
高度に分散したハイブリッド クラウドかつマルチクラウドの IT 環境を管理しており、開発者はワークフローで Prometheus に大きく依存しています。Prometheus Query Language（PromQL）のクエリ、指標のすばやい表示、効率的な問題の診断をサポートする、クラウドベースで拡張性が高く、メンテナンスの手間が少ないエンタープライズ向けソリューションが必要です。どうすればよいですか。

選択肢と解説

  • 1
    マルチクラウド環境全体の既存の Kubernetes とサーバーレスの構成に Prometheus Operator をデプロイする。
  • 2
    マルチクラウド環境全体を一元的に把握できる単一の管理画面（シングル ペイン オブ グラス）として Cloud Monitoring を設定する。
  • ✓
    Google Cloud Managed Service for Prometheus を有効にして、ワークロードを大規模にモニタリングし、アラートを生成する。
  • 4
    クラウドごとにカスタマイズ可能な方法で指標を表示する、SaaS ベースの Prometheus 互換ソリューションを構築する。

解説

【正解】C

【0からの解説】
①前提知識
・Prometheus は、オープンソースのモニタリング ツールです。監視対象から指標（メトリクス）を収集（スクレイプ）して時系列データとして保存し、PromQL で照会したりアラートを出したりします。ただし自前で運用する場合、ストレージ容量、長期保存、高可用性、複数クラスタや複数クラウドにまたがる統合（フェデレーション）などをすべて自分で設計・運用する必要があり、規模が大きくなるほど運用負荷が増大します。
・Google Cloud Managed Service for Prometheus は、Prometheus（および OpenTelemetry）の指標を扱う、Google Cloud のフルマネージドでマルチクラウド・プロジェクト横断のソリューションです。Google 自身の監視に使われているグローバル スケールのデータストア Monarch 上に構築されており、データを 24 か月保持し、ハイブリッド クラウドとマルチクラウドに対応しています。全データを PromQL で照会でき、既存の Prometheus の構成、エクスポータ、ルール、Grafana ダッシュボードを生かしたまま移行できます。収集方式として、GKE 向けのマネージド収集と、GKE 以外の Kubernetes や他のクラウドでも使えるセルフデプロイ収集などを選べます。
②問題文の要件と制約語の整理
・環境: 高度に分散したハイブリッド / マルチクラウド。
・開発者は Prometheus に大きく依存 → Prometheus の使い方（PromQL など）を維持したい。
・「クラウドベース」「拡張性が高い」「メンテナンスの手間が少ない（運用負荷が小さい）」「エンタープライズ向け」。
・PromQL クエリ、指標のすばやい表示、効率的な問題の診断。
③正解がその要件をどう満たすか
Managed Service for Prometheus を使えば、開発者は PromQL や既存のエクスポータ・ルールといった Prometheus のワークフローをそのまま使い続けられ、データの保存・スケーリング・長期保持・高可用性は Google が管理します。ハイブリッド / マルチクラウドの指標を 1 か所に集約して照会でき、Cloud Monitoring のダッシュボードやアラートとも統合されるため、指標のすばやい表示と効率的な問題診断も実現できます。自前運用が不要なので「メンテナンスの手間が少ない」要件も満たします。

【誤りの選択肢】
A：Prometheus Operator は、Kubernetes 上に Prometheus を自前でデプロイ・管理するためのツールです。各環境の Prometheus サーバーのストレージ、スケーリング、高可用性、長期保存、環境をまたいだクエリなどをすべて自分で運用する必要があり、「クラウドベースで拡張性が高く、メンテナンスの手間が少ない」という要件に反します。また Operator は Kubernetes 向けの仕組みで、サーバーレス環境にそのまま適用できるものでもありません。
B：Cloud Monitoring は Google Cloud の監視基盤ですが、「単一の管理画面として設定する」だけでは、開発者が依存している Prometheus の指標をどう収集し、PromQL ベースのワークフローをどう維持するのかが示されていません。Prometheus の指標を Prometheus 互換のまま大規模に取り込むための具体的なサービスが Managed Service for Prometheus であり（その指標は Cloud Monitoring の基盤に保存されます）、要件に最も直接対応するのは C です。
D：SaaS ベースの Prometheus 互換ソリューションを自社で「構築」するのは、開発と運用の負担が最も大きい選択肢です。既に提供されているマネージド サービスで要件を満たせるため、「メンテナンスの手間が少ない」という要件に反します。

【参考】
Google Cloud Managed Service for Prometheus Observability
ハイブリッド クラウドとマルチクラウドのモニタリングおよびロギング パターン
この問題のページを開く →
問題 14運用のオーバーヘッドを最小限に抑えつつ、これらの要件を満たす完全に自動化されたバックアップ ソリューションを実装する必要…クラウド ソリューション インフラストラクチャの管理とプロビジョニング
問題
あなたの会社では、Compute Engine 仮想マシン（VM）上で稼働するカスタムビルドのアプリケーションを使用しています。このアプリケーションはリアルタイムの販売データを処理し、ゾーン Persistent Disk に書き込んでいます。最近の内部監査により、ゾーン障害から保護するためのバックアップと復旧の計画を実装することが求められました。あなたの会社には、すべてのバックアップ データを少なくとも 90 日間保持し、アクセスが制限された別のプロジェクトに保存しなければならないという厳格なポリシーがあります。運用のオーバーヘッドを最小限に抑えつつ、これらの要件を満たす完全に自動化されたバックアップ ソリューションを実装する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    Persistent Disk の日次バックアップを作成するスクリプトを作成する。バックアップを別のゾーンにコピーし、各スナップショットに削除日を示すラベルを付ける。
  • 2
    gcloud コマンドを使用して Persistent Disk のスナップショットを作成する。スナップショットをリージョンの Cloud Storage バケットに保存し、90 日より古いオブジェクトを削除するライフサイクル ルールを構成する。
  • 3
    スナップショット スケジュールを作成して Persistent Disk のスナップショットを自動的に作成し、スクリプトを使用してそれらをマルチリージョンの Cloud Storage バケットに移動して保存する。
  • ✓
    Backup and Disaster Recovery（DR）サービスを使用してバックアップ プランを作成する。日次でスナップショットを取得し、90 日間の保持ポリシーを設定したバックアップ ボールトに保存するようにバックアップ プランを構成する。

解説

【正解】D

【0からの解説】
①前提知識
・Backup and DR サービスは、Compute Engine インスタンス、Compute Engine ディスク（Persistent Disk）、Cloud SQL などのバックアップを一元管理する Google Cloud のマネージド サービスです。
・バックアップ プラン：バックアップの頻度（例: 毎日）、保持期間、保存先を定義したポリシーです。保護したいリソースにプランを適用すると、以降のバックアップは自動的に実行されます。
・バックアップ ボールト（Backup Vault）：バックアップを保存する専用のストレージ リソースです。作成時に「最小適用保持期間」（1 日〜99 年）を設定でき、その期間が終わるまでバックアップは管理者や Google を含め誰にも変更・削除できません（変更不可・削除不可）。また、バックアップ ボールトを保護対象とは別の管理用プロジェクトに置く「一元管理モデル」を取ることで、本番プロジェクトとは別のアクセス制御のもとでバックアップを保管できます。
・ボールトに保存されたバックアップはゾーンに依存しないため、元のゾーンで障害が発生しても別のゾーンやリージョンに復元できます。

②要件の整理
・ゾーン障害からの保護（バックアップがゾーンの外にあること）。
・バックアップは少なくとも 90 日間保持。
・アクセスが制限された「別のプロジェクト」に保存。
・「完全に自動化」かつ「運用のオーバーヘッドを最小限」→ スクリプトや手作業を含まないマネージドな方式が望ましい。

③正解が要件をどう満たすか
D では、Backup and DR のバックアップ プランで日次バックアップを自動的に取得し、最小適用保持期間を 90 日に設定したバックアップ ボールトへ保存します。ボールトは別プロジェクトに作成してアクセスを限定でき、保持期間中は削除できないため、90 日保持のポリシーを技術的に強制できます（ランサムウェアや誤削除への備えにもなります）。スケジュール、保持、保存先の管理がすべてマネージドで自動化されるため、運用のオーバーヘッドも最小です。

【誤りの選択肢】
A：スクリプトによる自作のバックアップは、作成・保守・失敗時の監視が必要で、運用のオーバーヘッドが大きくなります。ラベルは削除日を「示す」だけで、自動的な削除や保持の強制は行われません。さらに、別プロジェクトへの保存という要件も満たしていません（なお、スナップショットはもともとリージョンまたはマルチリージョンに保存されるため、「別のゾーンにコピー」という操作自体が的外れです）。
B：Persistent Disk のスナップショットは Compute Engine が管理するリソースであり、Cloud Storage バケットにオブジェクトとして保存する仕組みはありません。また、gcloud コマンドを手動または独自に実行する方式は完全な自動化とは言えず、別プロジェクトに保存するという要件にも触れていません。
C：スナップショット スケジュールで取得を自動化する点は適切ですが、B と同様にスナップショットを Cloud Storage バケットへ「移動」することはできません。追加のスクリプトが必要になる点で運用負荷も増え、別プロジェクトでのアクセス制限や 90 日間の保持の強制も実現されていません。

【参考】
変更不可・削除不可のバックアップ用の Backup Vault | Backup and DR
ディスクをバックアップ Vault にバックアップする | Backup and DR
バックアップ プランの概要 | Backup and DR
この問題のページを開く →
問題 15セキュリティとコンプライアンスのための設計セキュリティとコンプライアンスのための設計
問題
あなたのチームは、Vertex AI を使用して、不正検出、商品レコメンデーション、顧客離反予測などのさまざまなユースケース向けに機械学習モデルを開発・デプロイする予定です。データの引き出し（データ流出）を制限することで、Vertex AI と Workbench の環境のセキュリティ体制を強化したいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    VPC ネットワークで限定公開の Google アクセスを有効にし、Vertex AI サービスが公共のインターネットを経由せずに公開 Google サービスにアクセスできるようにする。
  • 2
    VPC フローログを有効にして Vertex AI サービスとの間のネットワーク トラフィックをモニタリングし、不審なアクティビティを特定する。
  • 3
    サービス境界を作成し、ml.googleapis.com と document.googleapis.com を保護対象のサービスとして含める。
  • ✓
    サービス境界を作成し、aiplatform.googleapis.com と notebooks.googleapis.com を保護対象のサービスとして含める。

解説

【正解】D

【0からの解説】
①前提知識
・Vertex AI（現 Gemini Enterprise Agent Platform）は、ML モデルの学習・デプロイ・推論などを行う Google Cloud の AI/ML プラットフォームで、API のサービス名は aiplatform.googleapis.com です。Vertex AI Workbench（現 Agent Platform Workbench）は、データ サイエンティスト向けの Jupyter ノートブック環境で、サービス名は notebooks.googleapis.com です。Vertex AI は 2026 年 4 月に Gemini Enterprise Agent Platform へ名称が変わりましたが、名称変更後も API のサービス名（aiplatform.googleapis.com と notebooks.googleapis.com）は変わっておらず、VPC Service Controls の対応サービス一覧にもこの名前で掲載されています。
・VPC Service Controls（VPC SC）は、指定したプロジェクトと Google Cloud サービス（API）の周りに「サービス境界」を作り、境界の内側のデータが境界外へ持ち出されること（データの引き出し、データ流出）を防ぐ仕組みです。たとえば、正規の認証情報を持つ内部の人や盗まれた認証情報でも、境界外のプロジェクトのバケットへデータをコピーしたり、境界外から保護対象の API を呼び出したりする操作がブロックされます。IAM（誰が何をできるか）とは別の、コンテキストに基づく防御層です。

②要件の整理
・対象は「Vertex AI」と「Workbench」の環境。
・目的は「データの引き出し（流出）を制限する」こと → 検知ではなく、流出そのものを防ぐ制御が必要。

③正解が要件をどう満たすか
D は、サービス境界を作成し、Vertex AI の API（aiplatform.googleapis.com）と Workbench の API（notebooks.googleapis.com）を保護対象サービス（制限付きサービス）に指定します。これにより、境界内のプロジェクトにある学習データ、モデル、ノートブック環境に対するアクセスが境界ルールで制御され、境界外への API 経由のデータ持ち出しがブロックされます。Google は Vertex AI のデータ流出対策として VPC Service Controls の利用を推奨しており、要件を直接満たすのは D です（実運用では、学習データを置く Cloud Storage や BigQuery なども同じ境界に含めます）。

【誤りの選択肢】
A：限定公開の Google アクセスは、外部 IP を持たない VM などが内部ネットワーク経由で Google API にアクセスできるようにする機能です。通信経路をプライベートにするだけで、認証済みのユーザーが境界外のプロジェクトへデータをコピーするような流出は防げません。データ流出の制限という要件を満たしません。
B：VPC フローログは、VM のネットワーク インターフェースを通過するトラフィックのサンプルを記録する機能で、事後の分析や不審な通信の「検知」には役立ちますが、流出を「防止・制限」することはできません。また、Google API へのマネージド サービス間のデータ移動は VPC フローログでは把握できません。
C：ml.googleapis.com は旧 AI Platform（Training / Prediction）のサービス名で、すでに非推奨となり提供が終了しています。Vertex AI や Workbench は保護されません。また document.googleapis.com という名前の対象サービスはなく（Document AI のサービス名は documentai.googleapis.com）、そもそも Document AI は本問の Vertex AI / Workbench 環境とは無関係です。

【参考】
VPC Service Controls の概要
サポートされているプロダクトと制限事項 | VPC Service Controls
この問題のページを開く →

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

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

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

問題は何問ありますか？

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

解説は付いていますか？

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