Section 2 問題集: CI/CD パイプラインの構築と実装

試験出題比率: 約 25%（4 セクション中最大ウェイト・最重要） 試験ガイド対応: 2025 年 10 月改訂版 収録問題数: 25 問（他セクションより多め）

学習方針

このセクションは PCDE 試験で最大の比重を占める「CI/CD パイプライン」を扱います。 Cloud Build / Cloud Deploy / Artifact Registry / Binary Authorization / Workload Identity Federation / SLSA / Software Delivery Shield など、サプライチェーンセキュリティを中心とした出題が中心です。

学習の進め方

まず通しで解く — 制限時間 40 分 / 25 問（1 問 90-100 秒）
採点して弱点把握 — 末尾の「正答率早見表」に記入
間違えた問題は学習資料 ../02_学習資料/02_CICDパイプライン/ に戻る
1 週間後に再挑戦 — 同じ問題で 90% 以上を目指す

正答率の目安

正答率	評価	次のアクション
90% 以上	合格圏	Section 3（SRE）へ進む
80-89%	合格ライン	間違えた領域だけ復習
70-79%	要復習	`02_応用.md` を再読
70% 未満	基礎不足	`01_基礎.md` から学び直す

難易度配分

★（基礎）: 3 問
★★（応用）: 15 問
★★★（発展）: 7 問

出題範囲対応表

試験ガイド項目	該当問題
2.1 パイプライン設計（CI/CD、Artifact Registry、ハイブリッド/マルチクラウド、トリガー、承認）	問題 1, 2, 3, 4, 5, 17, 19
2.2 パイプライン実装（監査、canary/blue-green、トラブルシュート、ML パイプライン）	問題 6, 7, 8, 9, 10, 11, 20, 23
2.3 パイプライン構成とシークレット（KMS、Secret Manager、Parameter/Certificate Manager、WIF）	問題 12, 13, 14, 15, 16, 21
2.4 デプロイパイプラインのセキュリティ（Artifact Analysis、Binary Authorization、SLSA、SDS、IAM）	問題 18, 22, 24, 25

問題

問題 1 （難易度: ★★）

シナリオ: Cymbal Bank（オンラインバンキング）の SRE チームは、毎晩深夜の脆弱性スキャン結果を Pub/Sub に publish しています。CVE が HIGH 以上で検出されたコンテナイメージを自動的に再ビルド・再デプロイするパイプラインを構築したいと考えています。アプリケーションは GKE 上で稼働し、Cloud Build を CI、Cloud Deploy を CD に使用しています。

質問: このイベント駆動の自動再ビルドを最も適切に実現する Cloud Build トリガー設定はどれですか。

選択肢:

A. gcloud builds triggers create scheduled で毎晩 03:00 にスキャン後再ビルドを実行
B. gcloud builds triggers create pubsub で Pub/Sub トピックをサブスクライブし、$(body.message.data.image) を substitution として渡す
C. gcloud builds triggers create webhook を作成し Cloud Functions から HTTP で叩く
D. gcloud builds triggers create manual --require-approval で SRE が手動実行する

解答と解説

正解: B

解説:

B が正解: Cloud Build の Pub/Sub トリガー は、Pub/Sub トピックにメッセージが届くたびにビルドを起動できます。--substitutions='_IMAGE=$(body.message.data.image)' のように Pub/Sub メッセージ本文の値を substitution として取り込む ことが可能で、CVE 検出 → メッセージ送出 → 再ビルドの自動化に最適です。
A: スケジュールでは「CVE が検出された時」というイベント駆動にならず、無駄な再ビルドが発生します。
C: Webhook トリガーは外部 HTTP からの起動には使えますが、Pub/Sub → Cloud Functions → Webhook と中継が増え不必要に複雑です。
D: 手動承認は自動化要件を満たしません。

試験のひっかけポイント: Cloud Build には push / PR / tag / manual / webhook / pubsub / scheduled の 7 種類のトリガーがあります。「イベント駆動」=「Pub/Sub」が定石。scheduled は時刻ベース、webhook は外部 HTTP ベース。混同しないこと。

関連リソース:

../02_学習資料/02_CICDパイプライン/02_応用.md §3.4

問題 2 （難易度: ★★）

シナリオ: Altostrat Retail はマイクロサービス 30 個を GKE で運用し、Cloud Deploy を採用しています。各サービスは個別のパイプラインを持ちますが、リリース時に dev → staging → prod という 3 段階を経て、prod は 米国・欧州・アジア の 3 リージョンに 同時並列デプロイ したいです。

質問: Cloud Deploy で、最後の prod ステージのみ 3 リージョン並列展開する最も適切な構成はどれですか。

選択肢:

A. パイプラインを 3 本作成し、それぞれ US / EU / ASIA のターゲットへデプロイする
B. multiTarget リソースを定義して targetIds に prod-us, prod-eu, prod-asia を列挙し、パイプラインのステージに multi-prod を指定する
C. 1 つの GKE Multi-Cluster Ingress を作り、単一の prod ターゲットでデプロイする
D. Cloud Deploy の customCanary ストラテジで percentages: [33, 66, 100] を指定して 3 リージョンに分配する

解答と解説

正解: B

解説:

B が正解: Cloud Deploy の multiTarget は、複数の子 target を同時並列に展開する公式機能です。1 つの Release から 3 リージョンへ並列デプロイが可能で、いずれかが失敗すれば multi-target rollout 全体が FAILED になります。
A: 3 本のパイプラインに分けると Release の一貫性が保てず、トレーサビリティが劣化します。
C: Multi-Cluster Ingress はトラフィック制御の機能で、CD の並列実行とは別レイヤです。
D: customCanary はトラフィック割合制御で、リージョン並列展開とは別概念です。

試験のひっかけポイント: 「複数リージョン同時デプロイ」は multiTarget が公式回答。canary の percentages はあくまで「同一ターゲット内のトラフィック比率」を表すもので、リージョン分割の手段ではないことに注意。

関連リソース:

../02_学習資料/02_CICDパイプライン/02_応用.md §5

