Section 5: 実装管理 — 問題集（20 問）

対象範囲: Section 5 (~12.5%) — Managing implementation 総問題数: 20 問 想定所要時間: 60 分（1 問 3 分目安）

学習方針

本問題集は 公式試験ガイド v2025-10 改訂版 に準拠しています。
Section 5 は CI/CD パイプライン構築、API 管理（Apigee）、移行ツール選定、開発者ツール（Cloud Shell / Cloud Code / Cloud Workstations / Gemini Code Assist）、IaC（Terraform）に焦点を当てます。
2025 年改訂で Gemini Code Assist / Cloud Workstations / Cloud Deploy Approval / Apigee X が試験範囲に加わりました。これらは新規ヒット問題として高確率で出題されます。

正答率の目安

正答率	評価	次のアクション
90% 以上	合格圏（試験本番でも安定）	模擬試験 → 直前は要点と暗記のみループ
75–89%	合格安全圏未到達	弱点別復習ガイド（巻末）で重点強化
60–74%	要対策	`02_応用.md` を再読 → Section 2 と紐付け
60% 未満	不合格圏	`01_基礎.md` から学び直し

問題 1 （難易度: ★）

シナリオ: あなたは新規 GKE プロジェクトの DevOps エンジニアです。開発者が GitHub に Push したら、自動的にコンテナイメージをビルド・テスト・スキャンし、Staging → Production の順に Cloud Deploy で進行させたいと考えています。GCP 純正のサービス組み合わせを採用する方針です。

質問: このパイプラインに使用すべき GCP サービスの組み合わせとして 最も適切 なものはどれですか。

選択肢:

A. Cloud Build + Container Registry + Cloud Functions
B. Cloud Build + Artifact Registry + Cloud Deploy
C. Jenkins + Docker Hub + GKE 直接デプロイ
D. Cloud Source Repositories + Cloud Storage + Cloud Run のみ

解答と解説

正解: B

解説:

B が正解: GCP 純正 CI/CD の王道組み合わせ。Cloud Build（CI: ビルド・テスト）→ Artifact Registry（成果物保管）→ Cloud Deploy（CD: マネージド進行管理）。
A 不正解: Container Registry は Artifact Registry に統合・廃止されました（2025 年現在）。Cloud Functions は CI/CD パイプラインの役割ではありません。
C 不正解: Jenkins / Docker Hub は OSS でも使えますが、「GCP 純正」要件に合致しません。GKE 直接デプロイは Cloud Deploy のメリット（ロールバック・承認）が活用できません。
D 不正解: Cloud Source Repositories と Cloud Storage の組み合わせは CI/CD パイプラインとして不完全です。

ひっかけポイント: 旧 Container Registry → Artifact Registry に統合 された点を必ず暗記。試験では旧名で混乱させる選択肢が出ます。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

問題 2 （難易度: ★★）

シナリオ: KnightMotives Automotive は本番リリースで「リリース後に問題発覚時は数秒で旧版に切り戻したい」要件があります。ダウンタイムは許容できず、ステートレスな API サービスを Cloud Run でホストしています。

質問: この要件を満たすデプロイ戦略として 最適なもの はどれですか。

選択肢:

A. Rolling Update — 順次置換
B. Blue-Green — 旧/新並走後に LB 切替
C. Recreate — 全停止後に再起動
D. Big Bang — 全インスタンス一括更新

解答と解説

正解: B

解説:

B が正解: Blue-Green デプロイ は旧版（Blue）と新版（Green）を並走させ、ロードバランサーで切替。問題発覚時は 数秒で旧版に切戻し可能 です。Cloud Run では Traffic Split で実装可能。
A 不正解: Rolling Update は順次置換のため、ロールバックには時間がかかります。
C 不正解: Recreate は全停止を伴い、ダウンタイム発生のため要件に反します。
D 不正解: Big Bang は Anti-pattern。ロールバックが事実上できません。

ひっかけポイント: 「即時切戻し」= Blue-Green、「段階リリース」= Canary。両者を混同しないこと。両方とも本番リリース戦略として頻出。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

問題 3 （難易度: ★★）

