【正解】C
【0からの解説】
①前提知識
・Cloud Build は Google Cloud のマネージド CI サービスで、Git リポジトリへの push などを契機にコンテナ イメージのビルドやマニフェストの更新を自動化できます。
・Config Sync は GitOps のツールで、Git リポジトリに置いた Kubernetes の構成（マニフェスト）を GKE クラスタに自動で同期します。Namespace 単位でのリソース配置も Git から宣言的に管理できます。
・Kubernetes の Namespace は、1 つのクラスタ内でリソースを論理的に分離する単位です。GKE のマルチテナンシーの考え方では、チームや用途ごとに Namespace を分け、リソース割り当てやアクセス制御で互いに干渉しないようにします。クラスタを丸ごと増やすより、はるかに安価で素早く分離環境を作れます。
・一時環境（エフェメラル環境）とは、テストのためだけに作成し、終わったら削除する環境のことです。使った分だけ費用がかかり、環境の汚染も残りません。
②要件と制約語の整理
・問題: 共有 Dev クラスタに複数のフィーチャー ブランチがデプロイされ、互いに干渉している。
・要件: 各開発者がフィーチャー（機能）を「他の開発作業から隔離された安定した開発環境」でテストできること。
・制約語: 「費用対効果が高い（cost-effective）」。
③正解の根拠
C は、フィーチャー ブランチへのコミットを契機に Cloud Build でマニフェストを更新し、Config Sync で既存の Dev GKE クラスタ上に動的に作成した Namespace へデプロイしてテストします。ブランチごとに Namespace が分かれるため他の開発作業と干渉せず、テスト後に Namespace を削除するので環境が残り続けることもありません。クラスタは 1 つを共有し、自動スケーリングで必要なときだけノードが増えるため、費用も最小限です。「隔離」と「費用対効果」の両方を満たすのは C です。
【誤りの選択肢】
A：main ブランチへのマージ リクエストを契機にしているため、フィーチャー ブランチの段階では隔離されたテストができません。開発者が求めているのは「マージ前に自分の機能を隔離環境でテストすること」であり、main への統合を前提にすると干渉の問題を解決できません。
B：コミットごとに Dev、Staging、Prod へのプログレッシブ デリバリーを行う構成で、共有 Dev クラスタに複数ブランチがデプロイされて干渉するという根本の問題を解決していません。フィーチャーごとの隔離された環境が用意されないため、要件を満たしません。
D：フィーチャー ブランチごとに GKE クラスタを丸ごと作成すると、隔離は実現できますが、クラスタの管理手数料やノードの費用、作成に要する時間がブランチ数だけ増えます。Namespace による分離で十分に隔離できる状況では費用対効果が低く、「費用対効果が高い」という制約に反します。
【参考】
クラスタ マルチテナンシー | Google Kubernetes Engine (GKE)Config Sync の概要ビルドトリガーの作成と管理 | Cloud Build