問題 3 （難易度: ★★）

シナリオ: EHR Healthcare（医療 SaaS、HIPAA 規制下）は、社内ポリシーで「本番デプロイは main ブランチからのみ・要承認・複数人レビュー が必須」と定められています。リリースを作る人と承認する人を別人物にしなければなりません。

質問: Cloud Deploy で職務分掌（separation of duties）を実装する最も適切な IAM 設計はどれですか。

選択肢:

A. リリース担当者と承認者の両方に roles/clouddeploy.admin を付与する
B. リリース担当者に roles/clouddeploy.releaser、承認者に roles/clouddeploy.approver を付与し、prod Target に requireApproval: true を設定する
C. 全員に roles/clouddeploy.operator を付与し、承認は GitHub PR で行う
D. リリース担当者に roles/clouddeploy.developer、承認者に roles/clouddeploy.viewer を付与する

解答と解説

正解: B

解説:

B が正解: Cloud Deploy には専用ロール roles/clouddeploy.releaser（release 作成・promote）と roles/clouddeploy.approver（承認のみ）が用意されています。これに加えて Target 定義に requireApproval: true を入れることで、prod デプロイは PENDING_APPROVAL で停止し、別人物の承認が必須になります。
A: admin を両方に付けると職務分掌が崩れます。
C: GitHub PR レビューはソースコード変更のレビューであり、Cloud Deploy のデプロイ承認とは別レイヤです。
D: viewer は閲覧のみで承認権限がありません。

試験のひっかけポイント: PCDE では「release を作る人と承認する人を分ける」職務分掌が頻出。releaser + approver の組み合わせを覚えること。requireApproval: true は Target レベル で設定する点も重要。

関連リソース:

../02_学習資料/02_CICDパイプライン/02_応用.md §4

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

シナリオ: Shipping Co. のチームは Cloud Build から VPC 内のプライベート GKE クラスタの API サーバ と オンプレ DB（Cloud Interconnect 経由） に接続してデプロイ・データマイグレーションを実行する必要があります。現在はデフォルトの Cloud Build プールを使っていますが、両方への接続が失敗します。

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

選択肢:

A. デフォルトプールのままで --network=default を gcloud builds submit に追加する
B. Cloud Build Private Pool（Worker Pool） を作成し、VPC ピアリングまたは Private Service Connect でターゲット VPC に接続する
C. Cloud Functions 経由でデプロイし、Cloud Build はビルドのみを担当する
D. 各 GKE ノードに Public IP を付与してデフォルトプールから到達可能にする

解答と解説

正解: B

解説:

B が正解: デフォルト Cloud Build プールは Google マネージドの共有環境で、ユーザー VPC にはアクセスできません。Private Pool（Worker Pool） を作成すると、VPC ピアリング / Private Service Connect で顧客 VPC とつなぎ、プライベート GKE エンドポイント・Cloud SQL・オンプレ DB（Interconnect 経由）へアクセス可能になります。
A: デフォルトプールには --network オプションは存在しません。
C: Cloud Functions は CI ステップの代替にならず、責任範囲が広がります。
D: プライベート GKE の意味がなくなり、セキュリティを大きく損ないます。

試験のひっかけポイント: 「プライベート GKE / オンプレ / VPC 内リソースへの CI アクセス → Private Pool」は鉄則。試験では「ネットワーク到達性」「private endpoint」「VPC ピアリング」「on-prem」のキーワードが出たら Private Pool を選ぶ。

関連リソース:

../02_学習資料/02_CICDパイプライン/01_基礎.md §2.8

問題 5 （難易度: ★）

シナリオ: ある DevOps エンジニアが cloudbuild.yaml を作成中、複数の環境向けに同じ設定ファイルを使いまわしたいと考えています。trigger 設定で _ENV=prod のように環境名を渡し、それを使ってデプロイ先を切り替えたいです。

質問: Cloud Build でカスタム置換変数を定義する正しい構文はどれですか。

選択肢:

A.
```
substitutions:
  ENV: 'dev'
```
B.
```
substitutions:
  _ENV: 'dev'
```
C.
```
variables:
  ENV: 'dev'
```
D.
```
env:
  ENV: 'dev'
```

解答と解説

正解: B

解説:

B が正解: Cloud Build の ユーザー定義置換変数は必ずアンダースコア _ から始める 必要があります。これは $PROJECT_ID 等の組み込み変数と衝突しないようにするためです。トリガー作成時に --substitutions=_ENV=prod で上書きできます。
A: アンダースコアなしのキーは公式に拒否されます。
C: variables というフィールドは Cloud Build に存在しません。
D: env は step ごとの環境変数で、substitution とは別の機能です。

試験のひっかけポイント: ユーザー変数は _ プレフィックス必須（例: _ENV、_REGION、_IMAGE）。組み込み変数は _ なし（例: $PROJECT_ID、$SHORT_SHA、$BUILD_ID）。試験ではこの構文ミスをよく狙ってくる。

関連リソース:

../02_学習資料/02_CICDパイプライン/01_基礎.md §2.5

問題 6 （難易度: ★★）

シナリオ: Cymbal Games のオンラインゲームバックエンドを GKE で運用しています。最新リリースは新機能を含みますが、本番ユーザーの 5% にだけ 流して、4xx/5xx エラー率を Cloud Monitoring で観測し、問題なければ段階的にトラフィックを増やしたいです。検証は Cloud Deploy が自動で行います。

質問: このシナリオに最も適したデプロイ戦略と Cloud Deploy 設定はどれですか。

選択肢:

A. Blue/Green デプロイで新環境を構築し、LB を切り替える
B. strategy.canary を定義し、canaryDeployment.percentages: [5, 25, 50] と verify: true を指定する
C. Rolling Update で maxSurge: 5%, maxUnavailable: 0 を設定する
D. Feature Flag を使い、コードでユーザー 5% にだけ新機能を有効化する

解答と解説

正解: B

解説:

B が正解: 「一部トラフィックを新版に流す＋メトリクス検証＋段階的拡大」は canary デプロイの定義そのもの。Cloud Deploy では strategy.canary.canaryDeployment.percentages で段階を指定し、verify: true を付ければ各 phase で skaffold の verify ジョブが自動実行されます。失敗すれば次 phase に進まずに FAILED になります。
A: Blue/Green は全トラフィックを一度に切り替えるため、「5% だけ」の要件に合いません。
C: Rolling Update は Pod 単位の段階的置換で、トラフィック割合の精密制御はできません。
D: Feature Flag は機能の有効化制御で、「新バージョンの動作確認」が目的なら canary が正解。

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

「段階的トラフィック＋メトリクス検証」= canary
「即時切り戻し最優先」= Blue/Green
「A/B テスト・機能の段階開放」= Feature Flag
「通常のローリング更新」= Rolling 混同しないこと。

関連リソース:

../02_学習資料/02_CICDパイプライン/02_応用.md §2

問題 7 （難易度: ★★）

シナリオ: あなたは Cloud Run で公開している API のデプロイ担当です。新バージョン v2 のリリース直後に重大なバグが発覚し、5 秒以内に v1 に完全ロールバック したいです。GCP マネージドで最もシンプルな方法を選んでください。

質問: Cloud Run で即時ロールバックする最も適切な手段はどれですか。

選択肢:

A. gcloud run services delete で v2 サービスを削除する
B. Cloud Build を再実行して v1 を再ビルドし、デプロイする
C. gcloud run services update-traffic myapp --to-revisions=myapp-v1=100 でトラフィックを旧リビジョンに 100% 戻す
D. Kubernetes Deployment の kubectl rollout undo を実行する

解答と解説

正解: C

解説:

C が正解: Cloud Run は Knative ベースで各デプロイがイミュータブルなリビジョン として残ります。update-traffic で旧リビジョンへトラフィックを 100% 戻すだけで瞬時にロールバック完了。再ビルドや再デプロイは不要です。
A: サービス自体を削除するとエンドポイント自体が消失し、ダウンタイムが発生します。
B: 再ビルドは数分かかり、「5 秒以内」を満たせません。
D: Cloud Run は Kubernetes Deployment ではないので kubectl rollout undo は使えません。

試験のひっかけポイント: Cloud Run の revision + traffic split モデルを理解しておくこと。ロールバックは「過去のリビジョンにトラフィックを戻す」だけ。試験では他のサービス（GKE, App Engine）と混同させる選択肢が出る。

関連リソース:

../02_学習資料/02_CICDパイプライン/02_応用.md §15.3

問題 8 （難易度: ★★）

シナリオ: GKE で稼働するアプリのデプロイ後、Pod は起動しているのにユーザーから「古いバージョンが返ってくる」とクレームがありました。kubectl rollout history で確認すると最新リビジョンになっていますが、kubectl describe deployment を見ても異常はありません。原因を切り分けたいです。

質問: 最初に確認すべき項目として最も適切なものはどれですか。

選択肢:

A. Cloud Build のビルドログを再確認する
B. kubectl describe pod で Pod のイメージタグと imagePullPolicy を確認する
C. Cloud Deploy の rollout を強制的に reject する
D. GKE クラスタのノードを全て再起動する

解答と解説

正解: B

解説:

B が正解: 「最新リビジョンなのに古い動作」の典型は、latest タグで Pod が古いキャッシュ済みイメージを使っている ケース。kubectl describe pod でイメージの digest と imagePullPolicy を見れば判別できます。本来は immutable tag（v1.2.3-abc1234）で digest を固定 すべきです。
A: ビルドが成功している前提なので原因切り分けの最初ではありません。
C: Rollout を reject しても問題解決にならず、本番影響を悪化させる恐れがあります。
D: ノード再起動は影響範囲が大きく、最初に試す手段ではありません。

試験のひっかけポイント: 「latest タグの危険性」と「immutable tag の必要性」は頻出。本番では必ず digest または semver+SHA を使うこと。imagePullPolicy: Always でも、latest タグはレジストリ上で書き換わる可能性があるため再現性を損なう。

関連リソース:

../02_学習資料/02_CICDパイプライン/02_応用.md §7.1, §15.4

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

シナリオ: データサイエンスチームは Vertex AI Pipelines（KFP v2 ベース）で構築した ML 学習パイプラインを定期実行しています。今後、Git にコミットがあるたびに新しい学習・評価・デプロイ を自動化したいと考えています。学習指標（accuracy など）が基準を下回ったらモデルデプロイは行われない仕組みも必要です。

質問: この MLOps パイプラインを最もシンプルかつ Google 推奨の構成で実現するアプローチはどれですか。

選択肢:

A. Cloud Composer で全工程を Airflow DAG として書き、Vertex AI を呼び出す
B. Cloud Build トリガーで gcloud ai pipelines run を起動し、KFP の評価コンポーネントでメトリクス判定後、合格時のみ Vertex AI Endpoints に traffic-split でデプロイする
C. Cloud Functions に学習スクリプトを書き、git push 時に直接 Vertex AI を叩く
D. オンプレ Jenkins からモデルをビルドし、Artifact Registry に push するだけにする

解答と解説

正解: B

解説:

B が正解: PCDE では Cloud Build トリガー → gcloud ai pipelines run が ML パイプライン CI/CD の標準パターン。KFP コンポーネントとして評価ステップを組み込めば、メトリクスでデプロイ可否を分岐できます。本番モデルは Vertex AI Endpoints に traffic-split（モデル版の canary）でデプロイ。
A: Cloud Composer は ETL/オーケストレーション向けで、ML 専用機能は Vertex AI Pipelines が公式推奨。
C: Cloud Functions は短時間処理向きで、長時間の ML 学習には不適。
D: 学習・評価・デプロイの自動化を満たせません。

試験のひっかけポイント: ML パイプラインでも Cloud Build = CI、Vertex AI Pipelines = ワークフロー実行、Vertex AI Endpoints = デプロイ先 という役割分担。モデルの canary は traffic-split で実現する点も覚える。