シナリオ: Cymbal Retail はマーケットプレイス API を世界中の外部開発者に公開する計画です。要件は: (1) 開発者ポータルでセルフサインアップ、(2) API Key 認証 + Quota 制限、(3) 利用状況に基づくマネタイズ（従量課金）、(4) 複雑なリクエスト/レスポンス変換ポリシーが必要です。

質問: この要件に最も合致する GCP サービスはどれですか。

選択肢:

A. Cloud Endpoints（ESPv2）
B. API Gateway（サーバーレス）
C. Apigee X
D. Cloud Load Balancing + IAP

解答と解説

正解: C

解説:

C が正解: Apigee X は GCP のフル機能 API 管理プラットフォーム。開発者ポータル、API Key / OAuth、Quota / SpikeArrest、マネタイズ、複雑なポリシー変換 をすべてカバーします。エンタープライズ API 公開の決定版です。
A 不正解: Cloud Endpoints は gRPC / OpenAPI 用の軽量ゲートウェイで、開発者ポータル・マネタイズ機能はありません。
B 不正解: API Gateway はサーバーレス向け軽量ゲートウェイ。開発者ポータルやマネタイズはありません。
D 不正解: Cloud LB + IAP は認証付き内部 LB ですが、API 管理機能はありません。

ひっかけポイント: API 管理 3 種を覚える: Apigee（フル機能）/ API Gateway（サーバーレス軽量）/ Cloud Endpoints（gRPC/OpenAPI）。「開発者ポータル / マネタイズ」のキーワードがあれば Apigee 一択。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

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

シナリオ: EHR Healthcare は MySQL 5.7 のオンプレ DB を Cloud SQL for MySQL 8.0 に移行する計画です。要件は: (1) ダウンタイム最小化、(2) 移行中も継続的に新規データを取り込む、(3) スキーマ変換や ETL 加工は不要、(4) 移行成功確認後にカットオーバー可能。

質問: この要件に最適な GCP 移行ツールはどれですか。

選択肢:

A. Storage Transfer Service
B. Database Migration Service (DMS)
C. Datastream
D. BigQuery Data Transfer Service

解答と解説

正解: B

解説:

B が正解: Database Migration Service (DMS) は DB 専用の最小ダウンタイム移行ツール。継続的レプリケーション（CDC）でカットオーバーまで両系統が同期され、検証完了後に切替可能。MySQL → Cloud SQL for MySQL は最も成熟したパス。
A 不正解: Storage Transfer Service は GCS / S3 / Azure 間のオブジェクト転送用で、DB には不適。
C 不正解: Datastream は CDC で DB → 分析（BigQuery / GCS） への流し込み用。DB → DB の移行用途ではありません。
D 不正解: BigQuery Data Transfer Service は SaaS（Google Ads など）→ BigQuery 用。DB 移行用ではありません。

ひっかけポイント: DMS と Datastream を混同しない。DMS = DB 移行（DB → DB）、Datastream = CDC（DB → 分析/データレイク）。両方とも MySQL/PostgreSQL/Oracle に対応しているため要件を読み解く力が問われます。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

問題 5 （難易度: ★★）

シナリオ: あるエンタープライズが、開発者ノート PC のセットアップに 1 週間かかる課題を抱えています。仕事用 IDE・依存パッケージ・GCP CLI を全社統一構成にし、プライベート VPC からのみアクセス可能、機密データは PC に保存させたくないという要件があります。

質問: この要件に最適な GCP 開発環境サービスはどれですか。

選択肢:

A. Cloud Shell Editor（ブラウザベース）
B. Cloud Code（VS Code / IntelliJ 拡張機能）
C. Cloud Workstations（マネージド開発環境）
D. GCE VM に手動セットアップ

解答と解説

正解: C

解説:

C が正解: Cloud Workstations はフルマネージドの開発環境。プライベート VPC 接続、IDE/ランタイム/ライブラリのコンテナテンプレート化、高性能マシン、機密データを PC ローカルに残さない（リモート開発）といった要件をすべて満たします。
A 不正解: Cloud Shell Editor は便利ですが、5GB 永続のみ・カスタマイズ性低・高性能要件には不適です。
B 不正解: Cloud Code はローカル IDE 拡張で、PC へのセットアップ問題が解決しません。
D 不正解: 手動セットアップは要件に逆行します。

