ある企業がAWS Organizations配下の50のスポークアカウントに対して中央集権型DNSアーキテクチャを構築しています。「Network Services」アカウントには以下が存在します：AWS Transit Gateway（全スポークVPCがアタッチ済み）、Route 53 Resolverのインバウンドエンドポイント（オンプレミスからAWSへの名前解決用）とアウトバウンドエンドポイント（AWSからオンプレミスへの転送用）、Route 53プライベートホストゾーン（*.aws.internal.example.comを管理）。オンプレミスDNSサーバーはcorp.example.comとlegacy.example.comドメインを管理しています。以下の要件があります：（1）全スポークアカウントのVPCから*.aws.internal.example.comを解決可能にする、（2）全スポークアカウントのVPCからcorp.example.comとlegacy.example.comを解決可能にする、（3）Control Tower Account Factoryで週3〜4件の新規アカウントが追加されるが、追加された時点で自動的にDNS設定が完了している状態にする、（4）Network ServicesアカウントのDNS設定変更時は追加作業なしに全スポークアカウントへ自動反映される。これらの要件を最小の運用オーバーヘッドで満たす設計として最も適切なものはどれですか？
Route 53 ResolverルールはRAMでOrganization全体に共有でき、スポークアカウントに個別のResolverエンドポイントを作成することなくオンプレミスへの転送が可能になります。プライベートホストゾーンも同様にRAMで共有でき、Network Servicesで設定変更すれば共有先のアソシエーション済みVPCに自動反映されます。Control TowerライフサイクルイベントとLambdaで新規アカウントへのDNS設定が完全自動化できます。 選択肢AのRoute 53 Resolverアウトバウンドエンドポイント個別作成は各スポークアカウントごとにエンドポイントを設置するため高コストになり、半自動化では新規アカウント追加時の完全自動化要件を満たせません。 選択肢CのRoute 53パブリックホストゾーンは内部専用ドメインをパブリックに公開するためセキュリティ上許容できず、要件に反します。 選択肢DのEC2+BINDによるDNSサーバーはEC2インスタンスの管理が必要なうえ単一障害点となり、マネージドサービスに比べ運用オーバーヘッドが大きくなります。