関連リソース:

../02_学習資料/02_CICDパイプライン/02_応用.md §14

問題 10 （難易度: ★★）

シナリオ: あるオンライン教育プラットフォームの本番デプロイ中、Cloud Deploy の prod target で rollout が PENDING_APPROVAL のまま 4 時間進みません。担当者は gcloud deploy rollouts approve を実行しても「permission denied」と表示されます。

質問: 最初に確認・修正すべき設定はどれですか。

選択肢:

A. 該当ユーザーに roles/clouddeploy.approver または roles/clouddeploy.operator 以上が付与されているか確認する
B. Cloud Build トリガーの状態を確認する
C. GKE クラスタのノードプールを増やす
D. Artifact Registry の roles/artifactregistry.writer を付与する

解答と解説

正解: A

解説:

A が正解: gcloud deploy rollouts approve を実行するには roles/clouddeploy.approver（承認のみ）または上位ロール（operator / admin）が必要。releaser や viewer では承認できません。
B: トリガーは CI 側の設定で、Cloud Deploy の承認権限とは関係ありません。
C: ノードプール容量は承認権限に関係しません。
D: Artifact Registry の権限は push/pull の話で、承認とは無関係です。

試験のひっかけポイント: Cloud Deploy のロール構造（admin > operator > releaser/approver > developer > viewer）を覚えておく。「承認のみ可能な最小権限」= roles/clouddeploy.approver。職務分掌の文脈で頻出。

関連リソース:

../02_学習資料/02_CICDパイプライン/01_基礎.md §4.6

問題 11 （難易度: ★★★・複数選択）

シナリオ: あなたは新規 GKE プロジェクトで Cloud Deploy の canary を本番初導入しようとしています。CTO は「ポリシーをミスったときに全てのリリースが止まる事態は避けたい」「本番投入前に、もし全ポリシーを有効化していたらどうなるかをログだけで確認したい」と言っています。

質問: これに対応する Binary Authorization の設定として 正しいもの 2 つ を選んでください。

選択肢:

A. ポリシーの enforcementMode: DRYRUN_AUDIT_LOG_ONLY を設定して導入する
B. 個別 Pod に alpha.image-policy.k8s.io/break-glass: "true" の annotation を付ける（breakglass）
C. すべての deployment に nodeSelector: spec.binAuthBypass=true を指定する
D. evaluationMode: ALWAYS_ALLOW を本番で恒常的に使用する

解答と解説

正解: A, B

解説:

A が正解: DRYRUN_AUDIT_LOG_ONLY は ポリシー違反でもデプロイは許可し、監査ログにのみ違反を記録 します。本番展開前の検証フェーズに最適。
B が正解: breakglass は緊急時に個別 Pod だけポリシーをバイパスする annotation。監査ログに Policy Denied 系の証跡は残ります。「全リリースが止まる事態を避ける」緊急回避策。
C: そのような nodeSelector や仕組みは存在しません。
D: ALWAYS_ALLOW を本番で常時使うと Binary Authorization の意味がなくなり、誤りです。

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

dry-run はポリシー検証フェーズ、breakglass は緊急バイパス。両者は目的が別。
本番では ENFORCED_BLOCK_AND_AUDIT_LOG が原則。ALWAYS_ALLOW を恒常使用するのは誤った選択肢として頻出。

関連リソース:

../02_学習資料/02_CICDパイプライン/02_応用.md §8.4, §8.5

問題 12 （難易度: ★★）

シナリオ: GitHub Actions から Google Cloud にデプロイしている既存パイプラインがあります。現在は SA キー（JSON）を GitHub Secrets に保管しています。セキュリティチームから「SA キーを廃止し、特定のリポジトリの main ブランチからのデプロイのみ許可する こと」を要求されました。

質問: この要件を満たす最も Google 推奨の構成はどれですか。

選択肢:

A. GitHub Actions の secrets に新たに SA キーを発行し、90 日ごとに手動ローテーション
B. Workload Identity Federation (WIF) を構成し、Workload Identity Pool の OIDC Provider に attribute-condition で assertion.repository == 'myorg/myapp' && assertion.ref == 'refs/heads/main' を設定する
C. GitHub Actions から Cloud Build のサービスエージェント鍵を直接利用する
D. デプロイ専用 SA に roles/owner を付与し、SA キーを HSM に保管する

解答と解説

正解: B

解説:

B が正解: WIF + attribute-condition がキーレス認証＋ブランチ制限の Google 推奨パターン。GitHub Actions は id-token: write の権限で OIDC トークンを取得し、google-github-actions/auth@v2 が WIF Pool 経由で短命トークンに交換します。
A: SA キーの保管・ローテーションは漏洩リスクを残す。GCP は SA キー使用を非推奨化しています。
C: サービスエージェント鍵はユーザーが直接使用するためのものではありません。
D: roles/owner は最小権限原則違反。鍵を HSM に置いても外部 CI からの利用方法に解決策がありません。

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

WIF = SA キー不要（最頻出）
attribute-condition で repository / branch / ref / actor などのクレームを使って厳格に制限できる
principalSet:// 形式で SA に roles/iam.workloadIdentityUser を付与する

関連リソース:

../02_学習資料/02_CICDパイプライン/02_応用.md §12

問題 13 （難易度: ★★）

シナリオ: あなたのチームは Cloud Run でアプリを運用しており、PostgreSQL の DB パスワード と、機能切り替え用の feature flag JSON（非機密）を管理する必要があります。両者の管理サービスを最も適切に分離したいです。

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

選択肢:

A. 両方とも Secret Manager で管理する
B. 両方とも Parameter Manager で管理する
C. DB パスワードは Secret Manager、feature flag JSON は Parameter Manager で管理する
D. DB パスワードは Cloud KMS で暗号化して GCS に置き、feature flag は環境変数に直接書く

解答と解説

正解: C

解説:

C が正解: Secret Manager は API キー・パスワード・秘密鍵などの 機密情報 に。Parameter Manager は feature flag・しきい値・構成 JSON などの 非機密の構成パラメータ に。両者の役割分担が公式設計です。
A: Secret Manager は機密ではない設定にはオーバースペック（アクセス課金・監査負荷）。
B: Parameter Manager に DB パスワードを置くと、誤って広めの IAM が付くリスクがあります（機密管理に最適化されていない）。
D: KMS + GCS の自前構築は車輪の再発明で、可用性・監査面で不利。

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

Secret Manager = 機密、Parameter Manager = 非機密の構成、Certificate Manager = TLS 証明書という棲み分けを覚える。
試験では「両方 Secret Manager」を選びがちな引っかけが多いが、Parameter Manager の存在を知っているかが問われる。

関連リソース:

../02_学習資料/02_CICDパイプライン/01_基礎.md §8.3

問題 14 （難易度: ★★）

シナリオ: Cloud Build で npm の プライベートレジストリトークン（ビルド時必須）と、ランタイムで使う DB パスワード（コンテナ起動時必須）を、それぞれ最も適切に注入したいです。

質問: 最適な注入方式の組み合わせはどれですか。

選択肢:

A. 両方とも cloudbuild.yaml の secretEnv で注入する
B. プライベートレジストリトークンは Cloud Build の secretEnv 経由（Build-time）、DB パスワードは Cloud Run の --set-secrets（Runtime） で注入する
C. 両方とも Cloud Run の --set-secrets で注入する
D. プライベートレジストリトークンは Docker イメージにハードコードし、DB パスワードは環境変数で渡す

解答と解説

正解: B

解説:

B が正解: ビルドにしか使わない secret（npm token、private maven token 等）= Build-time 注入、ランタイム動作で必要な secret（DB password、API key 等）= Runtime 注入 が定石。Runtime 注入は rotation 即時反映が可能で、再ビルド不要。
A: ランタイム secret を Build-time に注入するとイメージレイヤに残るリスクがあり、再ビルドが必要になります。
C: ビルド時に必要な secret を Runtime にしてもビルドが通りません。
D: ハードコードは最悪の選択。Git やイメージレイヤから漏洩します。

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

「Runtime がデフォルト推奨」「Build-time は必要最小限」が原則
ビルド時 secret は multi-stage build で最終イメージから除外することも合わせて出題される

関連リソース:

../02_学習資料/02_CICDパイプライン/02_応用.md §11

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

シナリオ: あなたの組織は dev / staging / prod の 3 プロジェクトを持ち、それぞれ別の Cloud Run サービスが動いています。本番には prod 用の Secret Manager シークレット（DB 接続情報）のみ にアクセスでき、dev 用シークレットには絶対にアクセスできないようにしたいです。

質問: 最小権限を満たす IAM 設計はどれですか。

選択肢:

A. 全環境共通の app-sa を作り、3 プロジェクト全てのシークレットに roles/secretmanager.secretAccessor を付与
B. 環境別 SA (cloudrun-prod@app-prod.iam, cloudrun-dev@app-dev.iam) を作成し、各 SA を自環境のシークレットだけに roles/secretmanager.secretAccessor で binding する
C. 全シークレットを 1 つのプロジェクトに集約し、すべての SA に roles/secretmanager.viewer を付与
D. シークレットは使わず、環境変数で直接プロジェクトに渡す

解答と解説

正解: B

解説:

B が正解: 環境別プロジェクト + 環境別 SA + 自環境のみアクセス可 がエンタープライズの標準パターン。BLAST radius（影響範囲）を環境内に閉じ込められます。
A: 全環境共通 SA は dev の漏洩が prod に波及するリスクがあり、最小権限違反。
C: viewer ではシークレット値は取得できず、アプリが動かない。また集約は分離原則に反する。
D: 環境変数の平文管理は秘密情報の取り扱いとして不適切。

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

「環境別 SA・環境別シークレット」が PCDE の鉄則
secretmanager.viewer はメタデータ閲覧のみ、secretmanager.secretAccessor が値取得用、を区別する

関連リソース:

../02_学習資料/02_CICDパイプライン/02_応用.md §13

問題 16 （難易度: ★★）

シナリオ: ある SaaS の Cloud Run サービスは TLS 1.3 で公開されており、複数カスタムドメインがあります。Google マネージドで証明書を自動発行・自動更新したいです。

質問: 最も適切な構成はどれですか。

選択肢:

A. Let's Encrypt の証明書を Secret Manager に手動アップロードし、cron で更新する
B. Certificate Manager で Google-managed 証明書を発行し、Certificate Map に複数ドメインを集約して LB に紐付ける
C. Compute Engine VM 上で nginx をフロントエンドに置いて TLS 終端する
D. Cloud Storage に証明書を置いて Cloud CDN から配布する

解答と解説

正解: B

解説:

B が正解: Certificate Manager は Google-managed 証明書を自動発行・自動更新し、Certificate Map で複数ドメインと複数証明書を一元管理して LB（Global / Regional External Application LB）に紐付けるための公式サービス。
A: 手動管理は更新漏れリスクと運用負担が大きい。
C: アンチパターン。マネージドサービスの利点を捨てている。
D: 証明書配布の話ではなく、TLS 終端の仕組みが必要。

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

「マネージド TLS 証明書 = Certificate Manager」を即答する
複数ドメイン対応は Certificate Map という概念
旧来の gcloud compute ssl-certificates create --managed=... も同等だが、Certificate Manager が新世代の公式推奨

関連リソース:

../02_学習資料/02_CICDパイプライン/01_基礎.md §9

問題 17 （難易度: ★★）

シナリオ: あなたは Cloud Build と Cloud Deploy を組み合わせたパイプラインを設計しています。「ビルド」「アーティファクト保存」「環境への段階デプロイ」「承認」「canary 制御」を含みます。どのフェーズをどのサービスが担当するかを正しく整理したいです。

質問: 最も正確な役割分担はどれですか。

選択肢:

A. Cloud Build がビルド・アーティファクト保存・全環境デプロイ・承認・canary を全て担う
B. Cloud Build: テスト/ビルド/Artifact Registry への push まで。Cloud Deploy: Release/Rollout/段階デプロイ/承認/canary を担当する
C. Cloud Deploy がビルドから本番反映まで全て担う
D. Cloud Build: 全てのデプロイ作業。Cloud Deploy: 承認のみ

解答と解説

正解: B

解説:

B が正解: PCDE の最頻出概念。CI = Cloud Build（ビルド・テスト・push）、CD = Cloud Deploy（Release/Rollout/Pipeline、canary/blue-green、承認、ロールバック）。両者は明確に役割が分離しています。
A: Cloud Build にも gcloud run deploy 等は書けますが、段階デプロイ・承認・canary は Cloud Deploy の機能です。
C: Cloud Deploy はビルド機能を持ちません。
D: 逆。承認・canary は Cloud Deploy の本領発揮ポイント。

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

Cloud Build がビルドして Artifact Registry へ push、その image を Cloud Deploy が release として展開 という流れ
Cloud Deploy の階層: Delivery Pipeline → Target → Release → Rollout → Phase

関連リソース:

../02_学習資料/02_CICDパイプライン/01_基礎.md §1.3, §4

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

シナリオ: あなたは規制業界向けにサプライチェーンセキュリティを SLSA Level 3 まで引き上げる責任があります。現在は Cloud Build + Artifact Registry の標準構成で provenance が自動生成されており、SLSA Level 2 相当です。次に Level 3 へ進むために必要な追加要件は何でしょうか。

質問: SLSA Level 3 達成のために最も重要な追加対応はどれですか。

選択肢:

A. 全コミットに 2 名以上のレビュアー必須を GitHub branch protection で有効化する
B. Cloud Build Private Pool（強化されたビルダー） を使い、hermetic build（外部ネットワーク遮断）を実現し、Build as code と非バイパス可能なビルドプロセスを担保する
C. ソースコードを reproducible build に書き換える
D. Cloud KMS で全 secret を CMEK 暗号化する

解答と解説

正解: B

解説:

B が正解: SLSA L3 の主要追加要件は Build service の強化、Build as code、ephemeral & isolated environment、ソース/ビルドの非改ざん です。Cloud Build Private Pool + hermetic build がこれらを満たす公式達成手段。
A: 2 名レビューは L4 の要件。
C: reproducible build は L4 で要求される（best effort）。
D: CMEK は SLSA Level 認定に直接寄与しません。

試験のひっかけポイント: SLSA Level の要件は混同しがち。

L1: 自動化＋provenance 提供
L2: 署名付き provenance、ホスト型ビルド
L3: ビルド強化（private pool / hermetic / isolated）
L4: 2 人レビュー、reproducible、parameterless

関連リソース:

../02_学習資料/02_CICDパイプライン/02_応用.md §9

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

シナリオ: あなたの組織は社内 OSS 利用ポリシーで「Docker Hub のレートリミットに振り回されたくない」「内部開発イメージと外部イメージを 同じ pull コマンド で取得したい」「外部イメージが削除されてもキャッシュで動き続けたい」と決めています。

質問: これを最も適切に満たす Artifact Registry の構成はどれですか。

選択肢:

A. Standard リポジトリだけを作り、Docker Hub から直接 pull する
B. Remote Repository（Docker Hub プロキシ）と Standard Repository（内部用）を作り、両者を Virtual Repository で集約して単一エンドポイントから配信する
C. 全イメージを Cloud Storage に保存し、CDN で配信する
D. GCR（旧 Container Registry）に戻して Docker Hub のミラーを使う

解答と解説

正解: B

解説:

B が正解: Remote Repository は外部レジストリ（Docker Hub、Maven Central、npm 等）のプロキシ・キャッシュ。Virtual Repository は複数リポジトリを単一エンドポイントに集約。これにより内部・外部を統一エンドポイントから取得でき、外部削除時もキャッシュで継続稼働できます。
A: Docker Hub への直接依存はレート制限・削除リスクが残ります。
C: GCS は Docker レジストリではないため不可。
D: GCR は deprecated（後継が Artifact Registry）。

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

Standard（自社用）、Remote（プロキシ）、Virtual（集約）の 3 種類を正確に区別する
Remote の利点: キャッシュ、レート制限回避、削除耐性、同一リージョン pull で高速

関連リソース:

../02_学習資料/02_CICDパイプライン/02_応用.md §7.4, §7.5

問題 20 （難易度: ★★）

シナリオ: あなたの組織で「誰が・いつ・どのリリースを本番に承認したか」を監査要件として常時記録する必要があります。直近 13 か月（400 日）の保持が求められています。

質問: これを満たす最も適切な Cloud Audit Logs 設定はどれですか。

選択肢:

A. Cloud Deploy の操作は Admin Activity ログ で自動記録され、デフォルトで 400 日保持される。承認イベント（rollout approve）はここに記録される
B. Data Access ログを有効化しないと記録されない（デフォルト無効・保持 30 日）
C. System Event ログでのみ記録される
D. アプリログ（Cloud Logging）で自前ロギングを実装する必要がある

解答と解説

正解: A

解説:

A が正解: Cloud Deploy の release/rollout 作成・承認・拒否などの 設定変更系操作は Admin Activity ログに自動記録、デフォルトで 400 日保持、課金は無料。
B: Data Access はデータの読み書きが対象（保持 30 日）。承認イベントは「設定変更」系で Admin Activity に入ります。
C: System Event は GCP 側の自動操作用。
D: 自前ログ実装は不要。Cloud Audit Logs で十分。

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

Admin Activity = 設定変更（デフォ有効・400 日・無料）
Data Access = データ読み書き（デフォ無効・30 日・有料）
System Event = システム自動操作
Policy Denied = ポリシー違反（Binary Auth など） この 4 種類の使い分けは頻出。

関連リソース:

../02_学習資料/02_CICDパイプライン/01_基礎.md §14

問題 21 （難易度: ★★・複数選択）

