Cloud Run は、基盤となるインフラストラクチャを気にすることなく、コンテナ化されたアプリケーションをデプロイして実行できるフルマネージド プラットフォームです。Cloud Run は受信リクエストに基づいてアプリケーションを自動的にスケーリングします。料金は使用したリソースに対してのみ発生します。Cloud Run は、サービスの複数のリビジョンのデプロイと、それらの間での顧客トラフィックの分割もサポートしています。これにより、新しい機能を段階的に展開し、運用環境でテストし、そのパフォーマンスと信頼性を監視することができます。新しいリビジョンで問題が発生した場合は、トラフィック分割を調整することで簡単に前のリビジョンにロールバックできます。これは、新しいリビジョンに関連するリスクを最小限に抑え、サービス停止の影響を受ける可能性のある顧客の数を減らし、顧客に開発コストや運用コストがかからないため、サービスのリビジョンを管理するために Google が推奨する方法です。 。
他のオプションは、Google が推奨するプラクティスに従っていないか、新しいリビジョンに関連するリスクやコストが軽減されないため、不正解です。選択肢 B は不正解です。アプリケーションを 2 番目の Cloud Run サービスにデプロイし、顧客に 2 番目の Cloud Run サービスの使用を求めることは、段階的なロールアウトではなく、完全な切り替えです。これにより、顧客に混乱や不便が生じる可能性があり、古いリビジョンと比較して新しいリビジョンのパフォーマンスと信頼性を監視することができなくなります。オプション C は不正解です。新しいリビジョンのデプロイ後に潜在的な問題を軽減するために、指数関数的バックオフを使用してサービスへのアクセスを再試行するよう顧客に求めるのは、ユーザー エクスペリエンスが良くなく、問題の根本原因に対処することにもなりません。選択肢 D は不正解です。すべての顧客トラフィックを新しいリビジョンに送信し、本番環境で問題が発生した場合に以前のリビジョンにロールバックすることは、すべての顧客を潜在的な問題にさらすことになるため、リスクとコストがかかる戦略です。新しいリビジョンをすべての顧客に展開する前にテストすることはできません。
参照：
Cloud Run のドキュメント
リビジョンの管理
トラフィックの分割

最初に [Monitoring(Stackdriver Monitoring)] をクリックすると、クリックした元の ACTIVE(CURRENT) プロジェクトにリンクされたワークスペース (スタックドライバー アカウント) が作成されます。
ここで、プロジェクトを変更し、再度 [モニタリング] をクリックすると、変更された ACTIVE(CURRENT) プロジェクトにリンクされた別のワークスペース (スタックドライバー アカウント) が作成されます。これは、結果が 1 つのダッシュボードに統合されないため、これは望ましくありません(ワークスペース/Stackdriver アカウント)。
誤って 2 つの diff ワークスペースを作成した場合は、「監視」>「設定」>「ワークスペースのマージ」>「MERGE」でそれらをマージします。
ワークスペースが 1 つとプロジェクトが 2 つしかない場合は、[モニタリング] > [設定] > [GCP プロジェクト] > [GCP プロジェクトの追加] で他の GCP プロジェクトを追加するだけです。
https://cloud.google.com/monitoring/settings/multiple-projects
グループについては何もありません https://cloud.google.com/monitoring/settings?hl=ja