模擬問題集一覧

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

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

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

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

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

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

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

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

問題 1必要な手作業とメンテナンスの量を最小限に抑えながら、コンテナ化されたすべての依存関係をキャッシュするパイプラインを設計す…CI/CD パイプライン（継続的テストを含む）の構築と実装
問題
パブリックなアップストリーム コンテナ レジストリへの依存を最小限に抑え、ビルドの再現性とセキュリティを向上させるために、コンテナ化された CI パイプラインを設計しています。必要な手作業とメンテナンスの量を最小限に抑えながら、コンテナ化されたすべての依存関係をキャッシュするパイプラインを設計する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    1. アップストリーム レジストリごとに Artifact Registry に remote Docker リポジトリを作成する。2. CI パイプラインでは、その remote リポジトリを経由してコンテナ イメージにアクセスする。
  • 2
    1. アップストリーム レジストリごとに Artifact Registry に standard Docker リポジトリを作成する。2. ビルド パイプラインで使用するコンテナを適切なリポジトリにアップロードする。
  • 3
    1. アップストリーム レジストリごとに Artifact Registry に standard Docker リポジトリを作成する。2. standard リポジトリを提供する中央の virtual Docker リポジトリを作成する。3. CI パイプラインでは、中央のリポジトリを経由してコンテナ イメージにアクセスする。
  • ✓
    1. アップストリーム レジストリごとに Artifact Registry に remote Docker リポジトリを作成する。2. remote リポジトリを提供する中央の virtual Docker リポジトリを作成する。3. CI パイプラインでは、中央のリポジトリを経由してコンテナ イメージにアクセスする。

解説

【正解】D

【0からの解説】
①前提知識：Artifact Registry には 3 種類のリポジトリ モードがあります。
・standard（標準）リポジトリ：自分で push したイメージやパッケージを保存する通常のリポジトリ。
・remote（リモート）リポジトリ：Docker Hub などのアップストリーム（外部の公開レジストリ）のプロキシとして動作し、初回の pull 時に取得したイメージを自動的にキャッシュします。以後は同じイメージを Artifact Registry から返すため、アップストリームの障害やレート制限の影響を受けにくくなり、ビルドの再現性も高まります。
・virtual（仮想）リポジトリ：複数の上流リポジトリ（standard や remote）をまとめて 1 つのエンドポイントとして公開する集約用リポジトリ。優先度（priority）に従って上流リポジトリを検索します。

②要件の整理：(a) パブリックなアップストリームへの依存を減らす、(b) すべてのコンテナ依存関係をキャッシュする、(c) 手作業とメンテナンスを最小限にする、の 3 点です。アップストリーム レジストリは複数（「アップストリーム レジストリごとに」）ある前提です。

③正解の理由：アップストリームごとに remote リポジトリを作れば、イメージは pull されたときに自動でキャッシュされ、手動のアップロード作業は不要です（(a)(b)(c) を満たす）。さらにそれらを 1 つの virtual リポジトリの背後にまとめれば、CI パイプラインは単一のエンドポイントだけを参照すればよく、アップストリームを追加・変更しても virtual リポジトリの上流設定を変えるだけでパイプライン側の設定変更が不要になります。複数のアップストリームを扱う場合のメンテナンス負荷を最も小さくできる構成が D です。

【誤りの選択肢】
A：remote リポジトリによる自動キャッシュは正しい方向ですが、アップストリームごとに別のエンドポイントを CI パイプラインが個別に参照する必要があります。アップストリームの追加・変更のたびにパイプラインの設定（イメージ参照）を書き換える必要があり、virtual リポジトリで 1 か所に集約する D に比べてメンテナンス負荷が大きくなります。
B：standard リポジトリは自動キャッシュの機能を持たないため、使用するイメージを人手で取得してアップロードし、新しいバージョンが出るたびに更新し続ける必要があります。「手作業とメンテナンスを最小限に」という要件に反します。
C：virtual リポジトリで集約している点は良いものの、その上流が standard リポジトリなので、結局イメージを手動でアップロードする作業が残ります。キャッシュが自動化されないため要件を満たしません。

【参考】
リモート リポジトリの概要 | Artifact Registry
仮想リポジトリの概要 | Artifact Registry
この問題のページを開く →
問題 2オブザーバビリティの実装と問題のトラブルシューティングオブザーバビリティの実装と問題のトラブルシューティング
問題
アプリケーションを監視するための一元化されたプラットフォームを構築しています。アプリケーションは現在、オンプレミスと、複数の Google Cloud プロジェクトにまたがるクラウド上の Kubernetes クラスタで実行されています。開発者が OpenTelemetry を使用して、オンプレミスと Google Cloud の両方の環境でインフラストラクチャとアプリケーションの両方の指標を監視できるようにしたいと考えています。同時に、運用をサポートしやすい状態に保ち、すべての指標を 1 か所に統合したいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    すべての Kubernetes クラスタ（オンプレミスと GKE）で、各 Pod と並べてサイドカーの OpenTelemetry Collector を実装する。これらのコレクタを Prometheus 形式の指標をエクスポートするように構成する。各 Kubernetes クラスタで専用の Prometheus インスタンスを使用し、中央の GKE クラスタで Thanos を使用する。GKE クラスタに Grafana をインストールし、Grafana を使用してアプリケーションを監視する。
  • ✓
    スコーピング プロジェクトを作成し、すべての Google Cloud プロジェクトをそれに追加する。Bindplane を使用して、オンプレミスの Kubernetes クラスタから Cloud Monitoring への OpenTelemetry 指標の収集を効率化する。
  • 3
    スコーピング プロジェクトとして使用する新しい Google Cloud プロジェクトを作成し、他のすべての Google Cloud プロジェクトをそれに追加する。オンプレミスで実行されているアプリケーションを計装して、指標をユーザー定義指標として Cloud Monitoring にエクスポートする。Cloud Monitoring を使用してアプリケーションを監視する。
  • 4
    OpenTelemetry Collector を使用して Google Kubernetes Engine（GKE）クラスタで Google Cloud Managed Service for Prometheus の収集を有効にし、オンプレミスの Kubernetes クラスタでは非マネージドの Prometheus を有効にする。GKE クラスタに Grafana をインストールし、Grafana を使用してアプリケーションを監視する。

解説

【正解】B

【0からの解説】
①前提知識：
・指標スコープとスコーピング プロジェクト：Cloud Monitoring では、1 つのプロジェクト（スコーピング プロジェクト）の「指標スコープ」に他のプロジェクトを追加すると、そのプロジェクトから複数プロジェクトの指標をまとめて表示・アラート設定できます。複数プロジェクトの監視を 1 か所に集約する Google 推奨の方法です。
・Bindplane：Google と提携する observIQ 社の製品で、OpenTelemetry Collector をベースにしたエージェントと管理プレーンにより、オンプレミスや他クラウドのホスト・Kubernetes から指標やログを収集して Cloud Monitoring / Cloud Logging に送ることができます。Google Cloud のドキュメントでもオンプレミスとハイブリッド クラウドの指標収集方法として案内されています。
・OpenTelemetry：ベンダー中立なテレメトリ（指標・トレース・ログ）の計装と収集の標準規格です。

②要件の整理：(a) オンプレミスと複数の Google Cloud プロジェクトの Kubernetes を監視、(b) OpenTelemetry を使ってインフラとアプリの両方の指標を扱う、(c) 運用をサポートしやすくする（自前の監視基盤を運用しない）、(d) すべての指標を 1 か所に統合、の 4 点です。

