正解：C

Artifact Registry は GCP のコンテナ + 言語パッケージ用マネージドリポジトリ。Container Registry は非推奨で、新規プロジェクトでは Artifact Registry を使う。

• ❌ A：非推奨。新規利用は禁忌。
• ❌ B：プライベートとは限らず、Cloud Build や IAM 統合がない。
• ❌ D：GCS は BLOB ストレージ。イメージレジストリの機能（タグ管理、脆弱性スキャン）がない。

📖 関連：02_学習資料/02_構築とテスト/01_基礎.md § Artifact Registry

正解：B

Cloud Build は Secret Manager 連携が標準。availableSecrets.secretManager で Secret バージョンを宣言し、step に secretEnv: ['VAR'] を指定。Build ログにも平文出ない。

• ❌ A：可能だが冗長。標準機能を使うべき。
• ❌ C：trigger の環境変数は substitution であり、シークレットには向かない。ログに平文が出る。
• ❌ D：Dockerfile の ARG はビルドコンテキストに残る。漏洩源。

📖 関連：02_学習資料/02_構築とテスト/02_応用.md § secrets の扱い

正解：B

gcloud run deploy --source . は Buildpacks を内部で利用し、Dockerfile 不要でソースコードをコンテナ化 → Artifact Registry に push → Cloud Run にデプロイを一括実行。

• ❌ A：Dockerfile が必要。
• ❌ C：GKE 向け。
• ❌ D：可能だが冗長。--source . でこの手順は内部的に1コマンドに統合される。

📖 関連：02_学習資料/03_デプロイ/01_基礎.md § ソースコードからのデプロイ

正解：B

Binary Authorization は GKE / Cloud Run のデプロイ時に attestation 署名の検証ポリシーを強制する。Cloud Build で provenance（SLSA L3）を生成・署名し、デプロイ前に Binary Authorization が検証することで、改ざんイメージをブロック。

• ❌ A：Cloud Armor は WAF。デプロイ制御ではない。
• ❌ C：VPC SC はネットワーク境界。イメージの真贋検証はしない。
• ❌ D：IAM はアクセス制御。署名検証の機能はない。

📖 関連：02_学習資料/02_構築とテスト/02_応用.md § Binary Authorization と Artifact Analysis の統合

正解：B

Pub/Sub エミュレータを起動し、環境変数 PUBSUB_EMULATOR_HOST=localhost:8085 を設定すれば、Cloud Client Libraries が自動でエミュレータに接続。コード変更不要・無料。

• ❌ A：本物の Pub/Sub に課金される。
• ❌ C：Pub/Sub Lite は別サービス（よりコスト最適化されたバージョン）。エミュレートではない。
• ❌ D：本物の Pub/Sub に課金される。

📖 関連：02_学習資料/02_構築とテスト/01_基礎.md § gcloud CLI のエミュレータ

正解：B

Cloud Workstations は管理者が **Configuration（OS イメージ、リソース、拡張機能）**をテンプレ化し、開発者はそれを起動するだけで使える。永続ボリューム、企業ポリシー強制、Gemini Cloud Assist 統合。

• ❌ A：Cloud Shell は個人の軽量シェル。テンプレ化・永続化機能は限定的。
• ❌ C：CE + カスタムイメージは自前運用が重い。
• ❌ D：GKE + Dev Container も自前運用が重い。

📖 関連：02_学習資料/02_構築とテスト/01_基礎.md § Cloud Workstations

正解：B

ビルド短縮の3本柱：①マシンタイプ強化（E2_HIGHCPU_32 / N1_HIGHCPU_32）、②並列ステップ（waitFor: ['-']）、③マルチステージ Dockerfile で最終イメージを小さく。さらに kaniko cache や GCS ライブラリキャッシュも有効。

• ❌ A：順次実行は遅い。並列化が必須。
• ❌ C：ビルドコンテキスト肥大化は逆効果。
• ❌ D：品質を犠牲にしてはいけない。

📖 関連：02_学習資料/02_構築とテスト/02_応用.md § multi-step ビルドの並列化

正解：C

Cloud Build の Pull Request トリガーは、PR が作成・更新されたタイミングで自動実行し、結果（成功/失敗）を PR の Status Checks に反映する。標準的な PR レビュー連携。

• ❌ A：Schedule は定時実行。PR 連動ではない。
• ❌ B：Manual は手動。自動化要件を満たさない。
• ❌ D：PR とブランチ Push は別概念。PR ベースで動かしたいなら PR トリガーを使う。

📖 関連：02_学習資料/02_構築とテスト/01_基礎.md § Cloud Build の trigger 設計

正解：A, D

• A：Gemini Cloud Assist は GCP 全体に統合された AI アシスタント。コード生成・説明、ログクエリ生成、可観測性支援など。

• D：MCP サーバーは、AI モデルが外部リソース（GitHub、DB、API）に接続するための標準プロトコル。AI コーディングアシスタントとセットで出題される可能性。

• ❌ B：Cloud Trace は分散トレースサービス。AI 駆動開発ツールではない。

• ❌ C：Container Registry は非推奨のレジストリ。

📖 関連：02_学習資料/02_構築とテスト/01_基礎.md § AI コーディングアシスタント / MCP サーバー

正解：A, C

• A：Cloud Build は SLSA L3 相当の provenance を自動生成。Binary Authorization のポリシーで attestor 署名を必須にすることで、改ざんを防ぐ。

• C：Artifact Analysis はイメージの脆弱性スキャンを実施。Cloud Build のステップで深刻度を判定し、HIGH/CRITICAL が含まれていればパイプラインを失敗させる（デプロイブロック）。

• ❌ B：:latest タグは「何のバージョンか不明」「ロールバック不可」。サプライチェーン強化に逆行。

• ❌ D：認証なし公開はセキュリティの観点で逆方向。

📖 関連：02_学習資料/02_構築とテスト/02_応用.md § サプライチェーンセキュリティ