【PCD】WEB問題集:アプリのデプロイ編

正解：A

正解の根拠

Cloud Build GitHub App を導入することで push や PR イベントを Webhook 経由でリアルタイムに受信でき、ビルドの状態を GitHub の Checks API に直接書き戻せます。トリガー定義は cloudbuild.yaml としてリポジトリ内で管理でき、IaC との親和性も確保できます。

不正解の理由

• B: CSR ミラーは数分単位の遅延があり、PR のチェック API 連携も提供されないため要件を満たしません。
• C: GitHub Actions からの呼び出しは二重 CI となり管理が複雑化し、Cloud Build 側のトリガー管理も失われます。
• D: Scheduler によるポーリングは push 即時性が無く、無駄なビルドや遅延が頻発します。

参考：Connect to a GitHub host - Cloud Build

正解：B, C

正解の根拠

Binary Authorization は GKE Pod 起動時にイメージへの attestation 検証を行い、policy で require-attestation を有効化することで未署名イメージを拒否できます。Cloud Build と連携した attestor を登録すると、ビルド成功時に attestation が自動付与され、要件である「Cloud Build 経由ビルド+特定 attestor 署名」の双方を満たせます。

不正解の理由

• A: Cloud DNS の内部解決はネットワーク経路設定で、イメージ署名検証の機能とは無関係です。
• D: VPC SC はデータ境界制御で、コンテナ署名やビルド経路の検証手段ではありません。

参考：Create attestors - Binary Authorization

正解：B

正解の根拠

Cloud Deploy は Delivery Pipeline 内で canary strategy を宣言でき、percentages の配列でフェーズを定義し、各フェーズに approval gate と自動ロールバックを組み込めます。Cloud Run target との統合により traffic split は Cloud Deploy 側が制御し、宣言的に履歴と昇格状態を管理できます。

strategy:
  canary:
    runtimeConfig:
      cloudRun:
        automaticTrafficControl: true
    canaryDeployment:
      percentages: [5, 20]

不正解の理由

• A: スクリプト方式は承認ゲートやロールバックを自作する必要があり、監査要件を満たすには工数が膨らみます。
• C: Cloud Functions に traffic split を委ねると状態管理が分散し、リリース履歴の追跡が困難になります。
• D: Terraform 再 apply は drift 検出のたびに traffic を上書きしてしまい、段階リリースの段階状態を保持できません。

参考：Canary deployment - Cloud Deploy

正解：C

正解の根拠

Google Cloud buildpacks は Dockerfile 不要でソースから OCI イメージを生成し、ベースイメージ rebase により JRE などのランタイム脆弱性パッチを Google が継続提供します。pack CLI または gcloud builds submit --pack で利用でき、Cloud Build に統合できます。

不正解の理由

• A: Kaniko は Dockerfile を前提とし、ベースイメージ更新の自動化は提供されません。
• B: docker pull と save の組合せはビルドではなくイメージ再パッケージで、要件と無関係です。
• D: Jib は Java 向けに有用ですが、ベースイメージは利用者管理で Google が脆弱性対応を保証しません。

参考：Buildpacks overview - Google Cloud

正解：B, D

正解の根拠

Anthos Service Mesh の VirtualService には mirror および mirrorPercentage が定義でき、本番トラフィックを複製して shadow 先サービスへ流せます。複製先の応答は呼び出し元に返らないため、ユーザー応答時間に影響を与えずに新バージョンを検証できます。mirrorPercentage を 100 に設定すれば全リクエストを複製し、忠実な再現が可能です。

spec:
  http:
  - route:
    - destination: { host: api, subset: v1 }
    mirror: { host: api, subset: v2 }
    mirrorPercentage: { value: 100 }

不正解の理由

• A: 50:50 split はユーザー応答経路に v2 を入れる構成で、shadow の定義から外れます。
• C: replicas 増加はキャパシティ調整であり、新バージョン検証に寄与しません。

参考：Traffic mirroring - Anthos Service Mesh