Section 1 問題集: Bootstrapping and maintaining a Google Cloud organization

試験出題比率: 約 20% 試験ガイド対応: 2024-2025 改訂版（Infrastructure Manager GA / Cloud Workstations GA / Gemini Code Assist GA 反映） 収録問題数: 20 問

学習方針

このセクションは PCDE 試験の土台にあたる「組織設計・IaC・CI/CD・複数環境・開発環境」を扱います。 1.1〜1.5 のいずれも他セクションの前提となるため、選定基準と Google 推奨パターンを最優先で習得してください。

学習の進め方

まず通しで解く — 制限時間 30 分 / 20 問（1 問 90 秒）
採点して弱点把握 — 末尾の「正答率早見表」に記入
間違えた問題は学習資料 ../02_学習資料/01_組織と基盤/ に戻る
2 週間後に再挑戦 — 同じ問題で 90% 以上を目指す

正答率の目安

正答率	評価	次のアクション
90% 以上	合格圏	Section 2 (CI/CD 実装) に進む
80-89%	合格ライン	間違えた小項目だけ復習
70-79%	要復習	`02_応用.md` を再読
70% 未満	基礎不足	`01_基礎.md` から学び直す

難易度配分

★（基礎）: 3 問
★★（応用）: 12 問
★★★（発展）: 5 問

出題範囲対応表

試験ガイド項目	テーマ	該当問題
1.1 リソース階層・Shared VPC・IAM・Org Policy・SA・データ常駐	組織基盤	問題 1, 2, 3, 4, 5
1.2 IaC（Infrastructure Manager / CFT / Config Connector / GitOps）	IaC 選定	問題 6, 7, 8, 9
1.3 CI/CD（Cloud Build / Cloud Deploy / Artifact Registry / Binary Auth / SLSA）	CI/CD 設計	問題 10, 11, 12, 13, 14
1.4 複数環境（Ephemeral / GKE Fleet / Config Sync / パッチ）	複数環境管理	問題 15, 16, 17
1.5 セキュアな開発環境（Cloud Workstations / Cloud Shell / Gemini Code/Cloud Assist/CLI）	開発体験	問題 18, 19, 20

問題

問題 1 （難易度: ★★）

シナリオ: Cymbal Bank は日本国内の地方銀行 50 社の共同利用型勘定系基盤を Google Cloud 上に構築しています。各銀行ごとに独立した課金・IAM 境界を持ちつつ、共通の VPC 基盤・監査ログ集約・Org Policy を中央 Platform チームが制御する必要があります。プロジェクト数は 1 銀行あたり 5〜10 で、将来 100 社まで拡張予定です。サブネットレンジは銀行を跨いで重複させたくありません。

質問: このリソース階層・ネットワーク設計として 最も適切 なものはどれですか。

選択肢:

A. すべての銀行を 1 つのプロジェクトに集約し、Folder で論理分離する
B. 銀行ごとに Organization を分け、VPC Peering で相互接続する
C. 中央 common Folder にホストプロジェクトを置いた Shared VPC を作成し、銀行ごとの Folder 配下のサービスプロジェクトをアタッチする
D. 銀行ごとに独立 VPC を持ち、Network Connectivity Center のハブで全銀行を接続する

解答と解説

正解: C

解説:

C が正解: 銀行ごとの課金・IAM 境界（プロジェクト分離）を保ちつつ、中央 Platform チームが Shared VPC のホストプロジェクトでサブネット範囲・ファイアウォール・Interconnect を統制できます。Google Enterprise Foundations Blueprint で示される標準パターン（common Folder にホスト、production などにサービスプロジェクトを配置）に合致します。
A: プロジェクト統合は課金・IAM・Quota が銀行間で混ざり、規制上 NG。
B: Organization を分けると Shared VPC が使えず（同一 Org 限定）、Org Policy も中央適用できません。VPC Peering は推移性がなく 100 社規模で破綻します。
D: NCC はオンプレ・他クラウドを含むハブ・スポーク型 WAN 統合向け。同一 Org 内の集中ネットワーク管理であれば Shared VPC が第一選択です。

試験のひっかけポイント: 「複数 VPC を接続したい」だけで VPC Peering / NCC に飛びつかない。同一 Organization 内で中央集権ネットワーク管理 → Shared VPC が即答できること。

関連リソース:

問題 2 （難易度: ★★）

シナリオ: EU の医療スタートアップ Helsana は、患者データを EU リージョン外に出してはいけない という GDPR / EU Health Data Space 規制下にあります。複数の開発者が誤って us-central1 にリソースを作成してしまうインシデントが続いており、技術的に防止したいと考えています。さらに既存の本番リソースが新しい制約に違反していないか、本番投入前に確認したいです。

質問: この要件を満たすために 最も適切な組み合わせ はどれですか。

選択肢:

A. IAM Custom Role で compute.regions.create を拒否する
B. Org Policy gcp.resourceLocations を Folder に Dry Run モードで適用し、違反を確認後 Enforce する
C. VPC Service Controls の境界で us-central1 を除外する
D. Cloud Asset Inventory で定期スキャンし、違反リソースを手動削除する