③正解の理由：スコーピング プロジェクトで Google Cloud 側の全プロジェクトの指標を集約し、オンプレミス側は Bindplane（OpenTelemetry ベース）で Cloud Monitoring に取り込めば、すべての指標がマネージドな Cloud Monitoring 1 か所に統合されます。Prometheus や Thanos などの監視基盤を自分で運用する必要もなく、(a)〜(d) をすべて満たします。

【誤りの選択肢】
A：各 Pod のサイドカー コレクタ、クラスタごとの Prometheus、中央の Thanos、Grafana をすべて自前で構築・運用する構成で、技術的には動きますが運用負荷が非常に大きく、「運用をサポートしやすく」という要件に反します。
C：スコーピング プロジェクトの部分は正しいものの、オンプレミスのアプリケーションごとにユーザー定義指標（カスタム指標）を送るよう個別に計装する必要があり、開発工数が大きくなります。またインフラ指標の収集手段がなく、「OpenTelemetry を使ってインフラとアプリの両方を監視する」要件も満たしません。
D：GKE 側は Managed Service for Prometheus を使いますが、オンプレミス側は非マネージドの Prometheus を自前で運用することになり、指標が Cloud Monitoring と自前 Prometheus に分散して 1 か所に統合されません。Grafana も自前で運用が必要で、運用負荷の面でも B に劣ります。

【参考】
Bindplane を使用してオンプレミスとハイブリッド クラウドの指標を収集する | Cloud Monitoring
指標スコープの概要 | Cloud Monitoring
この問題のページを開く →
問題 3最初に何をすべきですか。サイト信頼性エンジニアリング（SRE）のプラクティスの適用
問題
Cloud Run にデプロイしたアプリケーションがあります。最近、カナリア デプロイ戦略を使用してアプリケーションの新しいバージョンがデプロイされました。サイト信頼性エンジニアリング（SRE）チームのメンバーから、このアプリケーションの SLO が超過したと知らされました。できるだけ早くアプリケーションを正常な状態にする必要があります。最初に何をすべきですか。

選択肢と解説

  • 1
    トラフィック分割を構成して、トラフィックの 100% を最新のリビジョンに送信する。
  • ✓
    トラフィック分割を構成して、トラフィックの 100% を以前のリビジョンに送信する。
  • 3
    最後に正常だったバージョンのアプリケーションを使用して新しいリビジョンを作成する。
  • 4
    Cloud Trace を使用してレイテンシの原因を特定する。

解説

【正解】B

【0からの解説】
①前提知識：
・Cloud Run では、デプロイのたびに変更不可能な「リビジョン」が作成され、トラフィック分割で各リビジョンへ送るトラフィックの割合を自由に設定できます。カナリア デプロイでは、新しいリビジョンに一部（例: 10%）のトラフィックだけを流して様子を見ます。以前のリビジョンも残っているため、トラフィックを戻すだけで即座にロールバックできます。
・SRE のインシデント対応では「まずユーザーへの影響を軽減（mitigate）し、原因の調査はその後」が原則です。直前の変更が疑わしい場合、最速の軽減策は既知の正常な状態へのロールバックです。

②要件の整理：新バージョンのカナリア デプロイ直後に SLO 違反が発生しており、「できるだけ早く」正常化することが求められています。「最初に」何をするかが問われています。

③正解の理由：トラフィックの 100% を以前の（正常だった）リビジョンに戻せば、新たなビルドやデプロイを行うことなく、数秒でユーザー影響を止められます。原因調査はロールバックで安定させた後に行います。

【誤りの選択肢】
A：SLO 違反の原因として最も疑わしいのは新しくデプロイした最新リビジョンです。そこへ 100% のトラフィックを送ると、影響を受けるユーザーが増えて状況が悪化します。
C：最後に正常だったバージョンで新しいリビジョンを作成しても同じ結果は得られますが、イメージの再デプロイとリビジョン作成に時間がかかり、手順も増えます。以前のリビジョンがすでに存在するのにわざわざ作り直す必要はなく、「できるだけ早く」という要件で B に劣ります。
D：原因の特定は重要ですが、ユーザー影響が続いている間に調査を先行させるのは SRE の原則に反します。まず軽減（ロールバック）、その後に Cloud Trace などで原因を調査し、ポストモーテムにつなげます。

【参考】
ロールバック、段階的なロールアウト、トラフィックの移行 | Cloud Run
この問題のページを開く →
問題 4Google Cloud 組織のブートストラップと維持Google Cloud 組織のブートストラップと維持
問題
あなたの会社は、クラウドネイティブな新しい Google Cloud 組織を作成しています。この Google Cloud 組織は、最初は少数の部門で使用され、その後、多数の部門で使用されるように拡大する見込みです。各部門は、規模がさまざまな多数のアプリケーションを抱えています。あなたは VPC ネットワーク アーキテクチャを設計する必要があります。ソリューションは、必要な管理の量を最小限に抑えつつ、開発チームが変化するニーズにすばやく適応できる柔軟性を保たなければなりません。どうすればよいですか？

選択肢と解説

  • 1
    部門ごとに個別の VPC を作成し、VPC ネットワーク ピアリングで VPC 同士を接続する。
  • ✓
    部門ごとに個別の VPC を作成する。Private Service Connect を使用して VPC 同士を接続する。
  • 3
    アプリケーションごとに個別の VPC を作成する。Private Service Connect を使用して VPC 同士を接続する。
  • 4
    部門ごとに個別の VPC を作成し、Cloud VPN で VPC 同士を接続する。

解説

【正解】B

【0からの解説】
①前提知識
・VPC（Virtual Private Cloud）は Google Cloud 上のプライベートなネットワークです。組織が大きくなると「どの単位で VPC を分け、分けた VPC 同士をどうつなぐか」が設計の中心になります。
・VPC ネットワーク ピアリングは、2 つの VPC を内部 IP で直接つなぐ仕組みです。シンプルですが、①推移的ルーティングをしない（A–B、A–C をつないでも B–C は通信できない）、②ピアリングする VPC 間でサブネットの IP 範囲が重複してはいけない、③1 つの VPC が持てるピアリング数やピアリング グループ単位の割り当て（上限）がある、という制約があります。部門が増えるほどフルメッシュの接続数と IP アドレス調整の負担が急増します。
・Private Service Connect（PSC）は、サービスの提供側（プロデューサー）が自分の VPC でサービスを「公開」し、利用側（コンシューマー）が自分の VPC 内のエンドポイント（内部 IP）からそのサービスにだけアクセスする、サービス指向の接続方式です。NAT で変換されるためプロデューサーとコンシューマーの間で IP アドレスの調整が不要で、各チームが自分の VPC を独立して管理できます。コンシューマーはネットワーク全体ではなく公開されたサービスの IP だけに到達できるため、セキュリティ境界も明確です。
・注意点として、PSC は VPC 同士を「ネットワークごと」つなぐ技術ではありません。選択肢 B の「VPC 同士を接続する」は、正確には「各部門の VPC が、他部門の VPC で公開されたサービスに PSC エンドポイント経由でアクセスできるようにする」という意味に読み替えてください。
・ピアリングと PSC の違いを一言でまとめると、ピアリングは「2 つの VPC のルートを交換し、相手 VPC 内のすべての内部 IP に届くようにする（ネットワーク単位の接続）」、PSC は「相手が公開した特定のサービスにだけ、自分の VPC 内の IP アドレスで届くようにする（サービス単位の接続）」です。ネットワーク単位でつなぐと双方の IP 設計やルートを調整し続ける必要がありますが、サービス単位でつなげば各 VPC の内部設計は互いに独立したままにできます。
・Cloud VPN は IPsec トンネルで暗号化接続する仕組みで、主にオンプレミスや他クラウドとの接続に使います。