ひっかけポイント: Cloud Shell / Cloud Code / Cloud Workstations の 3 つの違いを必ず暗記。「フルマネージド + プライベート VPC + 高性能」= Cloud Workstations 一択（2025 改訂で試験範囲に追加）。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

問題 6 （難易度: ★★）

シナリオ: あなたは VS Code でアプリケーション開発をしています。開発生産性向上のため、AI によるコード補完・テスト自動生成・コードレビュー支援を IDE 内で受けられるようにしたいと考えています。Anthropic Claude や Vertex AI とも統合可能なソリューションを探しています。

質問: この用途に最適な GCP の AI 開発支援サービスはどれですか。

選択肢:

A. Gemini Cloud Assist（GCP コンソール内 AI 支援）
B. Gemini Code Assist（IDE 内 AI コーディング支援）
C. Vertex AI Gemini API（LLM API 呼び出し）
D. Cloud Build AI Assistant

解答と解説

正解: B

解説:

B が正解: Gemini Code Assist は VS Code / IntelliJ などの IDE 内で動作する AI コーディング支援。コード補完、テスト生成、レビュー、自然言語からのコード生成をサポートします。
A 不正解: Gemini Cloud Assist は GCP コンソール内 でのアーキ設計やトラブルシュート支援で、IDE 用途ではありません。
C 不正解: Vertex AI Gemini API は LLM の API 呼び出しで、IDE 統合機能ではありません。
D 不正解: Cloud Build AI Assistant という名称のサービスは存在しません。

ひっかけポイント: Gemini Code Assist（IDE） と Gemini Cloud Assist（コンソール） を混同しないこと。両者は名前が似ているが役割が完全に違う。2025 改訂で両方とも試験範囲入りした重要トピック。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

問題 7 （難易度: ★★）

シナリオ: あなたは GCE 上で動作するアプリケーションを開発中。本番リソースで動かす前にローカルで Pub/Sub 連携をテストしたいが、本番 Pub/Sub に課金が発生してしまいます。Pub/Sub の本番接続なしにローカルでテストする手段を探しています。

質問: この用途に最適なツールはどれですか。

選択肢:

A. Cloud Pub/Sub Emulator
B. Dataflow ローカルランナー
C. Cloud Functions Local Emulator
D. Vertex AI のテスト機能

解答と解説

正解: A

解説:

A が正解: Cloud Pub/Sub Emulator は gcloud beta emulators pubsub start でローカル実行可能。本番 Pub/Sub に接続せず、課金ゼロでテストできます。クライアントライブラリの環境変数 PUBSUB_EMULATOR_HOST で切替。
B 不正解: Dataflow ローカルランナーは Dataflow ジョブのローカル実行用で、Pub/Sub 用ではありません。
C 不正解: Cloud Functions Local Emulator は Cloud Functions のローカル実行用です。
D 不正解: Vertex AI は ML 用で、Pub/Sub テスト用ではありません。

ひっかけポイント: Cloud Emulators で対応しているサービスは限定的: Bigtable / Spanner / Pub/Sub / Firestore。BigQuery や Cloud SQL の Emulator は 存在しません（実環境または小規模インスタンスで対応）。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

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

シナリオ: あなたは Terraform チームのリードとして、本番 GCP 環境を IaC で管理しています。複数の開発者が同時に terraform apply を実行することによる State 競合が発生しています。また、機密値（API キーなど）をハードコードしないようにしたいと考えています。

質問: Terraform ベストプラクティスとして 適切な記述を 2 つ 選びなさい。

選択肢:

A. GCS Backend で State を共有し、ロック機構を有効化する
B. State ファイルは Git にコミットして履歴管理する
C. 機密値は Secret Manager から取得し、tfvars にハードコードしない
D. 個人の PC 上で terraform apply を実行し、ローカル State で管理する

解答と解説

正解: A, C

解説:

A が正解: GCS Backend は Terraform 公式推奨。State を GCS に保管し、自動的に ロック機構 が有効になります。複数開発者による同時実行衝突を防げます。
C が正解: 機密値は Secret Manager から data ソース経由で取得するのがベストプラクティス。tfvars にハードコードすると Git にコミットされるリスクがあります。
B 不正解: State ファイルは機密情報を含むため Git コミット禁止。.gitignore に追加し、GCS Backend に保管。
D 不正解: ローカル State は競合・紛失リスク大。本番運用は CI 内 apply + GCS Backend が原則です。

ひっかけポイント: Terraform 必須事項: GCS Backend / CI 内 apply / plan を PR レビュー / 最小権限 SA / Secret Manager 統合。「ローカル apply」「State を Git」は両方とも Anti-pattern。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

問題 9 （難易度: ★★）

シナリオ: Cymbal Retail は本番リリースのコンプライアンス要件として、本番デプロイ前に マネジメント承認 を必須としています。CI/CD パイプラインで自動進行はしたいが、Production 直前で停止し、SLAck と Email で承認依頼を出し、承認後に進行する仕組みが必要です。

質問: この要件を満たす Cloud Deploy 機能はどれですか。

選択肢:

A. Cloud Deploy Promotion（次ターゲットへの昇進）
B. Cloud Deploy Approval（承認ゲート）
C. Cloud Deploy Verification（デプロイ後ヘルスチェック）
D. Cloud Deploy Rollback（即時前バージョンへ）

解答と解説

正解: B

解説:

B が正解: Cloud Deploy Approval はターゲット（環境）への進行前に承認ゲートを設置する機能。Pub/Sub 通知で Slack / Email 連携可能。コンプラ用途・本番手前の人手承認に必須の機能です。
A 不正解: Promotion は単に次ターゲットへの進行で、承認ゲートはオプション機能です。
C 不正解: Verification はデプロイ後の自動ヘルスチェックで、承認ではありません。
D 不正解: Rollback はロールバック機能で、承認ゲートではありません。

ひっかけポイント: 2025 改訂で Cloud Deploy Approval が試験範囲に明示追加されました。「本番デプロイ前の承認」「コンプラ要件」キーワードでは即答できることが大切です。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

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

シナリオ: あなたは大手金融機関のクラウド移行リーダーです。1 PB のオンプレデータを GCS に移行する必要があります。ネットワーク帯域は 1 Gbps しか確保できず、ネットワーク経由では 100 日近くかかる計算です。

質問: この要件に最適な移行ツールはどれですか。

選択肢:

A. gsutil cp -m（並列コピー）
B. Storage Transfer Service（ネットワーク経由）
C. Transfer Appliance（物理アプライアンス輸送）
D. Cloud Storage FUSE マウント転送

解答と解説

正解: C

解説:

C が正解: Transfer Appliance は物理ストレージ機器を貸与・データ書き込み・Google データセンターに輸送する移行ツール。100 TB 超の大規模データ移行に最適。Edge / Rackable の 2 種類があり、最大 1.0 PB（Rackable）まで対応します。
A 不正解: gsutil cp -m は便利ですが、1 PB を 1 Gbps では 100 日以上かかります。
B 不正解: Storage Transfer Service も同様にネットワーク経由のため、帯域制約を解決できません。
D 不正解: Cloud Storage FUSE はマウント用で、大規模一括転送には不向きです。

ひっかけポイント: 「>100 TB データ移行」= Transfer Appliance。ネットワーク帯域制約があれば物理輸送が現実的。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

問題 11 （難易度: ★★）

シナリオ: あなたは外部 CI（GitHub Actions）から GCP リソースを操作するワークフローを構築しています。これまで Service Account Key（JSON）をシークレットに保管していましたが、漏えいリスクを懸念しています。鍵なしで GCP に認証できる方式に変更したいと考えています。

質問: この要件に最適な認証方式はどれですか。

選択肢:

A. Service Account Key（JSON）を GitHub Secrets に保管し、暗号化する
B. Workload Identity Federation で OIDC ベースの鍵なし認証を行う
C. Workload Identity（GKE Pod ↔ GCP SA）を GitHub Actions で利用する
D. Application Default Credentials（ADC）を GitHub Secrets に保管する

