問題集 セクション1：高スケーラブル・セキュア・信頼性の高いクラウドネイティブアプリケーションの設計
Google Cloud Professional Cloud Developer（2026年4月改訂・042426版準拠）のセクション1「設計」を、本番同様のシナリオ形式で固める問題集です。
使い方
- 全 10問。本番に近いシナリオ形式（企業の状況・要件から最適なサービス/構成を選ぶ）が中心です。
- 形式：単一選択（4択）8問 ＋ 複数選択（2つ選べ）2問。
- 各問に難易度アイコン（📘基礎 / 🔧応用 / 🎯発展）を付けています。
- まず自力で解答 →
▶ 正解と解説を開いて答え合わせ。 - 解説の「なぜ他の選択肢がダメか（❌）」まで必ず読むこと。
- 目標正答率：80%（10問中8問）以上。
Q1 📘 単一選択
新規開発するモバイル向け REST API のバックエンドを構築する。要件は次のとおり：
- ステートレス
- トラフィックは時間帯で激しく変動（深夜は 0、ピーク時は数千 RPS）
- チームに Kubernetes 経験者はいない
最もコスト効率が高く運用負荷が低いのは？
- A. Compute Engine の MIG（Managed Instance Group）
- B. GKE Standard with Cluster Autoscaler
- C. Cloud Run
- D. App Engine Standard
▶ 正解と解説
正解：C
ステートレス・トラフィック変動・運用負荷最小は Cloud Run の典型ユースケース。0 まで自動スケール、リクエスト課金、HTTPS 自動付与。
- ❌ A：MIG は VM ベースで常時起動コストが高く、スケーリングも Cloud Run より遅い。
- ❌ B：GKE は運用負荷高、Kubernetes 経験者が必要。
- ❌ D：App Engine Standard は新規プロジェクトでは Cloud Run / Cloud Run Functions が推奨される。
📖 関連：02_学習資料/01_設計/01_基礎.md § コンピュート 3 種の役割
Q2 🔧 単一選択
GitHub Actions から Cloud Run に毎日デプロイしている現行構成では、サービスアカウントキー JSON を GitHub Secrets に保存している。セキュリティチームから「鍵漏洩リスクを排除せよ」と指摘された。最適な改善策は？
- A. 鍵を定期的にローテーションする
- B. Workload Identity Federation を構成し、サービスアカウントキーを削除する
- C. GitHub Secrets を暗号化する
- D. プロジェクトの IAM で GitHub Actions SA に Owner を付与する
▶ 正解と解説
正解：B
Workload Identity Federation (WIF) は、GitHub Actions の OIDC トークンを GCP 側で検証し、サービスアカウントを借用させる仕組み。サービスアカウントキー JSON を発行・配布しなくて済むため、漏洩リスクを根本から排除できる。
- ❌ A：ローテーションしてもリスクは残る（漏洩時の被害を縮小するだけ）。WIF なら鍵自体が存在しない。
- ❌ C：GitHub Secrets は元々暗号化されている。問題は「鍵が存在すること」自体。
- ❌ D：Owner は最小権限に反する重大な権限過多。
📖 関連：02_学習資料/01_設計/02_応用.md § WIF・サービスアカウント設計
Q3 🔧 単一選択
新しい金融サービスのトランザクション DB を選定中。要件は次のとおり：
- グローバル分散（US/EU/Asia）
- 強整合性のトランザクション
- 高可用性（SLA 99.999%）
- PostgreSQL 互換である必要はない
最適な DB は？
- A. AlloyDB
- B. Cloud SQL Multi-region
- C. Spanner
- D. BigQuery
▶ 正解と解説
正解：C
Spanner は GCP のグローバル分散 SQL DB。External Consistency（強整合）と 99.999% SLA（マルチリージョン構成）を提供。グローバル分散 + 強整合は Spanner 一択。
- ❌ A：AlloyDB は PostgreSQL 互換で高性能だが、リージョナル。グローバル分散には対応しない。
- ❌ B：Cloud SQL もリージョナル。Cross-region replica は読み取り用で、強整合ではない。
- ❌ D：BigQuery は OLAP（分析）。トランザクションには向かない。
📖 関連：02_学習資料/01_設計/01_基礎.md § ストレージ意思決定ツリー
Q4 🎯 単一選択
既存の HTTP アプリ（Cloud Run 上）に、コード変更なしで Google アカウント認証を追加したい。社内ユーザーのみアクセス可、組織外は拒否したい。最適な構成は？
- A. アプリ内に OAuth2 認可コードフローを実装
- B. HTTP(S) Load Balancing + Identity-Aware Proxy (IAP) を構成
- C. Apigee の OAuth ポリシーで保護
- D. Cloud Armor の WAF ルールで Google ドメインのみ許可
▶ 正解と解説
正解：B
IAP は HTTP(S) LB の前段で Google アカウント認証を強制し、IAM で「誰がアプリにアクセスできるか」を制御する。アプリのコード変更不要で社内ユーザー限定が実現できる。
- ❌ A：「コード変更なし」の要件に反する。
- ❌ C：Apigee は API 管理。「コード変更なしの認証追加」だけなら IAP の方が軽量。
- ❌ D：Cloud Armor は WAF。Google ドメイン制限は技術的に困難で、認証の代替にはならない。
📖 関連：02_学習資料/01_設計/01_基礎.md § Identity-Aware Proxy (IAP)
Q5 📘 単一選択
モバイルアプリのプロフィール画像を、バックエンドを経由せず直接 Cloud Storage にアップロードしたい。バックエンドの帯域を消費したくない。最適な実装は？
- A. Public な GCS バケットを作りクライアントから直接アップ
- B. Cloud Functions が中継する
- C. バックエンドが Signed URL（PUT 用）を発行し、クライアントが直接 GCS に PUT
- D. Cloud Run のリバースプロキシ経由でアップ
▶ 正解と解説
正解：C
Signed URL は IAM を変更せず、一時的なアクセス権を URL に焼き込める仕組み。バックエンドは URL を発行するだけで、データは流れない。帯域消費を回避できる。
- ❌ A：公開バケットは誰でも上書きできて危険。
- ❌ B：Cloud Functions も帯域消費する。
- ❌ D：Cloud Run も帯域消費する。
📖 関連：02_学習資料/01_設計/01_基礎.md § 署名付き URL
Q6 🔧 単一選択
サービス A から B への HTTP 呼び出しを 200 msec → 50 msec に下げたい。B のレスポンスは概ねキャッシュ可能で、同じリクエストが繰り返される。最も簡潔で運用負荷が低い実装は？
- A. B の処理を非同期化し A は Pub/Sub に publish
- B. A の前段に Memorystore for Redis を導入し、B の結果をキャッシュ
- C. B を Cloud Spanner に移行
- D. B のコードを最適化する
▶ 正解と解説
正解：B
「同じリクエストが繰り返される」「キャッシュ可能」なら Memorystore (Redis) で Cache-Aside パターン。RTT 1msec 程度なので 200msec → 50msec は十分達成可能。
- ❌ A：非同期化はレイテンシ削減にならない（むしろ複雑化）。
- ❌ C：Spanner は分散 SQL DB であり、API キャッシュには向かない。
- ❌ D：コード最適化は効果が限定的・時間がかかる。
📖 関連：02_学習資料/01_設計/01_基礎.md § キャッシュ：Memorystore
Q7 🎯 単一選択
GKE で動く 5 つのマイクロサービス間で mTLS を強制したい。サービスメッシュとして最も推奨される選択肢は？
- A. nginx-ingress + 自前 mTLS 証明書管理
- B. Cloud Service Mesh（旧 Anthos Service Mesh）
- C. Cloud Load Balancing のセッションアフィニティ
- D. VPC Service Controls
▶ 正解と解説
正解：B
Cloud Service Mesh は GKE 向けのマネージドサービスメッシュ。PeerAuthentication: STRICT で mTLS を強制、証明書の自動ローテーションも実施。
- ❌ A：自前 mTLS は運用負荷が極めて高い。
- ❌ C：セッションアフィニティは認証ではない。
- ❌ D：VPC SC はデータ持ち出し防止の境界制御。mTLS とは別概念。
📖 関連：02_学習資料/01_設計/01_基礎.md § service-to-service 通信のセキュリティ
Q8 🔧 単一選択
新しい注文受付 API を本番にリリースする。安全のため新版を 10% のトラフィックで試運転し、問題なければ徐々に拡大、異常があれば即ロールバックしたい。Cloud Run で最も簡単に実現する方法は？
- A. 同じプロジェクトに別 Service として新版をデプロイ
- B. 新リビジョンを
--no-trafficでデプロイし、update-traffic --to-revisions=LATEST=10で 10% 配信 - C. GKE に移行して Argo Rollouts を使う
- D. Cloud Load Balancing の Weighted Backend を使う
▶ 正解と解説
正解：B
Cloud Run のリビジョン + traffic split が最も簡単な canary release。--no-traffic で新リビジョンを準備、update-traffic で % を変えれば段階的展開とロールバックが容易。
- ❌ A：別 Service にすると URL が変わり、ルーティングの複雑化を招く。
- ❌ C：GKE 移行は過剰。Cloud Run の標準機能で実現できる。
- ❌ D：Cloud Run なら標準の traffic split を使うべき。LB の Weighted Backend は別ソリューション。
📖 関連：02_学習資料/01_設計/02_応用.md § Cloud Run のリビジョン管理
Q9 📘 複数選択（2つ）
シークレット管理について、Google が推奨するベストプラクティスを 2つ選べ。
- A. シークレットを環境変数として Cloud Run / GKE にデプロイ
- B. シークレットを Secret Manager に保存し、ランタイムに
access_secret_versionで取得 - C. シークレットを Git リポジトリに暗号化して保存
- D. CMEK で Secret Manager を暗号化し、ローテーション可能な構成にする
▶ 正解と解説
正解：B, D
B：Secret Manager は GCP 標準のシークレット管理。バージョン管理、IAM 制御、CMEK 対応。ランタイムに取得することで、デプロイ時に平文を露出させない。
D：CMEK で Secret Manager 自体を顧客管理鍵で暗号化することで、鍵のローテーション・無効化を顧客側で制御できる（コンプライアンス要件で頻出）。
❌ A：環境変数は
gcloud run services describeで平文表示される。❌ C：Git にシークレットを置くと誤コミット・履歴漏洩のリスク。Secret Manager に保存し、Git にはバージョン参照のみ。
📖 関連：02_学習資料/01_設計/02_応用.md § Secret Manager の使い方
Q10 🎯 複数選択（2つ）
ペタバイト級の IoT センサーデータを受信し、毎秒数百万件の書き込みとミリ秒単位の読み取りを実現したい。アプリ側の制約として正しいものを 2つ選べ。
- A. Cloud SQL の Read Replica を 100 台立てる
- B. Bigtable を選択し、行キーは Reverse Timestamp や Salt を使って分散する
- C. アクセスパターンを事前に分析し、行キー設計でホットスポットを避ける
- D. BigQuery にストリーミングインサート、毎秒数百万件で問題ない
▶ 正解と解説
正解：B, C
B：Bigtable はペタバイト級の NoSQL ワイドカラム DB。書き込みもスケール、読み取りもミリ秒。ただし「タイムスタンプそのまま」を行キーにすると最新時刻にアクセス集中（ホットスポット）するので、Reverse Timestamp や Salt で分散する。
C：Bigtable は行キー設計が全て。アクセスパターンを事前に分析し、ホットスポット回避策（Salting / Reverse Timestamp / 分散 ID）を盛り込む。
❌ A：Cloud SQL はリージョナル RDB で、ペタバイト規模・毎秒数百万件は不可能。
❌ D：BigQuery のストリーミング挿入には Storage Write API でも毎秒数百万行はかなり厳しい。OLAP であって OLTP ではない。
📖 関連：02_学習資料/01_設計/02_応用.md § Bigtable のスキーマ設計の落とし穴
自己採点
| 得点 | 評価 | 次のアクション |
|---|---|---|
| 9-10 | 🎯 合格圏 | 次セクションへ |
| 7-8 | 🔧 もう一押し | 誤答セクションを 02_学習資料/01_設計/03_要点と暗記.md で復習 |
| 5-6 | 📘 基礎再学習 | 01_基礎.md を読み直し |
| 0-4 | 📚 シラバスから | 00_試験概要/シラバス詳細.md の該当範囲を再学習 |