②要件と制約語の整理
・最初は少数部門 → 後で「多数の部門」に拡大（スケーラビリティ）
・各部門に規模がさまざまな「多数のアプリケーション」
・「管理の量を最小限に（minimize the amount of management）」
・「開発チームが変化するニーズにすばやく適応できる柔軟性」

③正解の根拠
部門単位で VPC を分ければ VPC の数は部門数に比例するだけで済み、部門内のアプリケーションはその VPC 内で自由に構成できます。部門間の連携は PSC で「必要なサービスだけを公開・消費する」形にすると、IP アドレスの重複を気にせず、ピアリングの上限や非推移性にも縛られずに部門を追加していけます。各部門は他部門と調整せずに自分の VPC を変更でき（柔軟性）、接続は公開サービス単位で管理されるため中央の管理負担も小さく抑えられます。したがって B が最も要件に合います。
※補足: 実務では共有 VPC（Shared VPC）による一元管理も有力な選択肢ですが、本問の選択肢には含まれていません。選択肢の中では、拡大時の管理負荷と柔軟性の両面で PSC を使う B が最善です。

【誤りの選択肢】
A：VPC ネットワーク ピアリングは少数の VPC なら簡単ですが、推移的ルーティングがないため部門が増えるとフルメッシュで接続を張る必要があり、ピアリング数の上限（ピアリング グループ単位の割り当て）にも達しやすくなります。さらに全 VPC 間でサブネットの IP 範囲が重複しないよう調整し続ける必要があり、「多数の部門へ拡大」しつつ「管理を最小限に」という要件に反します。加えて、ピアリングは相手 VPC 全体とルートを交換するネットワーク単位の接続のため、ある部門がサブネットを追加・変更すると接続先の部門にも影響が及びます。各部門が独立して素早く変更できるという「柔軟性」の点でも、公開サービス単位でつなぐ PSC（B）に劣ります。少数の VPC を単純につなぐだけならピアリングでも十分ですが、本問は「多数の部門への拡大」が前提である点が決め手です。
C：アプリケーションごとに VPC を作ると、各部門が多数のアプリケーションを持つため VPC の数が爆発的に増え、VPC・ファイアウォール・PSC エンドポイントの管理対象が膨大になります。接続方式は PSC で適切でも、分割単位が細かすぎて「管理の量を最小限に」に反します。
D：Cloud VPN は主にオンプレミスや他クラウドとの暗号化接続に使うもので、同じ Google Cloud 組織内の VPC 同士をつなぐ用途では、VPN ゲートウェイとトンネルの構築・運用、帯域の上限、トンネルごとの費用がかかります。部門が増えるほどトンネル数と管理負荷が増えるため、要件に合いません。

【参考】
Private Service Connect | Virtual Private Cloud
VPC ネットワーク ピアリング | Virtual Private Cloud
Private Service Connect のデプロイ パターン | Virtual Private Cloud
この問題のページを開く →
問題 5管理しやすいパスワード ローテーション ポリシーを実装する必要があります。CI/CD パイプライン（継続的テストを含む）の構築と実装
問題
コンテナ化されたアプリケーションを Cloud Run にデプロイしています。このアプリケーションは、データを取得するためにデータベースに接続する際にパスワードを必要とします。会社のセキュリティ要件を満たすために、パスワードは毎週ローテーションする必要があります。管理しやすいパスワード ローテーション ポリシーを実装する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    1. コンテナを Cloud Run にデプロイする。2. 毎週、新しいデータベース パスワードを Dockerfile 内の環境変数として設定した新しいコンテナを作成する。3. 新しいコンテナを Cloud Run にデプロイし、トラフィックを新しいバージョンに移行する。
  • 2
    1. パスワードを保持するシークレットを Secret Manager に作成する。2. コンテナを Cloud Run にデプロイし、シークレットの latest バージョンを環境変数として使用する。3. 毎週、新しいパスワードを持つシークレットの新しいバージョンを Secret Manager に作成する。
  • 3
    1. コンテナを Cloud Run にデプロイする。2. 毎週、ビルドフェーズで新しいデータベース パスワードをシークレットとして設定した新しいコンテナを作成する。3. 新しいコンテナを Cloud Run にデプロイし、トラフィックを新しいバージョンに移行する。
  • ✓
    1. パスワードを保持するシークレットを Secret Manager に作成する。2. コンテナを Cloud Run にデプロイし、シークレットの latest バージョンをマウントされたボリュームとして使用する。3. 毎週、シークレットの新しいバージョンを Secret Manager に作成する。

解説

【正解】D

【0からの解説】
①前提知識：Secret Manager は、パスワードや API キーなどの機密情報を「シークレット」として保存し、値を更新するたびに新しい「バージョン」を追加していくマネージド サービスです。Cloud Run からシークレットを使う方法は 2 つあります。
・環境変数として公開：値はインスタンスの起動時に解決されます。そのため Google は、環境変数で使う場合は latest ではなく特定のバージョンに固定（pin）することを推奨しています。latest を指定しても、すでに起動しているインスタンスは古い値を持ち続け、インスタンスによって値がバラバラになる可能性があります。
・ボリュームとしてマウント：ファイルを読み取るたびに Cloud Run が Secret Manager から latest バージョンの値を取得するため、シークレットのローテーションとの相性が良いと公式ドキュメントに明記されています。

②要件の整理：(a) パスワードを毎週ローテーションする、(b) 管理しやすい（再ビルド・再デプロイなどの手間を増やさない）方法にする、の 2 点です。

③正解の理由：Secret Manager にパスワードを保存し、latest バージョンをボリュームとしてマウントしておけば、毎週シークレットに新しいバージョンを追加するだけで、アプリケーションは次回ファイルを読み込んだ時点で新しいパスワードを取得できます。コンテナの再ビルドや再デプロイは不要で、パスワードがイメージに焼き込まれることもありません。

【誤りの選択肢】
A：パスワードを Dockerfile の環境変数としてイメージに焼き込むため、イメージを取得できる人なら誰でもパスワードを読めてしまい、セキュリティ上不適切です。さらに毎週のビルド・デプロイ・トラフィック移行が必要で、「管理しやすい」という要件にも反します。
B：Secret Manager を使う点は正しいですが、環境変数の値はインスタンス起動時にしか解決されません。新しいバージョンを追加しても実行中のインスタンスには反映されず、新しいリビジョンのデプロイや再起動が必要になるため、ローテーションを確実に反映させる仕組みとしては D に劣ります。Google も環境変数ではバージョン固定を推奨しています。
C：ビルドフェーズでシークレットを渡しても、その値がイメージに取り込まれる形になり、毎週のビルドと再デプロイも必要です。ビルド時シークレットは本来ビルド処理（プライベート リポジトリへのアクセスなど）に使うもので、実行時の資格情報のローテーション手段としては不適切です。

