正解：A, E
コミュニティやフォーラムの議論、および Google Cloud の技術仕様に基づき、A と E が正解となる理由を改めて詳しく解説します。
正解： A および E
A. Cloud Service Mesh とサイドカー プロキシを使用して、アプリケーションを REST サービスに接続する。
【理由】
マルチリージョン間のサービス連携: Cloud Service Mesh（旧 Traffic Director / Anthos Service Mesh）は、複数のリージョンやクラスターに分散したマイクロサービス間の通信を管理するための標準的なソリューションです。
トラフィック管理: サイドカー プロキシ（Envoy）を使用することで、アプリケーションコードに手を加えることなく、リージョンをまたいだ負荷分散や、障害時のフェイルオーバー、mTLS によるセキュリティ強化を柔軟に実現できます。
グローバルな接続性: この構成は、異なるリージョンにある GKE クラスター同士を安全かつ効率的に接続するための Google 推奨のベストプラクティスです。
E. REST サービスのファイアウォールを構成して、GKE チェック プローブの IP 範囲から送信されるヘルスチェックを許可する。
【理由】
「Check Probe」の定義: この選択肢における「check probe」は、Google Cloud のロードバランサやメッシュのコントロールプレーンが実行する外部ヘルスチェックを指します。
ヘルスチェック用 IP の許可: 外部ロードバランサやマルチクラスター・メッシュ環境でサービスを公開する場合、Google のヘルスチェック・プローブ専用の IP 範囲（
130.211.0.0/22および35.191.0.0/16）からのインバウンド通信を VPC ファイアウォールで許可する必要があります。なぜ C ではないのか: 選択肢 C の「GKE service's IP ranges（サービス IP 範囲）」はクラスター内部の仮想 IP を指すことが多く、外部（または別リージョンのインフラ）からのヘルスチェックを許可するための設定としては、プローブのソース IP を直接指す E の方が技術的に正確で具体的であると判断されます。
コメント