解答と解説

正解: B

解説:

B が正解: gcp.resourceLocations は List Constraint で、リソース作成可能リージョンを階層単位で強制できます。2024 年に GA した Dry Run モード により、本番適用前に違反リソースを検出できるため、既存資産への影響評価ができます。
A: IAM はリージョン単位の作成権限制御ができない（Region は Resource 単位ではない）。
C: VPC SC はデータの 境界越え通信 を制御するもので、リソース作成リージョンの制限手段ではありません。
D: 検知ベースは予防策にならない（インシデント発生後）。Org Policy で予防するのが Google 推奨。

試験のひっかけポイント: 「データ常駐」=「gcp.resourceLocations」「CMEK」「Assured Workloads」の 3 点セットを暗記。Dry Run は 2024 追加 の新機能で、頻出。

関連リソース:

../02_学習資料/01_組織と基盤/01_基礎.md §5, §7
../02_学習資料/01_組織と基盤/02_応用.md §5, §6

問題 3 （難易度: ★★★）

シナリオ: SaaS 企業 LedgerPro は GitHub Actions から Google Cloud にデプロイしています。CISO 監査で「SA キーが GitHub Secrets に保管されている」ことが指摘され、6 か月以内にキー廃止が要求されました。さらに、特定リポジトリの main ブランチからのワークフローのみ本番 SA を使用可能にしたいです。複数のリポジトリで使うため柔軟性も必要です。

質問: 最小権限で SA キーを廃止する設定として 最も適切 なものはどれですか。

選択肢:

A. Workload Identity Pool と OIDC Provider を作成し、SA に roles/iam.workloadIdentityUser を principalSet://...attribute.repository_owner_id/<org>/attribute.ref/refs/heads/main 形式で付与する
B. GitHub Actions Runner を GCE 上で Self-hosted 化し、メタデータサーバから認証する
C. Cloud Build トリガーで GitHub と連携し、Cloud Build SA から GCP API を呼ぶ
D. SA キーを Secret Manager に移動し、GitHub Actions から Secret Manager API で取得する

解答と解説

正解: A

解説:

A が正解: Workload Identity Federation で OIDC ベースの STS 認証を行い、principalSet の Attribute Condition で「特定リポジトリ × 特定ブランチ」のみ SA Impersonation を許可するのが Google 推奨。SA キー完全廃止が可能。
B: Self-hosted Runner はインフラ管理負担増、CI/CD ネイティブの解決策ではない。
C: 質問の要件は「GitHub Actions からデプロイ」を維持すること。Cloud Build に置き換えるのはアーキ変更で要件外。
D: SA キー自体が存在し続けるため、漏洩リスクと監査指摘は解消しない。

試験のひっかけポイント: 「外部 CI/CD → GCP の認証」=「Workload Identity Federation」が即答。SA キーを Secret Manager に置き換えるのは キー廃止にはならない（キー自体が残るため）。

関連リソース:

問題 4 （難易度: ★★）

シナリオ: EC 企業 KartLogix は本番・ステージング・開発を 3 つのプロジェクトで運用しています。Cloud SQL（PostgreSQL）と Memorystore（Redis）を本番プロジェクトでホストし、これらをアプリの GKE クラスタ（別プロジェクト）からプライベートに利用したいです。VPC Peering を使ったプライベートサービスアクセスでも実現可能ですが、将来的にマネージドサービスが増えるため、サブネット消費と推移性問題を避けたいです。

質問: このマネージドサービスへの接続方式として 最も適切 なものはどれですか。

選択肢:

A. Shared VPC を作成し、Cloud SQL を共有サブネットに配置する
B. プライベートサービスアクセス（VPC Peering with Google）で Cloud SQL に接続する
C. Private Service Connect (PSC) エンドポイントを各サービス向けに作成し、コンシューマー側 VPC からアクセスする
D. Cloud SQL Auth Proxy をパブリック IP で立て、IAM 認証する

解答と解説

正解: C

解説:

C が正解: PSC は サービスごとにエンドポイント IP を発行し、コンシューマー側 VPC のプライベート IP として利用できます。サブネット重複も許容され、推移性問題もない（エンドポイント単位）。Google が マネージドサービス接続の推奨方式 として位置付けています。
A: Cloud SQL は Shared VPC 内に直接配置できない（プライベートサービスアクセス経由）。
B: プライベートサービスアクセスは予約範囲をすべての Google サービスで共有し、推移性も問題化しやすい（PSC が後継推奨）。
D: パブリック IP 公開は本番ではセキュリティ的に避けるべき。

試験のひっかけポイント: 「マネージドサービスにプライベート接続」→ Private Service Connect が 2024 年以降の Google 推奨。古い問題集だと Private Services Access が答えになるケースがあるが、現行試験では PSC が優先。

関連リソース:

問題 5 （難易度: ★★★）

シナリオ: グローバル製造業 FactoryNet は GCP に 200 プロジェクトを持ちます。SOC2 監査で「監査ログ（Admin Activity / Data Access）を 10 年保管」「Org 全体で 1 か所に集約」「BigQuery で SQL 分析」「セキュリティ重大度の高いものは即時 Pub/Sub 通知」が要求されています。Logging の _Required バケットは 400 日固定で要件を満たしません。