【参考】
サービスのシークレットを構成する | Cloud Run
Secret Manager でローテーション スケジュールを作成する
この問題のページを開く →
問題 6Google Cloud のアラートがこの Webhook を呼び出すように統合する必要があります。オブザーバビリティの実装と問題のトラブルシューティング
問題
あなたの会社は、すべてのモニタリング機能とアラート機能を一元化しようとしています。VPC ネットワークには、アラートをトリガーするために呼び出せる内部公開の Webhook があります。Google Cloud のアラートがこの Webhook を呼び出すように統合する必要があります。Google が推奨するプラクティスに従いつつ、コストを最小限に抑えたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    新しいトピックを使用して新しい Pub/Sub 通知チャンネルを構成する。イベントを消費するための pull サブスクリプションを作成する。
  • 2
    新しいトピックを使用して新しい Pub/Sub 通知チャンネルを構成する。イベントを取得するために、Webhook をサブスクライバーとする push サブスクリプションを作成する。
  • 3
    新しい Webhook 通知チャンネルを構成する。アラート ポリシーを編集して、新しい通知チャンネルを使用してイベントを伝播させる。
  • ✓
    新しいトピックを使用して新しい Pub/Sub 通知チャンネルを構成する。ダイレクト VPC 下り（外向き）を使用する新しい Cloud Run function を作成し、イベントを内部エンドポイントに書き込む。イベントを取得するために、Cloud Run function をサブスクライバーとする push サブスクリプションを作成する。

解説

【正解】D

【0からの解説】
①前提知識：
・Cloud Monitoring のアラート ポリシーは、条件を満たしたときに「通知チャンネル」（メール、Slack、PagerDuty、Webhook、Pub/Sub など）へ通知を送ります。
・Webhook 通知チャンネルはパブリック エンドポイントのみをサポートします（インターネットから完全にアクセス可能な HTTP/HTTPS エンドポイントが必要）。公式ドキュメントでは、公開されていないエンドポイントに通知を送りたい場合は Pub/Sub 通知チャンネルを作成し、そのトピックにサブスクリプションを構成するよう案内しています。
・Pub/Sub の push サブスクリプションは、メッセージを HTTPS エンドポイントへ送信しますが、VPC 内部の IP アドレスにしか公開されていないエンドポイントへ直接 push することはできません。
・Cloud Run functions（旧 Cloud Functions）は、ダイレクト VPC 下り（Direct VPC egress）を使うと VPC 内のプライベート IP に直接通信できます。リクエストがない間はゼロまでスケールするため、低頻度のアラート転送であればコストは最小限です。

②要件の整理：(a) 宛先は VPC 内部にのみ公開された Webhook、(b) Google 推奨のプラクティスに従う、(c) コストを最小限にする、の 3 点です。

③正解の理由：アラート → Pub/Sub 通知チャンネル → push サブスクリプション → Cloud Run function（ダイレクト VPC 下りで VPC に接続）→ 内部 Webhook という経路にすれば、公開されていない内部エンドポイントへ確実にアラートを届けられます。サーバーレスでイベント駆動のため、常時稼働の VM や Serverless VPC Access コネクタのインスタンス費用もかからず、コストも最小化できます。

【誤りの選択肢】
A：pull サブスクリプションを作るだけでは、誰がメッセージを pull して Webhook を呼び出すのかが定義されていません。pull するには常時稼働するコンシューマ（VM など）を別途用意・運用する必要があり、不完全かつコスト面でも不利です。
B：Pub/Sub の push サブスクリプションは VPC 内部にのみ公開されたエンドポイントへ直接配信できないため、内部 Webhook には届きません。
C：Webhook 通知チャンネルはパブリック エンドポイントのみをサポートしているため、VPC 内部の Webhook を直接呼び出すことはできません。内部 Webhook をインターネットに公開すればセキュリティ上の問題が生じます。

【参考】
API で通知チャンネルの作成と管理を行う | Cloud Monitoring
Cloud Run ネットワーキングのベスト プラクティス
この問題のページを開く →
問題 7サービスを実行するための、費用対効果が最も高いソリューションを選択する必要があります。パフォーマンスとコストの最適化
問題
あなたは無料の写真処理アプリケーションを提供する企業に勤務しています。写真を処理するバックエンド サービスのインフラストラクチャを設計しています。このサービスは次のとおりです。 ・Cloud Storage を使用して、未処理の写真と処理済みの写真の両方を保存する。 ・障害が発生した場合に写真の処理を再開できる。 ・コンテナ化には適していない。 写真の処理にかかる時間に関する SLO はありません。サービスを実行するための、費用対効果が最も高いソリューションを選択する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    Cloud Run を使用してサービスをデプロイする。
  • 2
    3 年間の確約利用割引を適用した標準 VM を使用してサービスをデプロイする。
  • 3
    GKE を使用してサービスをデプロイする。
  • ✓
    Spot VM を使用してサービスをデプロイする。

解説

【正解】D

【0からの解説】
①前提知識
・Spot VM は、Compute Engine の余剰容量を使う VM で、標準 VM より大幅に安価（オンデマンド料金から最大 91% 割引）です。その代わり、Compute Engine が容量を必要とするといつでもプリエンプト（停止・削除）される可能性があり、可用性の保証（SLA）もありません。そのため「中断されても再実行・再開できる」「完了時間に厳しい要件がない」バッチ処理やフォールト トレラントな処理に最適です（Spot VM はプリエンプティブル VM の後継）。
・確約利用割引（CUD）は、1 年または 3 年の利用を確約する代わりに割引を受ける仕組みで、常時稼働する安定したワークロード向けです。
・Cloud Run と GKE は、どちらもコンテナを実行するプラットフォームです。

②要件の整理
・処理状態は Cloud Storage に保存され、障害時に処理を再開できる（中断耐性あり）
・コンテナ化に適さない（Cloud Run・GKE は使えない）
・処理時間の SLO がない（遅延しても問題ない）
・無料アプリなので「費用対効果が最も高い」ことが最優先

③正解の理由
中断されても再開でき、処理時間の SLO もないため、Spot VM のプリエンプトという欠点は問題になりません。コンテナ化不要の VM で動作し、最も安価に実行できる Spot VM が最も費用対効果の高い選択です。

【誤りの選択肢】
A：Cloud Run はコンテナ イメージを実行するサービスで、要件の「コンテナ化には適していない」と矛盾します。
B：3 年間の確約利用割引は割引にはなりますが、割引率は Spot VM より小さく、さらに 3 年間の支払いを確約するため利用量が変動・減少しても費用が発生します。中断を許容できるワークロードでは Spot VM のほうが安価です。
C：GKE はコンテナ オーケストレーション サービスであり、コンテナ化に適さないサービスは実行できません。クラスタ管理の費用や運用負荷も加わります。

【参考】
Spot VM | Compute Engine
Spot VM を作成して使用する | Compute Engine
この問題のページを開く →
問題 8サイト信頼性エンジニアリング（SRE）のプラクティスの適用サイト信頼性エンジニアリング（SRE）のプラクティスの適用
問題
あなたの会社は、サイト信頼性エンジニアリング（SRE）のプラクティスに従って新しいウェブサービスを活発に開発しています。あなたは会社の SRE チームを率いており、このサービスを本番環境に向けて準備しています。この本番環境化（productionalization）のプロセスで、チームが Google 推奨の SRE プラクティスに従うようにする必要があります。次に実施すべき 2 つのアクションはどれですか？（2 つ選択）

選択肢と解説

  • ✓
    モニタリングとアラートのシステムを確立する。
  • 2
    インフラストラクチャ システムのガイドラインの文書化を開始する。
  • 3
    プロダクト チームと協力してサービスを設計する。
  • ✓
    冗長化の対策を実装する。
  • 5
    アーキテクチャと設計上の選択について詳細に議論するため、早期エンゲージメントのコンサルティングを提供する。

解説

【正解】A、D