解答と解説

正解: B

解説:

B が正解: Workload Identity Federation はオンプレ / 他クラウド / GitHub Actions などから GCP に OIDC / SAML / AWS トークンで認証する仕組み。Service Account Key 不要のため、漏えいリスクをゼロにできます。
A 不正解: SA Key 利用は本質的に漏えいリスクが残ります。Workload Identity Federation への移行が推奨。
C 不正解: Workload Identity は GKE Pod 専用。GitHub Actions では使えません。
D 不正解: ADC は認証コンセプトであって認証方式ではありません。

ひっかけポイント: Workload Identity（GKE Pod 用） と Workload Identity Federation（外部システム用） の違いを混同しないこと。「GitHub Actions / Jenkins / オンプレからの GCP 認証（鍵なし）」= Workload Identity Federation。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

問題 12 （難易度: ★★）

シナリオ: あなたは API クライアントを開発中。大量データを取得する API 呼び出しで、たまに 429（Too Many Requests）や 503（Service Unavailable）が返ってくることがあります。API クライアントベストプラクティスを実装したいと考えています。

質問: API ベストプラクティスとして 適切な記述を 2 つ 選びなさい。

選択肢:

A. 429 / 5xx は指数バックオフ + ジッターでリトライする
B. 4xx（クライアントエラー）も同様にリトライする
C. 大量データ取得はページング（pageToken）で分割する
D. クォータエラーは無視して全力でリトライ続行する

解答と解説

正解: A, C

解説:

A が正解: 指数バックオフ + ジッター は API クライアントの標準パターン。429（レート制限）と 5xx（サーバーエラー）は一時的なため、適切なリトライで成功率を向上できます。
C が正解: 大量データは ページング（pageToken） で分割取得。一度の呼び出しで全件取得しようとすると、タイムアウトや過大な負荷を引き起こします。
B 不正解: 4xx は クライアント側エラー（不正リクエスト・認証失敗など）でリトライ無意味。修正が必要です。
D 不正解: クォータエラーを無視してリトライは Anti-pattern。バックオフ後、必要ならクォータ増加申請を検討します。

ひっかけポイント: HTTP ステータスコード対応: 429/5xx → リトライ、4xx（401/403/400/404）→ リトライ禁止。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

問題 13 （難易度: ★★）

シナリオ: あなたは Apigee X で API 公開をしています。一部の API クライアントが短時間に大量リクエストを送ってきて、バックエンドに過大な負荷がかかります。突発的なスパイクを軽減したい一方、適切なレート以内ならリクエストは通したいと考えています。

質問: この要件に最適な Apigee ポリシーはどれですか。

選択肢:

A. Quota（時間単位のリクエスト総数制限）
B. SpikeArrest（短期間の突発スパイク制御）
C. ResponseCache（レスポンスキャッシュ）
D. VerifyAPIKey（API キー認証）

解答と解説

正解: B

解説:

B が正解: SpikeArrest は短期間（秒単位）の突発スパイクを防ぐポリシー。バックエンドを瞬間負荷から保護します。「100 リクエスト/秒」のような瞬時制御に使います。
A 不正解: Quota は時間単位（1 時間/日など）の総数制限で、瞬時のスパイク対策ではありません。両者は組み合わせて使うのが定石です。
C 不正解: ResponseCache はキャッシュでバックエンド負荷を減らしますが、リクエスト数制御ではありません。
D 不正解: VerifyAPIKey は認証ポリシーでスパイク制御ではありません。

ひっかけポイント: Quota（長期スロットリング） と SpikeArrest（瞬時スパイク防御） を区別。両者を組み合わせて使うのが Apigee の標準パターン。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

問題 14 （難易度: ★）

シナリオ: あなたはローカルから BigQuery にクエリを投げたい開発者です。最適な CLI ツールを選びたいと考えています。

質問: BigQuery 専用の CLI ツールはどれですか。

選択肢:

A. gcloud
B. gsutil
C. bq
D. kubectl

解答と解説

正解: C

解説:

