【正解】A
【0からの解説】
①前提知識
・Cloud Monitoring は Google Cloud Observability の一部で、指標（メトリクス）の収集・可視化・アラートを提供するフルマネージド サービスです。かつて「Cloud Monitoring ワークスペース」と呼ばれていた単位は、現在は指標スコープ（観測対象のプロジェクトの範囲）として管理されています。
・GKE クラスタでは、システム指標（ノード・Pod・コンテナの CPU / メモリ使用量、再起動回数など）が自動的に Cloud Monitoring に送られ、GKE 用の事前定義済み（すぐに使える）ダッシュボードで、クラスタ・ノード・ワークロード・Pod 単位の状態をドリルダウンして確認できます。
・アラート ポリシーは、指標がしきい値を超えたときなどに通知チャネル（メール、Slack、PagerDuty など）へ自動通知する仕組みです。
・トリアージとは、インシデント発生時に影響範囲と優先度を素早く判断し、原因の切り分けを始めることです。
②要件の整理
・GKE をすでに Cloud Monitoring でモニタリングしている。
・SRE として「インシデントを迅速にトリアージ」したい → すぐに使える可視化と、問題を早期に検知する仕組みが必要。自作の仕組みを構築している時間はない。
③正解が要件をどう満たすか
A は、まず GKE 用の事前定義済みダッシュボードを使ってクラスタ全体からワークロード・Pod まで状態を即座に把握し、さらに必要な指標を追加してアラート ポリシーを作成します。これにより、異常が発生したらすぐに通知を受け、ダッシュボードで影響範囲を確認するという流れが、追加のインフラや開発なしで実現できます。Google の SRE のプラクティス（重要な指標に対するアラートとダッシュボードによる迅速な状況把握）にも沿った、最も迅速かつ運用負荷の小さい方法です。
【誤りの選択肢】
B：シェル スクリプト、Pub/Sub、BigQuery、Data Studio（現 Looker Studio）で独自の監視基盤を作るのは、Cloud Monitoring がすでに標準で提供している機能の再発明です。構築・保守の負担が大きいうえ、データがエクスポートされるまでの遅延があり、アラート機能もないため「迅速なトリアージ」に向きません。
C：インシデントのたびにカスタム ダッシュボードを作成していては、インシデント発生後に可視化の準備から始めることになり、対応が遅れます。事前定義済みダッシュボードという即座に使える手段を使わない点で、迅速なトリアージという要件に反します。
D：事前定義済みダッシュボードを使う前半は正しいものの、Compute Engine インスタンスに独自のアラート ソフトウェアをインストールする必要はありません。Cloud Monitoring のアラート ポリシーを使えばマネージドで通知でき、別途インスタンスを運用するのは不要な運用負荷であり、そのインスタンス自体が障害点にもなります。
【参考】
Cloud Monitoring の概要指標の収集を構成する | Google Kubernetes Engine (GKE)インシデントと問題を管理する