問題集 セクション3：デプロイ用クラウドネイティブアプリケーションの構成
セクション3「デプロイ」を、本番同様のシナリオ形式で固める問題集です。全 10問、目標 80%以上。
Q1 🔧 単一選択
Cloud Run の新リビジョンを段階的にロールアウトしたい。まずは 10% だけ新版に流し、問題なければ拡大、異常があれば即ロールバック。最適なコマンドは？
- A.
gcloud run deploy --traffic=10 - B.
gcloud builds submit && gcloud run rollout - C.
gcloud run services update-traffic SERVICE --to-revisions=LATEST=10 - D.
kubectl rollout
▶ 正解と解説
正解：C
Cloud Run の traffic splitting は update-traffic で % 指定。LATEST=10 で最新リビジョンに 10% を配信、残り 90% は前リビジョン。ロールバックは LATEST=0。
- ❌ A：
gcloud run deployに--trafficフラグは存在しない（--no-trafficはある）。 - ❌ B：
gcloud run rolloutというコマンドは存在しない。 - ❌ D：kubectl は GKE 向け。Cloud Run には適用できない。
📖 関連：02_学習資料/03_デプロイ/02_応用.md § Traffic Splitting
Q2 📘 単一選択
毎晩 1時に動かしたいバッチ処理がある。最大処理時間は 2時間、HTTP リクエストは受けない。最適なサービスの組み合わせは？
- A. Cloud Run Service + Cloud Scheduler の HTTP リクエスト
- B. Cloud Run Jobs + Cloud Scheduler
- C. GKE CronJob
- D. Compute Engine + cron
▶ 正解と解説
正解：B
Cloud Run Jobs は HTTP 不要のバッチ用。タイムアウト最大 24時間、並列実行可。Cloud Scheduler で定時起動が定石。
- ❌ A：Cloud Run Service の HTTP は最大 60分のタイムアウト。2時間は不可。
- ❌ C：GKE CronJob は可能だが、Kubernetes 運用が必要。サーバーレスの方が運用負荷が低い。
- ❌ D：自前 cron は運用負荷が高い。
📖 関連：02_学習資料/03_デプロイ/01_基礎.md § Cloud Run Jobs
Q3 🔧 単一選択
GKE Pod から Cloud Storage を読みたい。サービスアカウントキー JSON を Secret として配布したくない。最適な構成は？
- A. すべての Pod に
roles/storage.adminを組織レベルで付与 - B. Workload Identity を構成し、K8s ServiceAccount を GCP SA にひも付ける
- C. Pod の環境変数に SA Key の base64 を埋め込む
- D. GCS バケットを公開する
▶ 正解と解説
正解：B
Workload Identity は GKE Pod から GCP API を呼ぶ標準パターン。K8s SA に GCP SA を annotation で紐付け、iam.workloadIdentityUser ロールで借用を許可。Pod に SA Key を配布する必要が一切ない。
- ❌ A：「すべての Pod に Owner 相当」は最小権限に大反する。
- ❌ C：base64 は単なるエンコードで暗号化ではない。漏洩リスクが残る。
- ❌ D：公開は最終手段で、推奨されない。
📖 関連：02_学習資料/03_デプロイ/02_応用.md § Workload Identity
Q4 📘 単一選択
GCS にファイルがアップロードされたら Cloud Run の処理を起動したい。最もシンプルな構成は？
- A. Cloud Scheduler で 1分おきに GCS をポーリング
- B. Eventarc トリガを Cloud Run に作成（GCS の Object Finalized イベント）
- C. Cloud Functions で Pub/Sub に publish → Cloud Run で受信
- D. GKE で nginx を立てて Object Notifications を受ける
▶ 正解と解説
正解：B
Eventarc は GCS イベント（google.cloud.storage.object.v1.finalized）を直接受けて Cloud Run を起動できる。Pub/Sub を介する必要なく、最もシンプル。
- ❌ A：ポーリングは遅延・コストの両面で非効率。
- ❌ C：中間に Cloud Functions を挟む必要なし。Eventarc 直結が簡単。
- ❌ D：複雑かつ自前運用。
📖 関連：02_学習資料/03_デプロイ/01_基礎.md § Eventarc から Cloud Run を起動
Q5 🎯 単一選択
Cloud Run Service A から Service B を呼び出す。B は認証必須で公開したくない。最適な構成は？
- A. B も
--allow-unauthenticatedで公開 - B. B に API キーを設定し、A の環境変数に保存
- C. B を
--no-allow-unauthenticatedにし、A の SA にroles/run.invokerを付与。A は ID Token を取得してAuthorization: Bearerで送信 - D. B を VPC 内に隔離し、A から PSC で接続
▶ 正解と解説
正解：C
Cloud Run サービス間認証の標準パターン。B 側を IAM で保護し、A の SA に invoker を付与。A は google.oauth2.id_token.fetch_id_token(audience=B_URL) で audience-bound ID Token を取得し、Bearer で送る。
- ❌ A：公開は要件に反する。
- ❌ B：API キーはローテーションと管理が煩雑。サービスアカウント + IAM の方が安全。
- ❌ D：PSC は VPC ネットワーク内の Private 接続。Cloud Run 標準は IAM 認証で十分。
📖 関連：02_学習資料/01_設計/02_応用.md § Service-to-service 認証パターン
Q6 🔧 単一選択
Pod が「準備中」状態でも Service にトラフィックが流れて 5xx エラーが多発。最初に確認すべきは？
- A. liveness probe の設定
- B. readiness probe の設定
- C. startup probe の設定
- D. HPA の minReplicas
▶ 正解と解説
正解：B
readiness probe が成功するまで Service エンドポイントに登録されない。未設定または不適切な設定だと、初期化中の Pod にトラフィックが流れて 5xx になる。
- ❌ A：liveness は「殺して再起動」。準備中の判断には使わない。
- ❌ C：startup は重い初期化アプリ用で、readiness と併用される。第一に確認すべきは readiness。
- ❌ D：HPA はスケール数。準備中状態の判定には関係ない。
📖 関連：02_学習資料/03_デプロイ/01_基礎.md § Kubernetes ヘルスチェック（3種）
Q7 🎯 単一選択
Pub/Sub のメッセージが溜まったら GKE Pod を自動で増やしたい。HPA の設定で正しいメトリックタイプは？
- A. Resource (CPU)
- B. Resource (Memory)
- C. Pods (Custom)
- D. External（pubsub.googleapis.com|subscription|num_undelivered_messages）
▶ 正解と解説
正解：D
Pub/Sub の 未配信メッセージ数は GCP の External Metric として取得し、HPA の type: External で参照。averageValue: 100 などで「Pod 1 個あたり backlog 100」を目安にスケール。
- ❌ A, B：CPU / メモリは Pod 自体の負荷。Pub/Sub backlog は別。
- ❌ C：Pods は Pod 内のカスタムメトリック。Pub/Sub のような外部値には External を使う。
📖 関連：02_学習資料/03_デプロイ/02_応用.md § HPA の Custom Metrics（実用例）
Q8 🔧 単一選択
GKE Standard と Autopilot の違いについて、Autopilot を選ぶ理由として正しいのは？
- A. GPU が必要
- B. ノード管理が不要、Pod のリソース要求のみで課金される
- C. 特殊な DaemonSet を多数動かす
- D. Spot VM を自由に組み合わせる
▶ 正解と解説
正解：B
Autopilot は Google がノードを管理し、Pod の requests に対して課金。ノードプール管理・OS パッチ・セキュリティ強化を自動化。新規ワークロードの第1選択。
- ❌ A, C, D：GPU・特殊 DaemonSet・Spot 自由活用は Standard が向く。
📖 関連：02_学習資料/03_デプロイ/01_基礎.md § GKE Autopilot vs Standard
Q9 📘 複数選択（2つ）
GKE のノードアップグレード時に Pod が同時多数落ちて可用性が損なわれないようにしたい。実装すべきものを 2つ選べ。
- A. Pod Disruption Budget (PDB) を設定し
minAvailableを指定 - B. すべての Pod を
priorityClassName: system-criticalに設定 - C. Deployment の replicas を増やし、
maxUnavailable: 1の RollingUpdate - D. Pod を 1 個だけにする
▶ 正解と解説
正解：A, C
A：PDB は「最低 N 個は稼働させる」を K8s に約束させる仕組み。ノードアップグレード時、PDB を満たすように Pod を順次 evict する。
C：Deployment の
RollingUpdateでmaxUnavailableを絞れば、同時 termination が制限される。❌ B：priorityClass はスケジューリング優先度。可用性制約とは別。
❌ D：Pod 1個は SPOF。多重化がそもそも必要。
📖 関連：02_学習資料/03_デプロイ/02_応用.md § Pod Disruption Budget (PDB)
Q10 🎯 複数選択（2つ）
Cloud Run のコールドスタートを最小化したい。実施すべきものを 2つ選べ。
- A.
--min-instances=1+を設定 - B. ベースイメージを大きいフルディストロにする
- C. 軽量ベースイメージ（distroless / alpine）を使い、起動時の重い初期化を遅延化
- D.
--concurrency=1に設定
▶ 正解と解説
正解：A, C
A：
--min-instances=1で最低 1 インスタンスを常時 warm に保つ。コールドスタートを実質ゼロに。C：軽量ベースイメージ（distroless / alpine / slim）と起動時の遅延ロードで、コンテナ起動時間そのものを短縮。
❌ B：大きいイメージは起動が遅くなる。逆効果。
❌ D：concurrency=1 は同時 1 リクエストしか処理しない設定。インスタンスが大量に増え、コールドスタートが頻発する。
📖 関連：02_学習資料/03_デプロイ/02_応用.md § コールドスタート対策
自己採点
| 得点 | 評価 | 次のアクション |
|---|---|---|
| 9-10 | 🎯 合格圏 | 次セクションへ |
| 7-8 | 🔧 もう一押し | 誤答セクションを 03_要点と暗記.md で復習 |
| 5-6 | 📘 基礎再学習 | 01_基礎.md を読み直し |
| 0-4 | 📚 シラバスから | シラバス詳細の該当範囲を再学習 |