C が正解: bq は BigQuery 専用 CLI。bq query --use_legacy_sql=false 'SELECT 1' のように使います。
A 不正解: gcloud は GCP リソース全般操作 CLI。BigQuery 操作も gcloud alpha bq で一部可能ですが、本格利用は bq が標準です。
B 不正解: gsutil は Cloud Storage 専用（旧、現在 gcloud storage に移行中）。
D 不正解: kubectl は Kubernetes 用。

ひっかけポイント: CLI 体系を覚える: gcloud（全般）/ gsutil（GCS、旧）/ gcloud storage（GCS 新）/ bq（BigQuery）/ kubectl（K8s）。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

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

シナリオ: EHR Healthcare は本番 Artifact Registry に格納されるコンテナイメージのサプライチェーンセキュリティを強化したいと考えています。要件は: (1) 未署名イメージのデプロイ禁止、(2) 既知 CVE スキャンの自動化、(3) SBOM（Software Bill of Materials）の生成。

質問: これらの要件を満たす GCP 機能の組み合わせとして 適切な記述を 3 つ 選びなさい。

選択肢:

A. Binary Authorization で署名検証を強制する
B. Artifact Registry の脆弱性スキャン機能を有効化する
C. Artifact Registry の SBOM 生成機能を利用する
D. Cloud Build でビルド時にイメージを難読化する
E. Cloud Run のみで運用し、コンテナを使わない

解答と解説

正解: A, B, C

解説:

A が正解: Binary Authorization は署名検証付きデプロイゲート。指定された Attestor の署名がないイメージのデプロイを禁止できます。GKE / Cloud Run で利用可能。
B が正解: Artifact Registry 脆弱性スキャン（Container Analysis API）は CVE 自動検出。継続的にイメージをスキャンし、新しい CVE が発見された場合も通知します。
C が正解: SBOM 生成 は Artifact Registry の機能で、サプライチェーン透明性確保に必須。SLSA Level 3 達成にも必要です。
D 不正解: 難読化はセキュリティ強化策ではなく、サプライチェーンセキュリティとは異なる概念です。
E 不正解: コンテナをやめるのは要件と無関係で過剰反応です。

ひっかけポイント: サプライチェーンセキュリティ 3 点セット: Binary Authorization（署名検証）+ 脆弱性スキャン + SBOM。「コンテナをやめる」は試験で時々ある誘導選択肢で、Anti-pattern。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

問題 16 （難易度: ★★）

シナリオ: Altostrat Media は数十のオンプレ VM を GCP に移行する計画です。OS とアプリケーションスタックは比較的シンプルだが、コンテナ化までの労力をかけたくありません。移行後に GCP の自動スケーリングや MIG を活用したいと考えています。

質問: この要件に最適な移行ツールはどれですか。

選択肢:

A. Migrate for Compute Engine（M4CE） — VM → GCE
B. Migrate to Containers（M2C） — VM → コンテナ化
C. Database Migration Service — DB のみ移行
D. Storage Transfer Service — ファイル転送のみ

解答と解説

正解: A

解説:

A が正解: Migrate for Compute Engine (M4CE) は VMware / Hyper-V / AWS EC2 / Azure VM などから GCE への "Lift and Shift" 移行ツール。コンテナ化せず、VM のまま GCE に移行できます。
B 不正解: M2C は VM をコンテナ化する用途。「コンテナ化までの労力をかけたくない」要件には不適です。
C 不正解: DMS は DB 専用。VM 移行には使えません。
D 不正解: Storage Transfer Service はファイル転送用で、VM 全体移行はできません。

ひっかけポイント: 移行 4 ツール: M4CE（VM → GCE）/ M2C（VM → コンテナ）/ DMS（DB）/ Storage Transfer（ファイル）+ Migration Center（計画）。各ツールの目的を明確に区別。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

問題 17 （難易度: ★★）

シナリオ: あなたは大規模なクラウド移行プロジェクトの計画フェーズです。100 以上のオンプレ VM があり、各 VM の依存関係・利用状況・移行先（GCE / Cloud Run / コンテナ化）を分析・推奨する必要があります。

質問: 移行アセスメント・計画に最適な GCP サービスはどれですか。

選択肢:

A. Migrate for Compute Engine
B. Migration Center
C. Stratozone（旧名）
D. Cloud Asset Inventory

解答と解説

正解: B

解説:

B が正解: Migration Center は移行アセスメント・計画・TCO 分析を一元的に行う GCP サービス。VM の依存マッピング、移行先推奨、コスト試算を提供します。Stratozone を統合・後継化した現行名称です。
A 不正解: M4CE は実際の移行実行ツールで、計画フェーズではありません。
C 不正解: Stratozone は旧名で、現在は Migration Center に統合・改称されています。試験で旧名選択を誘うトラップ。
D 不正解: Cloud Asset Inventory は GCP リソース棚卸し用で、オンプレ含む移行計画用ではありません。

ひっかけポイント: Stratozone → Migration Center に改称（2025）。旧名と新名の両方を覚えておくこと。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

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

シナリオ: あなたは Apigee Hybrid を導入しようとしています。要件は: (1) Apigee の管理プレーンは GCP 上に置きたい、(2) Runtime（API ゲートウェイ）はオンプレの GKE 上で動かしたい、(3) 既存オンプレシステムとの低レイテンシ通信が必須。

質問: この要件に最適なソリューションはどれですか。

選択肢:

A. Apigee X（フル GCP 上で稼働）
B. Apigee Hybrid（管理プレーン GCP + Runtime オンプレ）
C. Cloud Endpoints のみ
D. API Gateway のみ

解答と解説

正解: B

解説:

B が正解: Apigee Hybrid は管理プレーンを GCP、Runtime（API プロキシ）を任意のクラウド / オンプレの GKE 上で実行できる構成。オンプレシステムへの低レイテンシ通信を実現しつつ、GCP の管理機能を享受できます。
A 不正解: Apigee X は完全 GCP 上で稼働するため、オンプレ Runtime 要件を満たしません。
C 不正解: Cloud Endpoints は軽量で、Apigee の機能（ポータル / マネタイズ）を持ちません。
D 不正解: API Gateway はサーバーレス特化で、ハイブリッド構成は不可。

ひっかけポイント: Apigee X（フル GCP）/ Apigee Hybrid（ハイブリッド、Runtime オンプレ） の使い分けは 2025 改訂の新トピック。「オンプレ Runtime」「低レイテンシ」のキーワードで Apigee Hybrid を選ぶこと。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

問題 19 （難易度: ★★）

シナリオ: あなたは GKE 上で動作する Pod から GCP サービス（Cloud Storage / BigQuery など）にアクセスする必要があります。Pod ごとに異なる Service Account を割り当て、Pod が JSON 鍵を持たずに認証したいと考えています。

質問: この要件に最適な GCP 認証機構はどれですか。

選択肢:

A. Workload Identity（GKE Pod ↔ GCP SA バインド）
B. Workload Identity Federation
C. Node Service Account を全 Pod で共有
D. SA JSON Key を ConfigMap に保管

解答と解説

正解: A

解説:

A が正解: Workload Identity（GKE） は K8s ServiceAccount と GCP Service Account をバインドし、Pod が 鍵なしで GCP 認証 できる仕組み。Pod ごとに異なる権限を割り当てる粒度の細かい IAM が可能です。GKE のセキュリティベストプラクティスです。
B 不正解: Workload Identity Federation は 外部システム（オンプレ / 他クラウド / GitHub Actions）から GCP 認証 する仕組み。GKE Pod は Workload Identity（連邦なし） を使うのが標準。
C 不正解: Node SA 共有は粒度が粗く、最小権限原則に反します。
D 不正解: SA Key を ConfigMap で配布は危険な Anti-pattern。

ひっかけポイント: Workload Identity（GKE 内） と Workload Identity Federation（外部からの GCP） の混同に注意。問題 11 と対比して理解する。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

問題 20 （難易度: ★★）

シナリオ: あなたはアーキテクトとして、Kubernetes 中心のインフラを GitOps 流で管理したいと考えています。Pod や Service の定義は YAML で書き、Git リポジトリと K8s クラスタの状態を同期させる仕組みを構築する方針です。GCP 純正の選択肢を求めています。