【0からの解説】
①前提知識
Google の SRE 本（『Site Reliability Engineering』第 32 章「進化する SRE エンゲージメント モデル」）では、SRE が新しいサービスに関わる段階を、おおむね「アーキテクチャと設計」→「活発な開発（Active Development）」→「限定的な提供（Limited Availability）」→「一般提供（GA）」→「廃止」のライフサイクルとして説明しています。
・「アーキテクチャと設計」の段階では、SRE は早期エンゲージメントとして設計の相談に乗り、信頼性の高い設計パターンを提案します。
・「活発な開発」の段階に入ると、SRE はサービスを本番に出せる状態にする「本番環境化（productionizing）」を始めます。具体的には、キャパシティ計画、冗長性のための追加リソースの準備、負荷急増や過負荷への対策、ロードバランシングの実装、そしてモニタリング・アラート・パフォーマンス チューニングといった持続可能な運用プラクティスの整備です。
・選択肢を段階に当てはめると次のとおりです。
　- 「アーキテクチャと設計」段階（開発が始まる前）：C（プロダクト チームと協力した設計）、E（設計上の選択を議論する早期エンゲージメントのコンサルティング）
　- 「活発な開発」段階の本番環境化：A（モニタリングとアラート）、D（冗長化）
　- 特定の段階の中核作業ではない補助的な活動：B（インフラのガイドラインの文書化）
この対応関係を押さえると、「今どの段階にいるか」を問題文から読み取るだけで正解を絞り込めます。

②要件と制約語の整理
・サービスは「活発に開発中（actively developing）」で、すでに設計段階は過ぎている。
・今やるのは「本番環境化（productionalization）のプロセス」で、「次に（next）」取るべき行動を問われている。

③正解の根拠
活発な開発段階の本番環境化で SRE が行うべき代表的な作業は、A のモニタリングとアラートの確立（サービスの健全性を SLI で把握し、問題を検知して対応できるようにする）と、D の冗長化の実装（単一障害点をなくし、ゾーンやリージョンの障害に耐えられるようにする）です。どちらも本番運用に入る前に必須の準備であり、Google Cloud の Well-Architected Framework の信頼性の柱でも「リソースの冗長性による高可用性」と「オブザーバビリティによる障害の検出」が原則として挙げられています。

【誤りの選択肢】
B：インフラストラクチャのガイドラインの文書化は有益な作業ではありますが、SRE エンゲージメント モデルで本番環境化の中核として挙げられる活動ではありません。モニタリングや冗長化のような、本番の信頼性を直接高める作業より優先度が低く、「次に取るべき行動」として最適ではありません。文書化はどの段階でも並行して続ける作業であり、それ自体ではサービスの障害検知や耐障害性は向上しないため、本番環境化のチェックリストで優先される A・D には及びません。
C：プロダクト チームと協力したサービス設計は「アーキテクチャと設計」段階で行う活動です。本問のサービスはすでに活発に開発中であり、設計段階は過ぎているため、今のフェーズに合いません。
E：アーキテクチャと設計の選択を詳しく議論する早期エンゲージメントのコンサルティングも、設計段階で行う活動です。「早期（early）」という言葉のとおり、設計が固まる前に SRE が関与して手戻りを防ぐための活動であり、開発がすでに進んでいる本番環境化の段階で「次に」行うべき作業ではありません。問題文の「活発に開発中」「本番環境に向けて準備」という表現が、設計段階を過ぎていることを示す手がかりです。

【参考】
リソースの冗長性により高可用性システムを構築する
オブザーバビリティを使用して潜在的な障害を検出する
Well-Architected Framework: 信頼性の柱
この問題のページを開く →
問題 9Google Cloud 組織のブートストラップと維持Google Cloud 組織のブートストラップと維持
問題
あなたの会社には、12 個のマイクロサービスで構成されるアプリケーションが Google Kubernetes Engine（GKE）にデプロイされています。複数のチームが、Dev、Staging、Prod の 3 つの環境にまたがってさまざまな機能を並行して開発しています。開発者からは、共有の Dev GKE クラスタに複数のフィーチャー ブランチからデプロイが行われるため、依存関係のテストが失敗したり、リリースが遅れたりしているという報告があります。開発者が、他の開発作業から隔離された安定した開発環境でマイクロサービスの機能をテストできる、費用対効果の高いソリューションを実装する必要があります。どうすればよいですか？

選択肢と解説

  • 1
    Cloud Build を使用して CI パイプラインを自動化し、main ブランチへのマージ リクエストからコンテナ イメージの作成と Kubernetes マニフェストの更新を行う。Config Sync と統合して、自動スケーリングを有効にした Dev GKE クラスタ上に動的に作成される Namespace で新しいイメージをテストする。テスト後に Namespace をクリーンアップする処理を実装する。
  • 2
    Cloud Build を使用して CI パイプラインを自動化し、コミットごとにコンテナ イメージを作成して Kubernetes マニフェストを更新する。Cloud Deploy を使用して、Dev、Staging、Prod の GKE クラスタへのプログレッシブ デリバリーを行う。Config Sync を有効にして、環境間で一貫した Kubernetes 構成を維持する。
  • ✓
    Cloud Build を使用して CI パイプラインを自動化し、フィーチャー ブランチのコミットから Kubernetes マニフェスト ファイルを更新する。Config Sync と統合して、自動スケーリングを有効にした Dev GKE クラスタ上に動的に作成される Namespace で新しいイメージをテストする。テスト後に Namespace をクリーンアップする処理を実装する。
  • 4
    Cloud Build を使用して CI パイプラインを自動化し、フィーチャー ブランチのコミットから Kubernetes マニフェスト ファイルを更新する。Config Sync と統合して、フィーチャー ブランチごとに動的に作成される Dev GKE クラスタで新しいイメージをテストし、マージ リクエスト時にそのクラスタを削除する。

解説

【正解】C

【0からの解説】
①前提知識
・Cloud Build は Google Cloud のマネージド CI サービスで、Git リポジトリへの push などを契機にコンテナ イメージのビルドやマニフェストの更新を自動化できます。
・Config Sync は GitOps のツールで、Git リポジトリに置いた Kubernetes の構成（マニフェスト）を GKE クラスタに自動で同期します。Namespace 単位でのリソース配置も Git から宣言的に管理できます。
・Kubernetes の Namespace は、1 つのクラスタ内でリソースを論理的に分離する単位です。GKE のマルチテナンシーの考え方では、チームや用途ごとに Namespace を分け、リソース割り当てやアクセス制御で互いに干渉しないようにします。クラスタを丸ごと増やすより、はるかに安価で素早く分離環境を作れます。
・一時環境（エフェメラル環境）とは、テストのためだけに作成し、終わったら削除する環境のことです。使った分だけ費用がかかり、環境の汚染も残りません。

②要件と制約語の整理
・問題: 共有 Dev クラスタに複数のフィーチャー ブランチがデプロイされ、互いに干渉している。
・要件: 各開発者がフィーチャー（機能）を「他の開発作業から隔離された安定した開発環境」でテストできること。
・制約語: 「費用対効果が高い（cost-effective）」。

③正解の根拠
C は、フィーチャー ブランチへのコミットを契機に Cloud Build でマニフェストを更新し、Config Sync で既存の Dev GKE クラスタ上に動的に作成した Namespace へデプロイしてテストします。ブランチごとに Namespace が分かれるため他の開発作業と干渉せず、テスト後に Namespace を削除するので環境が残り続けることもありません。クラスタは 1 つを共有し、自動スケーリングで必要なときだけノードが増えるため、費用も最小限です。「隔離」と「費用対効果」の両方を満たすのは C です。