質問: この要件を満たす Logging アーキとして 最も適切な組み合わせ はどれですか。3 つ選びなさい。

選択肢:

A. Organization レベルで --include-children を指定した Aggregated Sink を作成し、Cloud Storage に長期エクスポートする
B. 各プロジェクトで個別に Sink を作成し、共通の BigQuery データセットに送る
C. Aggregated Sink で BigQuery にエクスポートし、パーティションテーブルで SQL 分析する
D. Aggregated Sink で severity >= ERROR フィルタを Pub/Sub に出力し、Cloud Functions でアラート通知する
E. _Required バケットの保持を 10 年に変更する

解答と解説

正解: A, C, D

解説:

A が正解: Organization レベルの Aggregated Sink + --include-children で配下全プロジェクトの監査ログを一括集約。Cloud Storage は 長期保管・低コスト（10 年保管に最適）。
C が正解: Aggregated Sink → BigQuery で SQL 分析。Log Analytics（Logging バケット → BigQuery リンク）でも可能だが、Sink 直送も標準パターン。
D が正解: 重大度フィルタの Sink を Pub/Sub に流し、リアルタイム通知に繋ぐのは公式パターン。
B: 200 プロジェクトで個別 Sink は運用負荷大、_Default バケット保持変更や新規プロジェクト追加時の漏れも発生する。Aggregated Sink が正解。
E: _Required バケットは 400 日固定で変更不可。誤答誘発の典型ひっかけ。

試験のひっかけポイント:

_Required バケットは保持期間変更不可（誤答誘発）
Aggregated Sink の --include-children を知っているか
1 つの Sink で複数宛先には出せない（用途別に複数 Sink を作る）

関連リソース:

問題 6 （難易度: ★）

シナリオ: GameStudio ZeroOne は新規 GCP プロジェクトで IaC を導入します。要件は (1) GCP 専用、(2) Terraform を使いたい、(3) State 管理・Lock 制御の運用負担を最小化、(4) Cloud Build から IAM ベースで API を呼んで実行したい、です。マルチクラウド要件はありません。

質問: 最も適合する IaC ツールはどれですか。

選択肢:

A. Terraform CLI を Cloud Build VM で実行し、State を GCS に保存する
B. Infrastructure Manager で Terraform を実行する
C. Config Connector で K8s CRD として GCP リソースを定義する
D. Cloud Foundation Toolkit のブループリントを手動 terraform apply する

解答と解説

正解: B

解説:

B が正解: Infrastructure Manager は GCP マネージド Terraform 実行サービスで、State 管理・Lock 制御を GCP が肩代わり。IAM ベースで API 呼び出し可能、Cloud Build から gcloud infra-manager deployments apply で実行できる。要件 (1)(2)(3)(4) を全て満たす。
A: 動作するが State Bucket・Lock の運用を自前管理する必要があり、要件 (3) を満たしにくい。
C: 既存 K8s クラスタが必要、要件外。
D: CFT はブループリント（Terraform module 集）であり、実行手段ではない。Infrastructure Manager 上で CFT を使うのが本来の組み合わせ。

試験のひっかけポイント: 「マネージド Terraform 実行サービス」=「Infrastructure Manager」を即答。CFT はパターン集、Config Connector は K8s 文化向け、と区別する。

関連リソース:

問題 7 （難易度: ★★）

シナリオ: IoT 企業 SensorWave は GKE 上に運用基盤を構築し、Kubernetes 文化が浸透しています。CI/CD は ArgoCD で GitOps を実装済みです。GCP リソース（Cloud SQL、Pub/Sub、Cloud Storage）も同じ GitOps フローで「マニフェスト → kubectl apply → 反映」できるようにしたいです。Terraform を新規導入するのは学習コストが高く、避けたいです。

質問: 最も適合する IaC アプローチはどれですか。

選択肢:

A. Terraform を Cloud Build から実行し、ArgoCD と別フローで管理する
B. Config Connector を GKE にインストールし、GCP リソースを K8s CRD で定義する
C. Infrastructure Manager に Terraform をデプロイし、API 呼び出しを ArgoCD から行う
D. Cloud Deploy のカスタムターゲットで GCP リソースを管理する

解答と解説

正解: B

解説:

B が正解: Config Connector は GCP リソースを Kubernetes CRD として定義し、kubectl apply で作成・更新できる。ArgoCD の GitOps フローに自然に統合され、K8s リコンシリエーションで差分修正も自動化される。「K8s 文化が強い組織が GCP リソースも K8s で管理したい」要件の Google 標準解。
A: Terraform 新規導入は要件と矛盾。
C: Infrastructure Manager は ArgoCD ネイティブ統合ではない。
D: Cloud Deploy は アプリのデプロイ が主用途。GCP インフラリソース管理ではない。

試験のひっかけポイント: 「K8s で GCP リソースを管理」「ArgoCD と同じフロー」→ Config Connector が即答。

関連リソース:

問題 8 （難易度: ★★）