シナリオ: あなたは Cloud Build から AWS の S3 にもアーティファクトをコピーする必要があります。長期的には SA キーや AWS アクセスキーをコードや CI に保管したくありません。

質問: 最も適切なキーレスアプローチを 2 つ 選んでください。

選択肢:

A. AWS から GCP へは AWS IAM Role を WIF Provider に登録 して GCP リソースにアクセスする
B. GCP から AWS へは AWS IAM Identity Center の OIDC で GCP SA を信頼 させ AssumeRoleWithWebIdentity を使う
C. Cloud Build のサービスアカウントの JSON キーを Cloud Build の環境変数に貼り付ける
D. アクセスキーを Secret Manager に格納し、毎回ビルドで取得する

解答と解説

正解: A, B

解説:

A が正解: AWS → GCP は WIF（AWS Provider） で Lambda などの AWS ワークロードに GCP リソースアクセスを与える公式パターン。
B が正解: GCP → AWS は AWS 側の IAM Identity Center / OIDC で GCP SA の id token を信頼し、AssumeRoleWithWebIdentity で短命の STS クレデンシャルを取得するキーレスパターン。
C: SA キーを CI に貼ること自体が NG。
D: アクセスキーの保管は短期回避には有効ですが「キーレス」要件を満たしません。

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

WIF は GCP 側のキーレス、AWS 側で同等の仕組みは STS AssumeRoleWithWebIdentity
「キーレス」=「短命 token + IdP の連邦化」と理解する

関連リソース:

../02_学習資料/02_CICDパイプライン/02_応用.md §12

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

シナリオ: GKE Standard クラスタに Binary Authorization を有効化し、evaluationMode: REQUIRE_ATTESTATION を設定しました。あるリリース後、デプロイ済みのコンテナイメージが後から新たな CRITICAL CVE に該当することが判明しました。Binary Authorization は デプロイ後の継続検証 を要件として要求されています。

質問: 最も適切な機能はどれですか。

選択肢:

A. Binary Authorization の Continuous Validation (CV) を有効化し、Cloud Logging / Monitoring で違反を通知する
B. Cloud Deploy で全 release を cancel する
C. Pod に breakglass annotation を恒久的に付ける
D. Artifact Analysis を手動で毎日実行する

解答と解説

正解: A

解説:

A が正解: Continuous Validation (CV) は Binary Authorization の機能で、デプロイ後も継続的にポリシー違反を検出（attestation 期限切れ、新規 CVE、policy 変更）し、Cloud Logging / Monitoring で通知できます。
B: 既デプロイ済みコンテナの停止は別議論で、cancel は進行中の rollout を止めるだけ。
C: breakglass は緊急バイパスで、継続検証の代替にはなりません。
D: 手動運用は要件「継続検証」を満たしません。CV が公式機能です。

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

Binary Authorization は「デプロイ時の 入口検証」だけでなく「実行中の 継続検証（CV）」も提供
CV は policy 変更・attestation 期限切れ・新規 CVE など、デプロイ後の状況変化を検知

関連リソース:

../02_学習資料/02_CICDパイプライン/02_応用.md §8.6

問題 23 （難易度: ★★）

シナリオ: あなたは Cloud Deploy で canary デプロイ中、canary-25 の verify ステップが Cloud Monitoring API を叩いて「エラー率 5% 超なら失敗」と判定するロジックを書きたいです。失敗時は次の phase に進ませず、即時に Cloud Logging へ通知したいです。

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

選択肢:

A. Skaffold の verify セクションでコンテナ（curl + 判定スクリプト）を定義し、非ゼロ exit code で Rollout を FAILED にする
B. Pod の livenessProbe を厳しくして自動再起動させる
C. Cloud Build の手動承認を canary 後に挿入する
D. Cloud Run の traffic split で 0% に手動変更する

解答と解説

正解: A

解説:

A が正解: Cloud Deploy の verify ジョブは Skaffold の verify セクション で定義し、コンテナの exit code が非ゼロなら Rollout 全体が FAILED になります。次 phase に進まず、Cloud Logging には自動で記録されます。
B: livenessProbe は Pod 自己回復の仕組みで、デプロイ判定とは別。
C: Cloud Build 承認は時間が空いてしまい、自動判定にならない。
D: 手動操作は自動化要件に反する。

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

verify ジョブ は Cloud Deploy 公式の「canary 自動判定」の仕組み
失敗判定は exit code 非ゼロ
predeploy/postdeploy hooks（Cloud Build action）と verify は別の概念

関連リソース:

../02_学習資料/02_CICDパイプライン/02_応用.md §2.4

問題 24 （難易度: ★★・複数選択）

シナリオ: あなたの組織は Software Delivery Shield を導入してサプライチェーンセキュリティを統合管理したいと考えています。SDS の構成要素として 公式に位置付けられているもの を 3 つ 選んでください。

選択肢:

A. Cloud Workstations
B. Artifact Analysis（脆弱性スキャン + SBOM）
C. Binary Authorization + Continuous Validation
D. Cloud Composer
E. Anthos Service Mesh

解答と解説

正解: A, B, C

解説:

A が正解: Cloud Workstations は Develop フェーズのマネージド開発環境として SDS に含まれます。
B が正解: Artifact Analysis は Scan フェーズ。CVE 検出と SBOM 生成を担う SDS の中核。
C が正解: Binary Authorization と Continuous Validation はデプロイ時／実行時の署名・継続検証を担当する SDS 中核。
D: Cloud Composer はオーケストレーションで SDS の構成要素ではない。
E: Service Mesh は通信セキュリティで SDS の構成要素には含まれない。

試験のひっかけポイント: SDS の公式構成は Cloud Workstations / Cloud Build / Artifact Registry / Artifact Analysis / Binary Authorization (+ CV) / Assured OSS / GKE Security Posture。Service Mesh や Composer はサプライチェーンと隣接領域だが SDS そのものではない。

関連リソース:

../02_学習資料/02_CICDパイプライン/02_応用.md §10

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