【誤りの選択肢】
A：main ブランチへのマージ リクエストを契機にしているため、フィーチャー ブランチの段階では隔離されたテストができません。開発者が求めているのは「マージ前に自分の機能を隔離環境でテストすること」であり、main への統合を前提にすると干渉の問題を解決できません。
B：コミットごとに Dev、Staging、Prod へのプログレッシブ デリバリーを行う構成で、共有 Dev クラスタに複数ブランチがデプロイされて干渉するという根本の問題を解決していません。フィーチャーごとの隔離された環境が用意されないため、要件を満たしません。
D：フィーチャー ブランチごとに GKE クラスタを丸ごと作成すると、隔離は実現できますが、クラスタの管理手数料やノードの費用、作成に要する時間がブランチ数だけ増えます。Namespace による分離で十分に隔離できる状況では費用対効果が低く、「費用対効果が高い」という制約に反します。

【参考】
クラスタ マルチテナンシー | Google Kubernetes Engine (GKE)
Config Sync の概要
ビルドトリガーの作成と管理 | Cloud Build
この問題のページを開く →
問題 10また、将来マニフェストを更新する際の開発オーバーヘッドを最小限に抑える必要があります。CI/CD パイプライン（継続的テストを含む）の構築と実装
問題
アプリケーションを Google Kubernetes Engine（GKE）にデプロイするための Cloud Deploy パイプラインを構成しています。アプリケーションは Deployment としてデプロイされます。開発環境では 2 つのレプリカ、本番環境では 5 つのレプリカになるように Deployment を構成する必要があります。他のすべての構成パラメータが環境間で一貫していることを保証しなければなりません。また、将来マニフェストを更新する際の開発オーバーヘッドを最小限に抑える必要があります。skaffold.yaml ファイルをどのように構成すればよいですか。

選択肢と解説

  • ✓
    複数のプロファイルを作成し、manifests.kustomize セクションを構成する。
  • 2
    単一のプロファイルを作成し、manifests.kustomize セクションを構成する。
  • 3
    複数のプロファイルを作成し、manifests.rawYaml セクションを構成する。
  • 4
    単一のプロファイルを作成し、manifests.rawYaml セクションを構成する。

解説

【正解】A

【0からの解説】
①前提知識：
・Cloud Deploy は、パイプラインに定義したターゲット（dev、prod など）へ順番にリリースを昇格させるマネージドな継続的デリバリー サービスで、レンダリングとデプロイには Skaffold を使います。
・Skaffold のプロファイル（profiles）：skaffold.yaml の中で環境ごとに異なる設定を定義する仕組みです。Cloud Deploy では、パイプラインの各ターゲット（ステージ）にどのプロファイルを使うかを指定できます。
・Kustomize：共通のマニフェスト（base）と、環境ごとの差分だけを記述した overlay を組み合わせて最終的なマニフェストを生成するツールです。レプリカ数のような差分だけを overlay に書けば、それ以外の設定は base を共有します。
・rawYaml：プレーンな Kubernetes マニフェストをそのまま使う方式で、差分を表現する仕組みはありません。

②要件の整理：(a) dev は 2 レプリカ、prod は 5 レプリカと環境ごとに値を変える、(b) それ以外の設定は環境間で一貫させる、(c) 将来のマニフェスト更新時の開発オーバーヘッドを最小にする、の 3 点です。

③正解の理由：環境ごとに異なる設定を出し分けるには、環境ごとのプロファイル（dev 用・prod 用の複数）が必要です。各プロファイルの manifests.kustomize に環境ごとの overlay を指定すれば、共通設定は base の 1 か所だけで管理され、レプリカ数だけが overlay で上書きされます。共通部分の変更は base を 1 回直すだけで全環境に反映されるため、一貫性の確保と更新時のオーバーヘッド最小化の両方を満たします。

【誤りの選択肢】
B：プロファイルが 1 つしかないと、ターゲットごとに異なる構成（overlay）を選び分けられず、dev と prod でレプリカ数を変えることができません。
C：複数プロファイルで環境を分けることはできますが、rawYaml では環境ごとに完全なマニフェストを別々に用意する必要があります。共通設定が重複するため、変更のたびに複数ファイルを同じように直す必要があり、設定のずれ（不一致）も起こりやすく、要件 (b)(c) に反します。
D：単一プロファイルかつ rawYaml では、環境ごとにレプリカ数を変えること自体ができません。

【参考】
Cloud Deploy でマニフェストを管理する
Cloud Deploy で Skaffold を使用する
この問題のページを開く →
問題 11この問題をトラブルシューティングする必要があります。オブザーバビリティの実装と問題のトラブルシューティング
問題
マネージド コレクションを有効にした Google Cloud Managed Service for Prometheus を使用して、Google Kubernetes Engine（GKE）で実行されているサービスから指標を収集しています。サービスをデプロイした後、Cloud Monitoring に指標データが表示されず、エラー メッセージも発生していません。この問題をトラブルシューティングする必要があります。どうすればよいですか。

選択肢と解説

  • 1
    サービスが Cloud Monitoring API への書き込みの割り当て（クォータ）を超過していないかどうかを確認する。
  • ✓
    PodMonitoring の構成が有効なポートを参照していることを確認する。
  • 3
    GKE クラスタに Grafana サービスがインストールされているかどうかを確認する。
  • 4
    サービスに monitoring.servicesViewer IAM ロールが付与されていることを確認する。

解説

【正解】B

【0からの解説】
①前提知識：
・Google Cloud Managed Service for Prometheus は、Prometheus 互換の指標を Google が管理するストレージ（Monarch）に保存し、Cloud Monitoring や PromQL で参照できるようにするサービスです。
・マネージド コレクションでは、GKE 上で Google が管理するコレクタが動作し、どの Pod の、どのポート・パスから指標をスクレイプ（収集）するかを PodMonitoring（クラスタ全体なら ClusterPodMonitoring）というカスタム リソースで指定します。
・PodMonitoring の endpoints で指定するポート（コンテナの名前付きポートやポート番号）が、実際にアプリケーションが指標を公開しているポートと一致していないと、コレクタはスクレイプ対象を見つけられず、明確なエラーを出さないまま指標が 1 件も取り込まれない状態になります。

②要件の整理：(a) マネージド コレクションを使用、(b) 指標がまったく表示されない、(c) エラー メッセージが出ていない、という状況での最初の確認事項が問われています。

③正解の理由：エラーが出ないのにデータが一切届かない場合、典型的な原因はスクレイプ設定の誤り、特に PodMonitoring が参照するポート（名前やセレクタ）と実際の公開ポートの不一致です。公式のトラブルシューティングでも、PodMonitoring のターゲットのステータスやポート設定の確認が挙げられています。まずここを確認するのが正しい手順です。

【誤りの選択肢】
A：Cloud Monitoring API への書き込みクォータを超過した場合は、コレクタのログに 429（RESOURCE_EXHAUSTED）などのエラーが記録され、また通常は一部のデータは取り込まれます。「エラーなし・データゼロ」という状況には合いません。
C：Grafana は指標を可視化するためのツールであり、指標の収集や Cloud Monitoring への取り込みには関係ありません。Cloud Monitoring にデータが表示されない原因にはなりません。
D：monitoring.servicesViewer は Cloud Monitoring のサービス（SLO 監視用）を閲覧するためのロールで、指標の書き込みには関係しません。またマネージド コレクションでは、指標の書き込みはアプリケーション自体ではなくマネージド コレクタが行います。権限不足であれば 403 エラーが記録されるはずです。

