【正解】C
【0からの解説】
①前提知識
・Cloud Run にデプロイしたサービスには、自動的に https://<サービス名>-<ハッシュ>.a.run.app のような URL が割り当てられます。独自ドメインで公開するには、公式ドキュメント上 3 つの方法があります：(1) グローバル外部アプリケーション ロードバランサ（推奨）、(2) Cloud Run ドメイン マッピング（プレビュー段階で、本番環境向けには推奨されない）、(3) Firebase Hosting。
・グローバル外部アプリケーション ロードバランサは、世界中の Google のエッジで HTTP(S) トラフィックを受ける L7 ロードバランサです。Cloud Run をバックエンドにするにはサーバーレス ネットワーク エンドポイント グループ（サーバーレス NEG）を使います。サーバーレス NEG の「URL マスク」を使うと、.example.com や example.com/ のようなパターンからサービス名を取り出して、対応する Cloud Run サービスへ振り分けることもできます。Google マネージド SSL 証明書、Cloud CDN、Cloud Armor なども組み合わせられます。
②要件と制約の整理
・Cloud Run の既定 URL は宣伝せず、カスタム ドメイン（パーソナライズされたホスト名またはパス）でアクセスさせたい。
・グローバルなイベント → 世界中から低レイテンシでアクセスできると望ましい。
・「Google が推奨するベスト プラクティス」に従う。
③正解がどう満たすか
Cloud Run の前段にグローバル外部アプリケーション ロードバランサ（バックエンドはサーバーレス NEG）を置き、example.com の DNS の A レコード（またはワイルドカード レコード）をロードバランサの IP アドレスに向ければ、カスタム ドメインのホスト名やパスで登録ポータルにアクセスできます。これは公式ドキュメントで「推奨」とされている方法で、マネージド証明書による HTTPS、URL マスクによるホスト名 / パス ベースの振り分け、Google のグローバル エッジでの受信といったグローバル イベント向けの利点も得られます。
【誤りの選択肢】
A：Cloud Armor はロードバランサに付けるセキュリティ ポリシー（WAF・IP 制限など）であり、それ自体でカスタム ドメインから Cloud Run への「再ルーティング」を行う機能はありません。カスタム ドメインでのアクセス自体を実現できません。
B：Compute Engine 上に HAProxy を自前で構築すると、VM のパッチ適用・スケーリング・冗長化・証明書管理などをすべて自分で行う必要があり、運用負荷が大きくなります。単一の VM はボトルネック・単一障害点にもなり、マネージドなロードバランサを使う Google 推奨の方法ではありません。
D：run.app の URL へ単純に CNAME を向けても、Cloud Run 側はそのホスト名を自分のサービスとして認識せず、TLS 証明書もカスタム ドメイン用に発行されないため、正しく接続できません（Cloud Run ドメイン マッピングを使う場合に必要な DNS レコードは ghs.googlehosted.com を指すもので、しかもドメイン マッピング自体がプレビューで本番向けには推奨されていません）。
【参考】
カスタム ドメインのマッピング | Cloud RunCloud Run、App Engine、または Cloud Run functions を使用してグローバル外部アプリケーション ロードバランサを設定する。 | Cloud Load Balancing