シナリオ: 通信企業 TelcoNova は新規 Organization で Landing Zone を構築します。手作業ではなく、Google 推奨パターンを採用し、Common Folder / Network / IAM / Logging / Project Factory を一気通貫で IaC 化したいです。社内に Terraform 経験者は数名おり、ゼロから設計する時間はありません。

質問: 最も適合する出発点はどれですか。

選択肢:

A. Terraform 公式 Provider のリファレンスから自前で書き起こす
B. Cloud Foundation Toolkit の terraform-example-foundation ブループリントを採用 し、Infrastructure Manager で実行する
C. Config Connector で Org・Folder・IAM を YAML で書く
D. Deployment Manager で Org 構築する

解答と解説

正解: B

解説:

B が正解: Cloud Foundation Toolkit (CFT) の terraform-example-foundation は Google が公開している 4 ステージ Landing Zone 構築ブループリント。Bootstrap → Org → Environments → Projects の構成で、Common Folder/Network/IAM/Logging/Project Factory を含む。Infrastructure Manager 経由で実行すれば State 管理も自動。
A: ゼロから書くのは時間とミスのリスク。Google 推奨はブループリント採用。
C: Config Connector は Org/Folder/IAM の管理に弱い（GCP リソース中心）。
D: Deployment Manager は新規利用非推奨（Maintenance モード）。Terraform / Infrastructure Manager が後継。

試験のひっかけポイント: 「Google 推奨の Landing Zone」=「Cloud Foundation Toolkit + Infrastructure Manager」。Deployment Manager は 新規採用しない（試験の罠選択肢として頻出）。

関連リソース:

../02_学習資料/01_組織と基盤/02_応用.md §1, §7

問題 9 （難易度: ★★）

シナリオ: ヘルスケア SaaS の MedFlow は Terraform で GCP 基盤を 3 年運用してきました。State が単一ファイルに肥大化し、terraform plan に 15 分以上かかり、誤って本番リソースを削除してしまうリスク（blast radius 大）に悩んでいます。今後マイクロサービス化で対象リソースは 5 倍に増える予定です。

質問: この問題を解決する 最も適切な再設計 はどれですか。

選択肢:

A. Terraform を捨てて Config Connector に全面移行する
B. State を環境別（dev/stage/prod）・サービス別に分割し、依存は terraform_remote_state または data ソースで参照する
C. Terraform Workspaces で 1 つの State 内に環境を分ける
D. 並列度を上げるため、terraform apply -parallelism=100 を指定する

解答と解説

正解: B

解説:

B が正解: 大規模化したら State を環境・サービス単位で分割 し、terraform_remote_state や data ソースで他 State を参照するのが Google 推奨。Plan 時間短縮と blast radius 限定の両方を達成。
A: 全面移行は学習コストと移行リスクが大きく、根本問題（粒度設計）が解決しない。
C: Workspaces は 同じ State 内で値の切替 に近く、blast radius は減らない。Google も推奨していない。
D: -parallelism を上げると API レート超過で逆効果、根本解決ではない。

試験のひっかけポイント: Terraform Workspaces を「環境分離」の答えにしない。State 分割 がベストプラクティス。

関連リソース:

../02_学習資料/01_組織と基盤/02_応用.md §1, §12

問題 10 （難易度: ★★）

シナリオ: オンラインメディア StreamWave は Cloud Build で CI を実行しています。ビルド中に オンプレミスの社内 npm レジストリ（VPN 経由でのみアクセス可）と Cloud SQL のプライベート IP にアクセスする必要があります。デフォルトの Cloud Build はパブリック IP で動くため、これらにアクセスできません。

質問: 最も適切な解決策はどれですか。

選択肢:

A. Cloud Build を Cloud Functions 経由でプロキシする
B. Cloud Build Private Pool を Shared VPC にピアリング し、ビルドを VPC 内で実行する
C. 社内 npm レジストリと Cloud SQL を Internet 経由で公開する
D. Cloud Build を GKE 上で Self-hosted 化する

解答と解説

正解: B

解説:

B が正解: Cloud Build Private Pool は VPC ピアリング経由でビルドを VPC 内（オンプレ含む）から実行できる Google 公式機能。--peered-network でホスト VPC を指定する。
A: アーキ複雑化、Cloud Build の公式パターンではない。
C: パブリック公開はセキュリティ要件と矛盾。
D: Cloud Build は Google マネージドサービスで Self-hosted 化はできない。

試験のひっかけポイント: 「Cloud Build から VPC 内・オンプレへアクセス」=「Private Pool」が即答。Worker Pool / Private Worker Pool とも呼ばれる。

関連リソース:

問題 11 （難易度: ★★★）