質問: この要件に最適な GCP サービスはどれですか。

選択肢:

A. Cloud Deployment Manager
B. Config Sync（GKE Enterprise）
C. Terraform with GKE Provider
D. Cloud Build with kubectl

解答と解説

正解: B

解説:

B が正解: Config Sync は GKE Enterprise（旧 Anthos）の GitOps エンジン。Git リポジトリの YAML を継続的に K8s クラスタに同期し、Drift を検出・修正します。Argo CD / Flux と並ぶ GCP 純正の選択肢です。
A 不正解: Deployment Manager は レガシー（2025 年現在、新規利用非推奨）。Terraform / Config Sync が推奨です。
C 不正解: Terraform は IaC ですが、継続的同期（GitOps）の機能はありません。あくまで「apply 時点」の状態管理。
D 不正解: Cloud Build + kubectl は CI/CD 的アプローチで、GitOps の継続的同期とは異なります。

ひっかけポイント: GitOps = 継続的同期。Config Sync / Argo CD / Flux が代表ツール。Deployment Manager はレガシー。

関連リソース:

../02_学習資料/05_実装管理/02_応用.md

正答率早見表

問題	難易度	主トピック	正解
1	★	CI/CD パイプライン	B
2	★★	Blue-Green デプロイ	B
3	★★	Apigee X	C
4	★★★	DMS（DB 移行）	B
5	★★	Cloud Workstations	C
6	★★	Gemini Code Assist	B
7	★★	Cloud Pub/Sub Emulator	A
8	★★★	Terraform ベスプラ	A, C
9	★★	Cloud Deploy Approval	B
10	★★★	Transfer Appliance	C
11	★★	Workload Identity Federation	B
12	★★	API ベスプラ	A, C
13	★★	Apigee SpikeArrest	B
14	★	bq CLI	C
15	★★★	Binary Authorization + Scan + SBOM	A, B, C
16	★★	M4CE（VM → GCE）	A
17	★★	Migration Center	B
18	★★★	Apigee Hybrid	B
19	★★	Workload Identity（GKE）	A
20	★★	Config Sync GitOps	B

弱点別復習ガイド

正答率が低かった分野に応じて、以下の学習資料に戻ってください。

弱点分野	関連問題	復習リソース
CI/CD パイプライン	1, 9	`../02_学習資料/05_実装管理/02_応用.md` §「Cloud Build / Artifact Registry / Cloud Deploy」
デプロイ戦略	2, 9	`../02_学習資料/05_実装管理/02_応用.md` §「デプロイ戦略」
API 管理（Apigee）	3, 13, 18	`../02_学習資料/05_実装管理/02_応用.md` §「Apigee / API Gateway / Endpoints」
移行ツール	4, 10, 16, 17	`../02_学習資料/05_実装管理/02_応用.md` §「DMS / Datastream / M2C / M4CE」
開発者ツール（Cloud Shell / Code / Workstations）	5, 6	`../02_学習資料/05_実装管理/02_応用.md` §「Cloud Shell / Cloud Code / Workstations」
Cloud Emulators	7	`../02_学習資料/05_実装管理/02_応用.md` §「Cloud Emulators」
IaC（Terraform）	8, 20	`../02_学習資料/05_実装管理/02_応用.md` §「Terraform / Config Connector / Config Sync」
認証（ADC / Workload Identity）	11, 19	`../02_学習資料/05_実装管理/02_応用.md` §「Workload Identity / Federation / ADC」
API クライアントベスプラ	12	`../02_学習資料/05_実装管理/02_応用.md` §「API ベストプラクティス」
サプライチェーンセキュリティ	15	`../02_学習資料/05_実装管理/02_応用.md` §「Binary Authorization / SBOM」
CLI（gcloud / bq）	14	`../02_学習資料/05_実装管理/02_応用.md` §「Cloud SDK / CLI」

推奨復習サイクル

誤答した問題のみを翌日に再演（メタ認知の強化）
3 日後に全 20 問を再演（記憶定着確認）
1 週間後に模擬試験で総合演習 → ../04_模擬試験/ 配下

次は → section6_問題集.md（運用卓越性）に進む。