シナリオ: あなたは多リージョン展開する SaaS の Cloud Deploy パイプラインを設計しています。prod だけ に以下のセキュリティポリシーを適用したいです：(1) main ブランチからのみデプロイ可能、(2) Binary Authorization で 複数 attestor（QA、セキュリティ）の attestation 必須、(3) CVE は HIGH 以下のみ許容、(4) ロールバック用に 直前 release への即時切戻し ができること。

質問: これらを満たす最も適切な構成はどれですか。

選択肢:

A. dev / staging / prod を 1 プロジェクトに置き、Cloud Build SA だけで全てを行う
B. 環境別プロジェクト＋prod target の requireApproval: true＋Binary Authorization policy で prod クラスタに対し複数 attestor を要求＋WIF の attribute-condition で ref == 'refs/heads/main' 限定＋Cloud Deploy の gcloud deploy targets rollback でロールバック
C. prod クラスタの IAM を roles/owner で全員に付与し、運用は人手判断に任せる
D. ロールバックは GitHub revert + 全部最初からビルドし直す方式に統一する

解答と解説

正解: B

解説:

B が正解: PCDE の総合問題。(1) WIF の attribute-condition で ブランチ制限、(2) Binary Authorization の clusterAdmissionRules で prod クラスタに 複数 attestor を要求、(3) CVE 許容範囲は Artifact Analysis + attestor の検証ロジック、(4) gcloud deploy targets rollback で 前 release を再デプロイ という構成が公式パターン。環境別プロジェクトで blast radius を限定します。
A: 1 プロジェクト集約・単一 SA は最小権限・職務分掌に反する。
C: roles/owner を全員に付与は重大なセキュリティ違反。
D: 「直前 release への即時切戻し」要件に対し再ビルドは遅く、要件未達。

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

PCDE 試験では WIF + Binary Authorization + Cloud Deploy rollback + 環境別プロジェクト の 4 点セットが「prod の最強構成」として頻出
gcloud deploy targets rollback は前 release を新 rollout として再展開する公式コマンド

関連リソース:

../02_学習資料/02_CICDパイプライン/02_応用.md §13, §15.2, §8.3

正答率早見表

採点後、以下に記入してください。

問題	難易度	カテゴリ
1	★★	2.1 トリガー（Pub/Sub）
2	★★	2.1 マルチターゲット
3	★★	2.1 承認/IAM
4	★★★	2.1 Private Pool
5	★	2.1 cloudbuild.yaml 構文
6	★★	2.2 canary 戦略
7	★★	2.2 ロールバック（Cloud Run）
8	★★	2.2 トラブルシュート
9	★★★	2.2 ML パイプライン
10	★★	2.2 承認エラー対処
11	★★★	2.4 Binary Auth（dry-run/breakglass）
12	★★	2.3 WIF + GitHub
13	★★	2.3 Secret vs Parameter Manager
14	★★	2.3 Build vs Runtime secret
15	★★★	2.3 環境別 IAM（Secret）
16	★★	2.3 Certificate Manager
17	★★	2.1 Cloud Build vs Cloud Deploy 役割分担
18	★★★	2.4 SLSA Level 3
19	★★★	2.1 Remote/Virtual Repository
20	★★	2.2 Cloud Audit Logs
21	★★	2.3 WIF AWS/GCP 双方向
22	★★★	2.4 Continuous Validation
23	★★	2.2 canary verify ジョブ
24	★★	2.4 SDS 構成要素
25	★★★	2.4 prod 総合セキュリティ

合計正答数: ___ / 25 （目標: 23/25 = 92%）

弱点別の復習リンク

弱点カテゴリ	該当問題	復習リソース
Cloud Build 構文・トリガー	1, 5, 17	`../02_学習資料/02_CICDパイプライン/01_基礎.md` §2
Private Pool / ネットワーク	4	`../02_学習資料/02_CICDパイプライン/01_基礎.md` §2.8
Cloud Deploy（canary / multiTarget / 承認）	2, 3, 6, 10, 17, 23	`../02_学習資料/02_CICDパイプライン/02_応用.md` §2, §4, §5
デプロイ戦略選定 / ロールバック	6, 7, 8	`../02_学習資料/02_CICDパイプライン/01_基礎.md` §5, `02_応用.md` §15
Artifact Registry（Remote/Virtual/immutable tag）	8, 19	`../02_学習資料/02_CICDパイプライン/02_応用.md` §7
Secret/Parameter/Certificate Manager	13, 14, 16	`../02_学習資料/02_CICDパイプライン/01_基礎.md` §7, §8, §9
Workload Identity Federation	12, 15, 21, 25	`../02_学習資料/02_CICDパイプライン/02_応用.md` §12
Binary Authorization	11, 22, 25	`../02_学習資料/02_CICDパイプライン/02_応用.md` §8
SLSA Framework	18	`../02_学習資料/02_CICDパイプライン/02_応用.md` §9
Software Delivery Shield	24	`../02_学習資料/02_CICDパイプライン/02_応用.md` §10
環境別 IAM / 職務分掌	3, 10, 15, 25	`../02_学習資料/02_CICDパイプライン/02_応用.md` §13
監査ログ（Audit Logs）	20	`../02_学習資料/02_CICDパイプライン/01_基礎.md` §14
ML パイプライン（Vertex AI）	9	`../02_学習資料/02_CICDパイプライン/02_応用.md` §14

次のセクションへ

PCDE 試験は 4 セクション構成です。Section 2 が終わったら次へ：

Section 3: SRE プラクティス（SLI/SLO/SLA、エラーバジェット、障害対応、ポストモーテム）— ../03_問題集/section3_問題集.md（未作成の場合は学習資料 ../02_学習資料/03_SREプラクティス/ を参照）
Section 4: サービスの可観測性（Cloud Monitoring / Logging / Trace / Profiler / Error Reporting）— ../03_問題集/section4_問題集.md

学習のコツ: Section 2 は試験本番の 25% を占めるため、ここで 90% 以上の正答率を取れていれば合格にぐっと近づきます。Binary Authorization・WIF・SLSA は他セクションにも波及するので、何度も復習してください。