【参考】
Google Cloud Managed Service for Prometheus Observability
この問題のページを開く →
問題 12サイト信頼性エンジニアリング（SRE）のプラクティスの適用サイト信頼性エンジニアリング（SRE）のプラクティスの適用
問題
あなたの会社は本番システムを Google Cloud に移行しています。将来発生しうるインシデントによる顧客への影響を最小限に抑えるため、移行中にサイト信頼性エンジニアリング（SRE）のプラクティスを導入する必要があります。導入すべき 2 つの SRE プラクティスはどれですか？（2 つ選択）

選択肢と解説

  • ✓
    問題のデバッグと軽減の手順を記載した、最新のプレイブックを作成する。
  • 2
    問題を解決するために、すべてのチームが本番環境を変更できるようにする。
  • 3
    システムの内部の動作に基づいて、SRE チーム向けのアラートの仕組みを作成する。
  • ✓
    一般的なタスクを自動化して、重要な影響情報を分析し、オンコール チームに軽減策をインテリジェントに提案する。
  • 5
    完全な自律性と権限がオンコール チームにのみ付与されるようにする。

解説

【正解】A、D

【0からの解説】
①前提知識
・顧客への影響は「影響を受けた時間 × 影響の範囲」で決まります。SRE では、インシデントの検知までの時間（MTTD）と復旧までの時間（MTTR）を短くすることが、顧客への影響を最小化する鍵だと考えます。
・プレイブック（ランブック）は、アラートが発生したときにオンコール担当者が何を確認し、どう軽減するかをまとめた手順書です。Google の SRE 本では、プレイブックを用意して対応するとその場で考えながら対応するより MTTR がおよそ 3 倍改善すると述べられています。
・トイル（手作業で繰り返し発生し、自動化可能な運用作業）の削減と自動化も SRE の中心的な考え方です。影響範囲の分析や軽減策の候補提示を自動化すれば、オンコール担当者は判断と実行に集中でき、復旧が速くなります。
・アラートについて SRE 本は「症状（ユーザーが体験する問題：エラー率やレイテンシなど）」に基づいてアラートを出し、「原因（内部の動作）」に基づくアラートは避けるべきだとしています。内部の指標はダッシュボードやデバッグ用（ホワイトボックス モニタリング）に使います。

②要件と制約語の整理
・目的は「将来のインシデントによる顧客への影響を最小限にする」こと。
・移行中に導入する「SRE のプラクティス」を 2 つ選ぶ。

③正解の根拠
A：最新のプレイブックがあれば、オンコール担当者は手順に沿ってすばやく調査・軽減でき、MTTR が短縮されて顧客への影響が小さくなります。
D：重要な影響情報の分析と軽減策の提案を自動化すれば、インシデント対応時の手作業（トイル）が減り、判断が速く正確になります。これも MTTR の短縮に直結し、Google Cloud の Well-Architected Framework のオペレーショナル エクセレンスの柱（インシデントと問題の管理）にも合致します。

【誤りの選択肢】
B：すべてのチームが本番環境を変更できるようにすると、変更の統制が効かなくなり、権限の過剰付与（最小権限の原則に反する）や、調整されていない変更による障害の拡大を招きます。インシデントの多くは変更が原因で起きるため、顧客への影響はむしろ大きくなりがちです。
C：システムの内部の動作（原因）に基づくアラートは、ユーザーに影響のない事象でも通知が飛び、アラート疲れを招きます。SRE ではユーザーが体験する症状（SLI / SLO に基づくエラー率やレイテンシなど）でアラートを出すことが推奨されており、内部動作はデバッグ用の指標として使うのが適切です。
E：オンコール チームだけに「完全な自律性と権限」を与えるのは、最小権限の原則や変更管理の考え方に合わず、SRE のプラクティスとして推奨されるものではありません。インシデント対応では、インシデント コマンダーを中心とした役割分担と、必要な権限を必要なときに付与する仕組みが重要であり、特定チームに無制限の権限を集中させても顧客影響の最小化には直結しません。

【参考】
インシデントと問題を管理する
オブザーバビリティを使用して潜在的な障害を検出する
この問題のページを開く →
問題 13ロールアウトとロールバックの管理を改善し、古いコンテナ イメージをクリーンアップする必要があります。CI/CD パイプライン（継続的テストを含む）の構築と実装
問題
あなたの会社では、Cloud Build と Artifact Registry を使用した CI/CD パイプラインで、コンテナ イメージを Google Kubernetes Engine（GKE）にデプロイしています。イメージには最新のコミット ハッシュでタグが付けられ、開発環境と本番前環境でのテストに合格した後に本番環境へ昇格されます。最近の本番デプロイで、テストされていなかった統合機能が原因でアプリケーションに障害が発生し、業務に支障をきたす手動のロールバックが必要になりました。ロールバックの際、使用されていない古いコンテナ イメージが Artifact Registry に大量に蓄積していることに気付きました。ロールアウトとロールバックの管理を改善し、古いコンテナ イメージをクリーンアップする必要があります。どうすればよいですか。

選択肢と解説

  • 1
    Cloud Build でロールバック パイプラインを設定し、Artifact Registry のクリーンアップ ポリシーを実装する。
  • ✓
    デプロイの管理に Cloud Deploy を採用し、Artifact Registry のクリーンアップ ポリシーを実装する。
  • 3
    GKE クラスタ全体に Cloud Service Mesh をデプロイし、Artifact Registry のイメージを手動でクリーンアップする。
  • 4
    デプロイの管理に Cloud Deploy を採用し、コンテナ イメージのクリーンアップ用の Cloud Build ジョブをスケジュールする。

解説

【正解】B

【0からの解説】
①前提知識：
・Cloud Deploy は、dev → pre-prod → prod のような昇格の流れ（デリバリー パイプライン）を管理するマネージドな継続的デリバリー サービスです。リリースの昇格、承認、カナリア デプロイ、デプロイの検証に加え、以前に成功したリリースへのロールバックをコンソールや gcloud deploy targets rollback で簡単に実行できます。デプロイ履歴も記録されるため、どのイメージがどの環境に出ているかを追跡できます。
・Artifact Registry のクリーンアップ ポリシー：リポジトリに「一定期間より古いバージョンを削除する」「最新の N 個のバージョンを保持する」などの条件を設定すると、条件に合うイメージが自動で削除されます。追加のコードやジョブは不要です。

②要件の整理：(a) ロールアウトとロールバックの管理を改善する（手動で混乱を伴うロールバックをなくす）、(b) 古いコンテナ イメージをクリーンアップする、の 2 点です。どちらもマネージド機能で実現できるのが理想です。

③正解の理由：Cloud Deploy を採用すれば環境間の昇格とロールバックが組み込み機能として管理され、ロールバックは以前のリリースを再デプロイするだけで済みます。古いイメージは Artifact Registry のクリーンアップ ポリシーで自動的に削除できます。両要件をマネージド機能だけで満たすのが B です。

【誤りの選択肢】
A：Cloud Build でロールバック用のパイプラインを自作することは可能ですが、どのバージョンに戻すかの管理やリリース履歴の追跡を自分で実装・保守する必要があります。Cloud Deploy の組み込みのロールバック・リリース管理に比べて運用負荷が大きく、ロールアウト管理の改善にもなりません。
C：Cloud Service Mesh はトラフィック管理やサービス間通信の可観測性・セキュリティを提供しますが、リリースの昇格やロールバックを管理するツールではありません。また、イメージの手動クリーンアップは継続的な手作業が必要で非効率です。
D：Cloud Deploy の採用は正しいものの、イメージ削除用の Cloud Build ジョブを自作してスケジュール実行するのは、Artifact Registry に組み込まれているクリーンアップ ポリシーで済むことを自前で実装することになり、保守の手間が増えます。