シナリオ: 金融 FinTrust は GKE 上でアプリを運用します。本番デプロイは 「Cloud Build で署名されたイメージのみ許可」「未署名イメージはデプロイブロック・監査ログ出力」「gcr.io/google_containers/* は例外」 という方針です。SOC2 監査でサプライチェーンの完全性を示す必要があります。

質問: 最も適切な GCP サービス組み合わせはどれですか。

選択肢:

A. Artifact Registry の Vulnerability Scanning のみで未署名イメージを検出する
B. Binary Authorization Policy を REQUIRE_ATTESTATION + ENFORCED_BLOCK_AND_AUDIT_LOG で設定し、admissionWhitelistPatterns で例外指定。Cloud Build で署名 attestation を生成する
C. GKE の NetworkPolicy で未署名イメージのアクセスを遮断する
D. Cloud Deploy の verify ステップで署名を確認する

解答と解説

正解: B

解説:

B が正解: Binary Authorization はデプロイ前にイメージの 署名・属性検証 を行う Admission Controller。evaluationMode: REQUIRE_ATTESTATION で署名必須、enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG でブロック＋監査ログ、admissionWhitelistPatterns で例外指定が公式パターン。Cloud Build の gcr.io/cloud-builders/binauthz-attestation で attestation 生成。
A: Vulnerability Scanning は脆弱性検出であり、署名検証ではない（Software Delivery Shield の別機能）。
C: NetworkPolicy は Pod 間通信制御。イメージ署名検証ではない。
D: Cloud Deploy verify はデプロイ後のテスト実行用で、Admission 制御ではない。

試験のひっかけポイント: 「デプロイ前の署名検証・ブロック」=「Binary Authorization」が即答。Vulnerability Scanning と混同しないこと（前者は署名、後者は CVE スキャン）。

関連リソース:

問題 12 （難易度: ★★）

シナリオ: SaaS の WorkTrack は本番 Web アプリを GKE で運用しています。デプロイは現在 kubectl rollout 一括で、リリース後にエラー率増加に気づくケースがありました。今後は 「最初 5% トラフィック → 10 分間メトリクス検証 → 25% → 検証 → 100%」 という段階的リリース・自動検証・自動ロールバックを GCP マネージドで実現したいです。

質問: 最も適切な実装はどれですか。

選択肢:

A. Cloud Build パイプラインで kubectl set image を分割実行し、自前スクリプトで検証する
B. Cloud Deploy の Canary 戦略 を使い、canaryDeployment.percentages: [5, 25] と verify: true を設定する
C. Argo Rollouts を GKE にインストールし、Cloud Deploy と並行運用する
D. Cloud Run に切り替え、Traffic Splitting を使う

解答と解説

正解: B

解説:

B が正解: Cloud Deploy の Canary 戦略 は percentages で段階的にトラフィック移行、verify: true で自動検証ステップを挟み、失敗時は自動ロールバックが可能。GKE/Gateway API/Service Mesh と統合済み。
A: 自前実装は再現性・運用負担が大きく、マネージド要件と矛盾。
C: GCP マネージド要件のため、サードパーティ Argo Rollouts は不適。
D: GKE から Cloud Run へのアーキ変更は要件外。

試験のひっかけポイント: Canary / Blue-Green / Standard の戦略を Cloud Deploy 内で宣言できる ことを覚える。verify は自動検証ステップで頻出。

関連リソース:

問題 13 （難易度: ★★）

シナリオ: EC の RetailJet は Artifact Registry に Java（Maven）、Node（npm）、コンテナイメージを保管しています。コスト調査で 3 年分のイメージが溜まりストレージ費が月 USD 4,000 に。古いイメージは利用されていません。さらに、開発チームから「DockerHub レートリミットでビルド失敗」「同じ URL で本番用と開発用イメージを切り替えたい」という要望があります。

質問: この要件を満たす Artifact Registry の機能の組み合わせとして 正しいもの 3 つ を選びなさい。

選択肢:

A. Cleanup Policies で古いタグ・バージョンを自動削除
B. Remote Repository で DockerHub をキャッシュプロキシ
C. Virtual Repository で複数 upstream を 1 URL に統合
D. Artifact Registry を新リージョンに移行
E. Container Registry にダウングレード

解答と解説

正解: A, B, C

解説:

A が正解: Cleanup Policies は条件（age / keep latest N 等）で古いイメージを自動削除しストレージ削減。
B が正解: Remote Repository は DockerHub / Maven Central 等を AR がキャッシュする方式。レート制限回避とビルド高速化を実現。
C が正解: Virtual Repository は複数の upstream（Remote / Standard）を 1 つの URL で公開でき、本番・開発の切替を URL を変えずに行える。
D: リージョン移行はコスト解決ではない。
E: Container Registry は deprecated（2024 年廃止計画）、ダウングレードは禁忌。

試験のひっかけポイント: Artifact Registry の 3 機能（Cleanup Policies / Remote / Virtual Repository）は頻出。Container Registry は 新規利用不可・Artifact Registry に移行必須。

関連リソース:

問題 14 （難易度: ★★）

シナリオ: レガシーシステムの Sentinel Logistics は社内に Jenkins クラスタが 20 台 あり、500 ジョブが稼働中です。新しいマイクロサービス（GKE on GCP）は GCP ネイティブ CI/CD を採用したいですが、既存 Jenkins を一括廃止するリスクは取れません。

質問: 最もリスクが低く Google 推奨 の移行アプローチはどれですか。

選択肢:

A. 全 Jenkins ジョブを 3 か月で Cloud Build に一括移行する
B. 既存 Jenkins は GCE/GKE で運用継続し、新規サービスから Cloud Build + Cloud Deploy + Artifact Registry を採用し段階移行する
C. Jenkins を Cloud Build から docker run jenkins で起動する
D. Cloud Composer で Jenkins ジョブをラップする

解答と解説

正解: B

解説:

B が正解: 既存資産を GKE/GCE 上で運用継続 しつつ、新規サービスから GCP ネイティブに移行するのが Google が一貫して推奨する段階移行パターン。リスクと学習コストを最小化。
A: 一括移行はリスク大、要件と矛盾。
C: 動作はするが永続化・スケール・Plugin 管理が大変、移行戦略にならない。
D: Composer は Apache Airflow ベースのワークフロー、CI/CD 置換ではない。

試験のひっかけポイント: Google は 「リフトしながら段階移行」 を一貫推奨。「一括置換」は試験では基本的に不正解。

関連リソース:

../02_学習資料/01_組織と基盤/02_応用.md §13

問題 15 （難易度: ★★）

シナリオ: 広告配信プラットフォーム AdReach は GitHub PR ごとに 「PR 専用環境を自動作成 → レビュアーがブラウザで動作確認 → PR マージ後に自動破棄」 を実現したいです。1 日 100 PR、レビュアー数十人、コストを抑える必要があります。GKE クラスタは既に運用中です。

質問: 最も適切な実装はどれですか。

選択肢:

A. PR ごとに新規 GKE クラスタを作成する
B. 既存 GKE クラスタ内で PR ごとに Namespace を作成 し、Cloud Build トリガーで kubectl apply、PR クローズ時に Namespace 削除する Ephemeral 環境
C. PR ごとに Cloud SQL インスタンスを作成し、Backend 接続テストを行う
D. すべての PR を 1 つの dev 環境にデプロイし、最後のデプロイで上書きする

解答と解説

正解: B

解説:

B が正解: Namespace per PR は GKE Ephemeral 環境の 最軽量 パターン。既存クラスタを再利用しコストを抑え、独立性も担保。Cloud Build トリガー（PR open / close）と組み合わせる定石。
A: クラスタ単位は独立性が高いが、起動 5-10 分・コスト過大で 100 PR/日は非現実的。Autopilot でも要件と合いにくい。
C: 質問の本質は 環境分離。Cloud SQL 単体作成は要件と異なる。
D: 上書き方式は同時 PR を破壊しレビュー成立しない。

試験のひっかけポイント: Ephemeral 環境は 「軽量 = Namespace per PR」「独立性 = Cluster per PR (Autopilot)」「Cold Start 許容 = Cloud Run per PR」 の使い分け。100 PR/日のコスト制約があるため Namespace が正解。

関連リソース:

問題 16 （難易度: ★★★）

シナリオ: グローバル SaaS の OmniSync は 東京・米国・欧州・オンプレ（GKE on bare metal） で合計 12 GKE クラスタを運用します。すべてのクラスタに同一の Network Policy、PodSecurity ポリシー、Namespace 構成を Git から自動同期したいです。さらに、team ラベル必須・特権コンテナ禁止などのポリシー違反を検出・拒否したいです。

質問: 最も適切な GCP サービス組み合わせはどれですか。

選択肢:

A. 各クラスタに個別 Argo CD をインストールし、別々の Git リポを参照する
B. GKE Fleet にすべてのクラスタを登録し、Config Sync（RootSync）で Git 同期、Policy Controller で OPA/Gatekeeper ポリシー強制
C. Terraform で各クラスタに kubectl apply する
D. Cloud Deploy で全クラスタにデプロイする

解答と解説

正解: B

解説:

B が正解: GKE Fleet はマルチクラスタ管理の論理単位で、Config Sync で Git → Fleet 内全クラスタへマニフェスト一括同期、Policy Controller（OPA/Gatekeeper）で team ラベル必須等の Constraint Template によるポリシー強制が可能。オンプレ含むハイブリッド構成にも対応（GKE Enterprise）。
A: 個別 Argo CD は集中管理にならず運用負担増。
C: Terraform は静的、リコンシリエーションがない（手動 drift 修正必要）。
D: Cloud Deploy はアプリデプロイ用、ポリシー強制機能なし。

試験のひっかけポイント: 「マルチクラスタ + ポリシー強制」=「Fleet + Config Sync + Policy Controller」の 3 点セット。Anthos Config Management の現行名でもあり、頻出。

関連リソース:

問題 17 （難易度: ★★）

シナリオ: ゲーム配信プラットフォーム PlayCast は GKE クラスタを Stable Release Channel で運用しています。年末年始のセール期間（12/20〜1/5）は絶対にクラスタアップグレードを走らせたくありません。さらに、通常運用では土日深夜 (JST) のみアップグレードしてほしいです。

質問: 最も適切な設定の組み合わせはどれですか。2 つ選びなさい。

選択肢:

A. Maintenance Window を FREQ=WEEKLY;BYDAY=SA,SU で土日深夜（JST 相当の UTC）に設定する
B. Maintenance Exclusion を 12/20〜1/5 で no_upgrades スコープで設定する
C. Release Channel を None に変更してアップグレードを無効化する
D. Cluster Autoscaler を無効化する
E. クラスタを停止する

解答と解説

正解: A, B

解説:

A が正解: Maintenance Window は週次の許可時間帯を指定（RFC5545 RRULE 形式）。
B が正解: Maintenance Exclusion は特定期間アップグレードを停止する仕組み。スコープは no_upgrades（マイナー最長 180 日 / マイナー含む最長 30 日等）。セール期間に必須。
C: Release Channel None は アップグレード管理を放棄 することになり、セキュリティパッチも当たらず推奨されない。
D: Autoscaler 無効化はワークロードスケーリング停止、アップグレード制御ではない。
E: クラスタ停止は本番継続要件に反する。

試験のひっかけポイント: Maintenance Window（時間帯許可）と Maintenance Exclusion（期間中の停止）の 使い分け を理解しているか。両方併用が正解。

関連リソース:

問題 18 （難易度: ★）

シナリオ: SaaS スタートアップ DevPilot は 30 名のリモート開発者 を抱え、それぞれ自宅 PC のスペック・OS が異なります。新規入社時のセットアップに 2-3 日かかり、works on my machine 問題が頻発しています。さらに本番 VPC 内の社内 API を開発者がローカルから直接叩く必要があります（VPN 経由）。

質問: 最も適切な解決策はどれですか。

選択肢:

A. 全員に macOS 統一の物理マシンを配布する
B. Cloud Workstations を Private Cluster で構築し、ベースイメージにツール・拡張機能をプリセット、VPC 内から社内 API にアクセス可能にする
C. Cloud Shell を共有して開発する
D. Compute Engine VM を各自に配布し、SSH で開発する

解答と解説

正解: B

解説:

B が正解: Cloud Workstations は VPC 内に配置できるブラウザベース開発環境（VM）。カスタムイメージで IDE/ツール/拡張機能をプリセットでき、新規入社時に 数分でセットアップ完了。Private Cluster + IAP で社内 API/プライベートリソースに安全アクセス可。
A: 物理マシン統一はコスト・物理配送・OS バージョン管理で運用負担大。
C: Cloud Shell は 60 分非アクティブで停止・週合計利用時間制限・5 GB のみ永続 で本格開発に不向き。
D: GCE VM は IDE/拡張機能の標準化がなく、結局個別運用に。

試験のひっかけポイント: Cloud Workstations と Cloud Shell の 使い分け：本格開発・長時間 → Workstations、軽い試し打ち → Shell。

関連リソース:

問題 19 （難易度: ★★）

シナリオ: コンサルティング会社 CloudOpsX のエンジニアが Google Cloud Console で「prod-payment-001 プロジェクトの GKE Pod の 5xx エラーが直近 1 時間で 3 倍に増えた」と気づきました。ログ・メトリクス・トレースを横断的に調査し、根本原因の仮説を素早く出したいです。エンジニアは Cloud Logging クエリに不慣れです。

質問: 最も適切な GCP の AI アシスタント機能はどれですか。

選択肢:

A. Gemini Code Assist（IDE 内のコード補完）
B. Gemini Cloud Assist の Investigations で「prod-payment-001 の 5xx 増加原因」を自然言語で問い合わせる
C. Gemini CLI でローカル PC からクエリを実行
D. Vertex AI のチャットモデルで Logging クエリを生成

解答と解説

正解: B

解説:

B が正解: Gemini Cloud Assist は GCP Console に組み込まれた AI アシスタントで、Investigations 機能はログ・メトリクス・トレースから障害の 根本原因の仮説とストーリー を自動構築。Console 内で完結し、Logging クエリ不慣れでも利用可。2024-2025 の新機能で試験頻出。
A: Gemini Code Assist は IDE 内コーディング支援用。Console 内の障害調査ではない。
C: Gemini CLI はターミナル/リポジトリ操作向け。Console 内 Investigations が最適。
D: Vertex AI チャットは汎用 LLM。GCP のログ・メトリクスとネイティブ統合した Cloud Assist が正解。

試験のひっかけポイント: 3 つの Gemini を 役割で区別：

Code Assist → IDE 内コーディング
Cloud Assist → GCP Console 内運用・設計
CLI → ターミナル / リポジトリ自動化

関連リソース:

問題 20 （難易度: ★★★）

シナリオ: スマートホーム企業 NestWave は新規プロジェクトで Cloud Workstations を全社展開予定です。CISO 要件は以下：(1) インターネットからアクセス不可、(2) Persistent Disk は 顧客管理鍵で暗号化、(3) コンテナイメージも顧客管理鍵で暗号化、(4) Workstation 自体の 作成・アクセス・操作監査ログ が必要、(5) VPC Service Controls 境界内 に閉じる。

質問: これらすべての要件を満たすために必要な機能の組み合わせとして 適切なもの 4 つ を選びなさい。

選択肢:

A. Private Cluster で Workstation を Public IP なしで構築（IAP 経由アクセス）
B. Persistent Disk CMEK を Cloud KMS で構成
C. コンテナイメージ CMEK（Artifact Registry CMEK）を構成
D. Cloud Audit Logs（Admin Activity / Data Access） を有効化
E. Workstation 全台にパブリック IP を割り当て、Cloud Armor で保護
F. Cloud Functions で監視するが Audit Logs は不要

解答と解説

正解: A, B, C, D

解説:

A が正解: Cloud Workstations の Private Cluster はパブリック IP を持たず、Identity-Aware Proxy (IAP) 経由でブラウザアクセス可。要件 (1)(5) を満たす。
B が正解: Persistent Disk の CMEK（Cloud KMS）を構成し、要件 (2) を満たす。
C が正解: Artifact Registry の CMEK でコンテナイメージも顧客管理鍵で暗号化、要件 (3) を満たす。
D が正解: Admin Activity（常時有効）+ Data Access Logs（明示的に有効化）で要件 (4) を満たす。
E: パブリック IP 付与は要件 (1)(5) と矛盾。Cloud Armor は WAF であり、VPC SC 境界の代替ではない。
F: Audit Logs 不要は要件 (4) と矛盾。

試験のひっかけポイント:

Cloud Workstations のセキュリティ機能（Private Cluster / CMEK / VPC SC / IAP / Audit）は すべて GA で組み合わせ可 を覚える
IAP は VPN を不要にする SSO 認証付きトンネル、Cloud Workstations Private のアクセス方式として頻出

関連リソース:

../02_学習資料/01_組織と基盤/02_応用.md §11

正答率早見表

学習者用チェックリスト。回答後に記入し、弱点把握に使ってください。

問題	難易度	試験ガイド項目	テーマ	正誤
1	★★	1.1	Shared VPC / 階層	☐
2	★★	1.1	Org Policy / Dry Run / データ常駐	☐
3	★★★	1.1	Workload Identity Federation	☐
4	★★	1.1	Private Service Connect	☐
5	★★★	1.1	Aggregated Sink / Logging 集約	☐
6	★	1.2	Infrastructure Manager	☐
7	★★	1.2	Config Connector	☐
8	★★	1.2	CFT / Landing Zone	☐
9	★★	1.2	Terraform State 分割	☐
10	★★	1.3	Cloud Build Private Pool	☐
11	★★★	1.3	Binary Authorization	☐
12	★★	1.3	Cloud Deploy Canary	☐
13	★★	1.3	Artifact Registry Cleanup/Remote/Virtual	☐
14	★★	1.3	CI/CD 段階移行戦略	☐
15	★★	1.4	Ephemeral 環境（Namespace per PR）	☐
16	★★★	1.4	Fleet / Config Sync / Policy Controller	☐
17	★★	1.4	Maintenance Window / Exclusion	☐
18	★	1.5	Cloud Workstations	☐
19	★★	1.5	Gemini Cloud Assist Investigations	☐
20	★★★	1.5	Cloud Workstations セキュリティ	☐

目標スコア

合格圏: 18/20 (90%) 以上
合格ライン: 16/20 (80%) 以上
要復習: 14/20 (70%) 未満

弱点別の復習リンク

弱点領域	該当問題	復習先
リソース階層・Shared VPC・PSC	1, 4	`01_基礎.md` §2-3, `02_応用.md` §1-2
IAM / Workload Identity Federation	3	`01_基礎.md` §5-6, `02_応用.md` §4
Org Policy / データ常駐	2, 17	`01_基礎.md` §5, §7, `02_応用.md` §5-6
Logging / Monitoring 集約	5	`01_基礎.md` §4, `02_応用.md` §3
IaC（IM / CFT / Config Connector / Terraform）	6, 7, 8, 9	`01_基礎.md` §8, `02_応用.md` §7
Cloud Build / Cloud Deploy / Artifact Registry	10, 12, 13, 14	`01_基礎.md` §9, `02_応用.md` §8
Binary Authorization / Software Delivery Shield	11	`02_応用.md` §8
複数環境 / Fleet / Config Sync / Policy Controller	15, 16, 17	`01_基礎.md` §10, `02_応用.md` §9-10
Cloud Workstations / Cloud Shell	18, 20	`01_基礎.md` §11, `02_応用.md` §11
Gemini Code Assist / Cloud Assist / CLI	19	`01_基礎.md` §11, `02_応用.md` §11

次のセクション問題集

Section 2: Building and implementing CI/CD pipelines (~22%) → section2_問題集.md（作成予定）
Section 3: Applying SRE practices (~22%) → section3_問題集.md（作成予定）
Section 4: Implementing observability practices (~22%) → section4_問題集.md（作成予定）
Section 5: Optimizing performance and managing costs (~14%) → section5_問題集.md（作成予定）

試験対策のコツ: Section 1 は他セクション全ての前提です。本問題集で 90% を取れない場合は、Section 2 以降に進む前に ../02_学習資料/01_組織と基盤/ を再読し、特に「Shared VPC vs Peering vs PSC」「Workload Identity Federation」「Cloud Build + Cloud Deploy + Artifact Registry」「Fleet + Config Sync + Policy Controller」「Cloud Workstations + Gemini 3 兄弟」の即答力を固めてください。