【正解】C
【0からの解説】
①前提知識
・リビジョン: Cloud Run ではデプロイのたびに不変の「リビジョン」が作成され、サービスへのトラフィックをリビジョン間で分割・移行できます。新しいリビジョンをトラフィック 0% でデプロイし（コンソールの「このリビジョンをすぐに提供する」をオフ、または gcloud run deploy --no-traffic）、準備ができてから切り替えるのが段階的ロールアウトの基本です。
・最小インスタンス数: リクエストが無くてもアイドル状態で待機させておくインスタンスの数で、コールド スタート（起動時間）を回避するために使います。サービス レベルとリビジョン レベルの両方で設定できます。
・サービス レベルの最小インスタンスは、トラフィック分割に含まれるリビジョンへ、トラフィックの割合に応じて按分されます。一方、リビジョン レベルの最小インスタンスは、そのリビジョン自体に対して確保されます。
②要件の整理
・トラフィックを切り替える「前に」、新しいバージョンでアイドル インスタンスが 2 つ待機している状態にしたい
・起動時間（コールド スタート）なしで処理したい
・管理オーバーヘッド最小
③正解 C の理由
新しいリビジョンに対してリビジョン レベルの最小インスタンス数 2 を設定すれば（例: gcloud run deploy SERVICE --image=IMAGE --no-traffic --tag=green --min-instances=2。--min-instances はリビジョン レベルの設定）、そのリビジョン専用に 2 つのインスタンスが起動して待機するため、トラフィックを移したとたんにウォームなインスタンスで応答できます。設定 1 つで済み、手作業の負荷テストなども不要です。
※補足: リビジョン レベルの最小インスタンスは、そのリビジョンがトラフィック分割で参照されている、またはタグ付けされているときに起動されます。トラフィック 0% で準備したい場合は、リビジョン タグを付けておくか、ごく小さな割合を割り当てた状態で設定すると確実です。
【誤りの選択肢】
A：トラフィック 0% でデプロイすること自体は適切ですが、シミュレーション ツールで負荷をかけてインスタンスを温める方法は手作業が多く、負荷を止めればインスタンスはやがてスケールインするため、「2 つのアイドル インスタンスを確保する」ことが保証されません。管理オーバーヘッド最小という要件にも反します。
B：サービス レベルの最小インスタンスは、トラフィック分割の割合に応じてリビジョン間で按分されます。切り替え前の新しいリビジョンはトラフィックを受けていないため、その 2 インスタンスは既存のリビジョン側に割り当てられ、新しいリビジョンにはアイドル インスタンスが確保されません。
D：既存（旧）リビジョンに最小インスタンスを設定しても、温まるのは旧バージョンのインスタンスです。新しいバージョンへ切り替えたときのコールド スタート回避には役立ちません。
【参考】
Cloud Run サービスでのインスタンスの自動スケーリングについてロールバック、段階的なロールアウト、トラフィックの移行 | Cloud Run