【正解】B
【0からの解説】
①前提知識：
・Cloud Deploy は、dev → pre-prod → prod のような昇格の流れ（デリバリー パイプライン）を管理するマネージドな継続的デリバリー サービスです。リリースの昇格、承認、カナリア デプロイ、デプロイの検証に加え、以前に成功したリリースへのロールバックをコンソールや gcloud deploy targets rollback で簡単に実行できます。デプロイ履歴も記録されるため、どのイメージがどの環境に出ているかを追跡できます。
・Artifact Registry のクリーンアップ ポリシー：リポジトリに「一定期間より古いバージョンを削除する」「最新の N 個のバージョンを保持する」などの条件を設定すると、条件に合うイメージが自動で削除されます。追加のコードやジョブは不要です。
②要件の整理：(a) ロールアウトとロールバックの管理を改善する（手動で混乱を伴うロールバックをなくす）、(b) 古いコンテナ イメージをクリーンアップする、の 2 点です。どちらもマネージド機能で実現できるのが理想です。
③正解の理由：Cloud Deploy を採用すれば環境間の昇格とロールバックが組み込み機能として管理され、ロールバックは以前のリリースを再デプロイするだけで済みます。古いイメージは Artifact Registry のクリーンアップ ポリシーで自動的に削除できます。両要件をマネージド機能だけで満たすのが B です。
【誤りの選択肢】
A：Cloud Build でロールバック用のパイプラインを自作することは可能ですが、どのバージョンに戻すかの管理やリリース履歴の追跡を自分で実装・保守する必要があります。Cloud Deploy の組み込みのロールバック・リリース管理に比べて運用負荷が大きく、ロールアウト管理の改善にもなりません。
C：Cloud Service Mesh はトラフィック管理やサービス間通信の可観測性・セキュリティを提供しますが、リリースの昇格やロールバックを管理するツールではありません。また、イメージの手動クリーンアップは継続的な手作業が必要で非効率です。
D：Cloud Deploy の採用は正しいものの、イメージ削除用の Cloud Build ジョブを自作してスケジュール実行するのは、Artifact Registry に組み込まれているクリーンアップ ポリシーで済むことを自前で実装することになり、保守の手間が増えます。
【参考】
ターゲットをロールバックする | Cloud Deployクリーンアップ ポリシーの概要 | Artifact Registry