【参考】
ターゲットをロールバックする | Cloud Deploy
クリーンアップ ポリシーの概要 | Artifact Registry
この問題のページを開く →
問題 14本番環境のチェックアウト プロセスを定期的にテストしてその機能を確認し、障害時に自動通知を受け取れていることを確認する必…オブザーバビリティの実装と問題のトラブルシューティング
問題
Google Cloud にデプロイする e コマース ウェブ アプリケーションを構築しています。本番環境のチェックアウト プロセスを定期的にテストしてその機能を確認し、障害時に自動通知を受け取れていることを確認する必要があります。また、管理の手間を最小限に抑え、Google が推奨するプラクティスに従いたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    Workflows を使用して機能を検証するワークフローを作成し、Cloud Tasks を使用してワークフローを定期的にトリガーする。
  • ✓
    合成モニタリング用の Cloud Run function をアラート ポリシーとともに実装する。
  • 3
    Cloud Logging でアラート ポリシーを作成し、チェックアウト プロセス中の失敗ログをモニタリングする。
  • 4
    アラート ポリシーとともに稼働時間チェックを構成する。

解説

【正解】B

【0からの解説】
①前提知識：
・合成モニタリング（合成モニター）：Cloud Monitoring の機能で、ユーザー操作を模したテスト スクリプト（例: Puppeteer や Selenium でログイン→カートに追加→購入）を Cloud Run functions（旧 Cloud Functions）として定期実行し、成功・失敗やレイテンシを記録します。合成モニターの作成時にアラート ポリシーも作成でき、失敗時に通知が届きます。スケジュール実行や結果の保存は Cloud Monitoring が管理します。
・稼働時間チェック（uptime check）：URL やホストに定期的にリクエストを送り、応答が返るか（必要に応じて特定の文字列を含むか）を確認する機能です。単一のリクエストの成否を見るもので、複数ステップのユーザー操作フローはテストできません。

②要件の整理：(a) 本番のチェックアウト プロセス（複数ステップの業務フロー）を定期的にテストする、(b) 障害時に自動通知を受け取る、(c) 管理の手間を最小限にし Google 推奨のやり方に従う、の 3 点です。

③正解の理由：チェックアウトのような複数ステップのフローを定期的に能動テストするための Google 推奨の仕組みが合成モニタリングです。Cloud Run functions でテストを実装し、アラート ポリシーと組み合わせれば、定期実行・結果の記録・失敗時の通知が Cloud Monitoring のマネージド機能として提供され、(a)〜(c) をすべて満たします。

【誤りの選択肢】
A：Workflows でテストを組むことはできますが、Cloud Tasks は個々のタスクをキューで非同期実行するサービスで、定期実行のスケジューラではありません（定期実行なら Cloud Scheduler が適切）。また結果の可視化や失敗時のアラートを自前で作る必要があり、管理の手間が大きくなります。
C：失敗ログの監視は、実際のユーザーがチェックアウトして失敗したときに初めて検知できる受動的な方法です。「定期的にテストする」という能動的な検証の要件を満たさず、利用者が少ない時間帯の障害も見逃します。
D：稼働時間チェックはエンドポイントが応答するかを確認するだけで、カートへの追加や決済といった複数ステップのチェックアウト処理が機能するかまでは検証できません。

【参考】
合成モニターを作成する | Cloud Monitoring
合成モニタリングの概要 | Cloud Monitoring
この問題のページを開く →
問題 15Google Cloud 組織のブートストラップと維持Google Cloud 組織のブートストラップと維持
問題
あなたは Cloud Workstations のワークステーション上で Code OSS を使用して Node.js のユーティリティを開発しています。このユーティリティはシンプルなウェブページで、必要なファイアウォール ルールがすべて設定されていることはすでに確認済みです。アプリケーションを Cloud Workstations のワークステーション上のポート 3000 で起動してテストしましたが、ローカル マシンからそのウェブページにアクセスできるようにする必要があります。Google 推奨のセキュリティ プラクティスに従う必要があります。どうすればよいですか？

選択肢と解説

  • 1
    踏み台ホスト（bastion host）VM 上で動作するブラウザを使用する。
  • 2
    Cloud Workstations の VM に対して gcloud compute start-iap-tunnel コマンドを実行する。
  • 3
    Cloud Workstations の構成でパブリック IP アドレスを許可する。
  • ✓
    Code OSS パネルのプレビュー リンクをクリックする。

解説

【正解】D

【0からの解説】
①前提知識
・Cloud Workstations は、Google Cloud 上で管理されたクラウド開発環境を提供するサービスです。ワークステーションには Code OSS（VS Code のオープンソース版）をベースにしたブラウザ IDE が用意されており、ローカルの PC にはブラウザがあれば開発できます。
・ワークステーション上で動かしている HTTP サーバーには、Cloud Workstations のゲートウェイ経由でブラウザからアクセスできます。URL は「https://ポート番号-ワークステーションのホスト名」（例: https://3000-ワークステーション名.クラスタID.cloudworkstations.dev）の形式で、アクセスにはログインと、ワークステーションの利用権限（roles/workstations.user または workstations.workstations.use）が必要です。つまり、IAM による認証・認可で保護された経路が最初から用意されています。
・Code OSS では、アプリがポートで待ち受けを開始すると通知やポートのパネルにブラウザで開くためのリンク（プレビュー リンク）が表示され、ターミナルに表示された http://localhost:3000 を Ctrl + クリックしても同じ URL に変換されて開けます（ワークステーションが localhost をワークステーションのホスト名に書き換えます）。

②要件と制約語の整理
・ワークステーション上のポート 3000 のウェブページに、ローカル マシンからアクセスしたい。
・ファイアウォール ルールは確認済み。
・「Google 推奨のセキュリティ プラクティスに従う」。

③正解の根拠
Code OSS のプレビュー リンクを使えば、Cloud Workstations が提供する認証付きのゲートウェイ経由で、ポート 3000 のアプリにローカルのブラウザから安全にアクセスできます。パブリック IP や追加の VM は不要で、IAM の権限を持つ本人だけがアクセスでき、追加の設定もいりません。これが Google が想定する標準の方法であり、D が正解です。

【誤りの選択肢】
A：踏み台ホスト VM を用意してそこでブラウザを動かすのは、余計な VM の構築・運用・費用が発生するうえ、攻撃対象となる経路を増やします。Cloud Workstations には認証付きでポートにアクセスする仕組みが組み込まれているため、不要かつ推奨されない方法です。
B：gcloud compute start-iap-tunnel は、自分のプロジェクトにある Compute Engine VM に対して IAP の TCP 転送でトンネルを張るためのコマンドです。Cloud Workstations のワークステーション VM はサービスが管理するもので、このコマンドの対象として使う設計にはなっていません（Cloud Workstations 用には gcloud workstations start-tcp-tunnel という専用コマンドがありますが、HTTP のウェブページを見るだけなら組み込みのプレビュー リンクで十分です）。
C：パブリック IP アドレスを許可すると、ワークステーションがインターネットから到達可能になり、攻撃対象領域が広がります。プライベートな構成を保つという Google 推奨のセキュリティ プラクティスに反し、しかもウェブページへのアクセスには不要です。

【参考】
ワークステーションで実行されている HTTP サーバーに接続する | Cloud Workstations
Cloud Workstations のアーキテクチャ
この問題のページを開く →

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

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

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

問題は何問ありますか？

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

解説は付いていますか？

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