第1回 問題集（全般）

正解: B. B. グローバルロードバランサとマルチリージョンの正常性確認による自動フェイルオーバー設計

正解の根拠・詳細解説

複数リージョンでの高可用性を実現するには、グローバルロードバランサと各リージョンのヘルスチェックを組み合わせ、障害リージョンを自動的にトラフィックから除外するフェイルオーバー設計が必要です。

正解: B. B. Cloud DNSのプライベートゾーンとDNS転送・DNSピアリングを組み合わせる

正解の根拠・詳細解説

ハイブリッド環境のDNS統合には、Cloud DNSのプライベートゾーンを軸に、オンプレミス側との名前解決はDNS転送（フォワーディング）、Google Cloud内の複数VPC間ではDNSピアリングを組み合わせるのが標準的な設計です。

正解: A. A. セカンダリ範囲はPodとServiceのIPアドレス範囲を提供するために使用される

正解の根拠・詳細解説

VPCネイティブGKEクラスタでは、ノードのプライマリ範囲に加えて、Pod用とService用の2つのセカンダリ範囲（エイリアスIP範囲）をサブネットに割り当てます。これによりIPアドレス空間に基づくスケーリング計画が必要になります。

正解: B. B. roles/compute.networkUser（特定サブネットへのネットワークユーザーロール）

正解の根拠・詳細解説

共有VPCではホストプロジェクトの管理者がサービスプロジェクトに対し、特定サブネット単位でcompute.networkUserロールを付与することで、最小権限の原則に従ったサブネット利用許可を実現します。

正解: A. A. プライベートサービスアクセスはVPCピアリングベースでIP範囲を予約し、PSCはエンドポイントベースで1対1または1対多の接続を提供する

正解の根拠・詳細解説

プライベートサービスアクセスはVPCピアリングを利用してIPレンジを予約し管理されたサービスに接続する方式、PSCはエンドポイント（IPアドレス）を介してサービスへ接続する方式で、サービス公開モデルや管理範囲が異なります。

正解: A. A. カスタムスタティックルートまたはポリシーベースルートとロードバランサを使った挿入設計

正解の根拠・詳細解説

NVAの挿入には、カスタムルート（静的またはポリシーベース）でトラフィックをNVA経由に誘導し、高可用性のために内部ロードバランサをネクストホップとして利用する設計が一般的です。

正解: B. B. VPCネットワークのMTUは1300〜8896の範囲で設定可能で、Cloud InterconnectやVPN経由の通信ではカプセル化オーバーヘッドを考慮する必要がある

正解の根拠・詳細解説

Google CloudのVPCネットワークのMTUは1300〜8896バイトの範囲で設定可能です。Cloud InterconnectやHA VPNを介した通信ではカプセル化によるオーバーヘッドが生じるため、エンドツーエンドでパケットの断片化が起きないよう適切なMTUを選定する必要があります。

正解: B. B. Google Cloudと他のクラウドプロバイダー間に専用の高帯域幅接続を直接確立するマルチクラウド接続

正解の根拠・詳細解説

Cross-Cloud InterconnectはGoogle Cloudと他のクラウドプロバイダー（AWSやAzureなど）間で専用の物理接続を確立し、高帯域幅・低レイテンシのマルチクラウド接続を実現するサービスです。

正解: B. B. Google API用のPrivate Service Connectエンドポイントを構成し、ハイブリッド接続経由でプライベートアクセスする

正解の根拠・詳細解説

オンプレミスからGoogleの管理対象APIへプライベートにアクセスするには、Google API用のPrivate Service Connectエンドポイントを構成し、Cloud InterconnectやHA VPN経由でオンプレミスからアクセス可能にする設計が推奨されます。

正解: A. A. ノードに外部IPアドレスを割り当てずに公開範囲を最小化し、セキュリティを向上させる

正解の根拠・詳細解説

プライベートノードは外部IPアドレスを持たないため、インターネットからの直接アクセスを防ぎ、攻撃対象領域を縮小できます。アウトバウンド通信にはCloud NATなどを併用します。

正解: A. A. プレミアムティアはGoogleのグローバルバックボーンネットワークを経由し、スタンダードティアは公衆インターネットの一部を経由する

正解の根拠・詳細解説

プレミアムティアはGoogleの専用グローバルネットワークバックボーンを最大限利用するため低レイテンシ・高信頼性ですが、スタンダードティアより高コストです。スタンダードティアは一部で公衆インターネットを経由します。

正解: A. A. リージョンモードはそのリージョンのCloud Routerが学習したルートのみをそのリージョンのサブネットに伝達し、グローバルモードは全リージョンに伝達する

正解の根拠・詳細解説

リージョン動的ルーティングではCloud Routerが学習したルートは同一リージョン内のサブネットにのみ伝播しますが、グローバル動的ルーティングでは全リージョンのサブネットに伝播されます。

正解: B. B. プライベートエンドポイントを有効化し、承認済みネットワーク（authorized networks）でオンプレミスのCIDR範囲のみを許可する

正解の根拠・詳細解説

GKEのコントロールプレーンエンドポイントをプライベートにし、承認済みネットワーク機能で特定のCIDR範囲（オンプレミスの管理ネットワークなど）のみアクセスを許可する設計が、セキュリティを保ちながら運用アクセスを確保する標準的な方法です。

正解: A. A. Googleと直接物理接続契約を結ぶことなく、信頼されたパートナー経由でダイレクトピアリングに近い接続性を得たい場合

正解の根拠・詳細解説

Verified Peering Providerは、Googleと直接のピアリング契約を結ぶ規模に達しない企業が、認定されたパートナー経由で同等の接続性メリットを得るための選択肢です。

正解: B. B. ハブアンドスポークトポロジでオンプレミスをハブ、各VPCをスポークとして接続を集約する

正解の根拠・詳細解説

Network Connectivity Centerのハブアンドスポークトポロジを使うことで、オンプレミス拠点をハブとして複数のVPCスポークへの接続を一元管理でき、接続数の増加に伴う複雑性を抑えられます。

正解: A. A. 社内システムの統合によりRFC1918のプライベートアドレス空間が重複し、十分なIPアドレス空間を確保できない場合

正解の根拠・詳細解説

企業合併や大規模システムにおいてRFC1918のプライベートアドレス空間（10.0.0.0/8等）が枯渇・重複する場合、所有しているパブリックIPアドレス（PUPI: Privately Used Public IP）をVPC内部で利用する設計が検討されます。

正解: B. B. デュアルスタッククラスタやIPv6シングルスタッククラスタなど複数の構成があり、サブネットのIPv6アクセスタイプ（内部/外部）を計画する必要がある

正解の根拠・詳細解説

GKEではIPv4シングルスタック、デュアルスタック、IPv6シングルスタックなど複数の構成がサポートされ、サブネットのIPv6アクセスタイプ（内部限定か外部公開か）を事前に計画する必要があります。

正解: A. A. Dedicated Interconnectは10Gbpsまたは100Gbpsの専用物理回線をGoogleと直接確立し、Partner Interconnectはパートナー経由で低帯域から接続できる

正解の根拠・詳細解説

Dedicated InterconnectはGoogleのColocation施設で専用の物理回線（10Gbpsまたは100Gbps単位）を直接確立する方式、Partner Interconnectはサービスパートナー経由でより柔軟な帯域幅（50Mbps〜）から接続できる方式です。

正解: A. A. Kubernetes Gateway APIに準拠した宣言的な設定で、トラフィック分割やヘッダーベースルーティングなど高度なL7制御が可能になる

正解の根拠・詳細解説

GKE Gateway ControllerはKubernetes Gateway APIに準拠し、トラフィック分割・ヘッダーベースルーティング・mTLSなど高度なL7トラフィック制御を宣言的に設定できる点が、従来のIngressより優れています。

正解: A. A. Cloud FunctionsやCloud Run、App EngineなどのサーバーレスサービスからVPC内のプライベートリソース（Cloud SQLなど）に直接アクセスする場合

正解の根拠・詳細解説

サーバーレスVPCアクセスは、Cloud Functions・Cloud Run・App Engineなどのサーバーレスサービスから、VPC内部のプライベートIPを持つリソース（Cloud SQL、Memorystoreなど）へ直接通信するために使用します。

正解: A. A. 標準モードはIGP的なコストベースの選択を行い、従来モードはAS-PATHの長さのみに依存する独自の選択を行う

正解の根拠・詳細解説

標準モードはより一般的なネットワーキング業界標準（コストベース）に近いパス選択ロジックを採用し、従来モードはGoogle Cloud独自のAS-PATH長に基づく選択ロジックを使用します。新規VPCでは標準モードが推奨されます。

正解: A. A. 外部IPを持たないVM等のリソースが、外部IPなしでGoogle APIおよびサービスにアクセスできるようにする

正解の根拠・詳細解説

プライベートGoogleアクセスを有効にすることで、外部IPアドレスを持たないVMインスタンスでも、Google CloudのAPIやサービス（Cloud Storageなど）にプライベートな経路でアクセスできるようになります。

正解: A. A. 組織のガバナンス・分離要件が強くチーム間でネットワーク管理権限を完全分離したい場合はスタンドアロンVPC、中央管理されたネットワークを複数チームで利用したい場合は共有VPCが適している

正解の根拠・詳細解説

強い分離要件やコンプライアンス上の理由がある場合はスタンドアロンVPCで管理権限を分離し、ネットワーク管理を中央チームに集約しつつ複数プロジェクトでリソースを共有したい場合は共有VPCが適しています。

正解: A. A. ノードあたりのPod数の上限とセカンダリ範囲（Pod範囲）のサブネットサイズが、クラスタ全体でスケール可能なノード数とPod数を制限する

正解の根拠・詳細解説

VPCネイティブクラスタでは、サブネットのセカンダリ範囲（Pod用CIDR）のサイズと、ノードあたりの最大Pod数の設定が、クラスタ全体で実行可能なノード数・Pod数の上限を事実上制約します。

正解: A. A. すべてのスポーク間で対等な全方向通信が必要な場合はメッシュ、中心拠点を経由した通信に集約したい場合はスタートポロジが適している

正解の根拠・詳細解説

メッシュトポロジは全てのスポーク間で直接通信が可能な構成、スタートポロジは中心となるハブ経由でのみスポーク間通信を行う構成です。要件に応じてどちらかまたは併用を選択します。

正解: A. A. IPアドレス管理（IPAM）を組織レベルで統一し、各拠点・VPCのCIDR割り当てを一元的に記録・管理する

正解の根拠・詳細解説

ハイブリッド環境でのIPアドレス重複は通信障害の典型的な原因です。組織全体でIPAM（IPアドレス管理）を統一し、各VPC・オンプレミス拠点のCIDR割り当てを一元的に管理することが重複回避の基本です。

正解: A. A. RFC1918のプライベートアドレス空間が不足する大規模クラスタにおいて、所有しているパブリックIP範囲を内部的にNAT不要で利用する

正解の根拠・詳細解説

PUPI（Privately Used Public IP）は、インターネット上ではパブリックとして割り当てられているアドレス範囲を、外部に広告せずVPC内部だけで利用する運用方法です。Google CloudのVPCではサブネットのプライマリ範囲やセカンダリ範囲にRFC1918以外のアドレスを指定でき、既定ではその経路はインターネットへ広告されません。大規模なGKEクラスタではノード数の増加に伴いPodやServiceが大量のIPを必要とし、社内の他システムとの重複を避けながらプライベートアドレス空間を確保することが難しくなります。こうした場合にPUPIをPod用のセカンダリ範囲へ割り当てれば、アドレス設計をやり直さずにクラスタを拡張できます。ただし自社VPC内で使ったパブリック範囲については、その範囲が本来指すインターネット上の宛先へ到達できなくなるため、実際に通信する必要のないアドレスを選ぶ必要があります。またVPCピアリングでは、PUPIの経路をエクスポート・インポートするかどうかを明示的に設定する必要がある点にも注意します。

正解: A. A. ホストプロジェクトを有効化し、サービスプロジェクトを紐付けた後、IAMでサブネット単位のネットワークユーザーロールを付与する

正解の根拠・詳細解説

共有VPCでは、ホストプロジェクトを有効化してサービスプロジェクトを紐付け、サブネット単位でcompute.networkUser等のIAMロールをサービスプロジェクトの利用者に付与することで、複数プロジェクト間でネットワークリソースを安全に共有します。

正解: A. A. 特定のGoogle Cloudサービスへのアクセスを境界内のリソースに制限し、データの持ち出し（データエクスフィルトレーション）リスクを低減する

正解の根拠・詳細解説

VPC Service Controlsは、Cloud StorageやBigQueryなどのサービスAPIへのアクセスをセキュリティ境界内に制限し、認可されていないネットワークやIDからのデータアクセス・持ち出しを防止するための機能です。

正解: A. A. 双方のVPCでカスタムルートのエクスポート・インポートを明示的に有効化しないと、ピアリングされたVPC間でサブネット以外のルートは伝播しない

正解の根拠・詳細解説

VPCネットワークピアリングではデフォルトでサブネットルートのみが共有されます。カスタム静的ルートやCloud Routerが学習した動的ルートを共有するには、両VPC側でエクスポート・インポートをそれぞれ明示的に有効化する必要があります。

正解: A. A. 送信元IPアドレスやプロトコルなど宛先以外の条件に基づいてパケットの転送経路を決定したい場合

正解の根拠・詳細解説

通常の宛先ベースルーティングでは表現できない、送信元アドレスやプロトコルなどの条件に基づいた転送経路の制御が必要な場合（例: NVA経由の検査トラフィックの選別）にポリシーベースルーティングが有効です。

正解: A. A. Private Service ConnectやPrivate NATで提供されるマネージドサービスの到達可能性をハブ経由で他のスポークに伝播する

正解の根拠・詳細解説

プロデューサースポークは、Private Service ConnectエンドポイントやPrivate NATなどで提供されるサービスへの到達可能性を、NCCハブ経由で他のスポーク（VPCやハイブリッド）に伝播させる役割を持ちます。

正解: A. A. eBPFベースのデータプレーンによりネットワークポリシーの適用とパフォーマンス・可視性が向上する

正解の根拠・詳細解説

GKE Dataplane V2はCiliumベースのeBPF技術を採用し、kube-proxyに依存せずにネットワークポリシーの適用、より高い可視性とパフォーマンスを提供するデータプレーンです。

正解: A. A. Pod IPをノードIPに変換して外部ネットワークへの通信を可能にし、特定の宛先（同一VPC内など）への通信ではマスカレードを除外する制御を行う

正解の根拠・詳細解説

ip-masq-agentのIPマスカレードポリシーは、PodがクラスタIP範囲外の宛先と通信する際にノードのIPへSNATする一方、内部ネットワークなど特定の宛先（non-masquerade-cidr）への通信ではマスカレードを除外する設定を可能にします。

正解: A. A. オンプレミスのルート変更が自動的に学習・反映され、静的ルートの手動メンテナンスが不要になる

正解の根拠・詳細解説

Cloud RouterはBGPを使用してオンプレミスルーターとルート情報を動的に交換するため、オンプレミス側のネットワーク変更が自動的に反映され、静的ルートの手動更新作業を削減できます。

正解: A. A. 既存の割り当て済み範囲を保持したまま、追加のIP範囲を割り当てて拡張する

正解の根拠・詳細解説

プライベートサービスアクセスで使用するIP範囲が不足した場合、既存の割り当てを保持したまま追加のIP範囲（CIDR）を割り当てることで、サービスの可用性を維持したまま拡張が可能です。

正解: A. A. 数値が小さいほど優先度が高く、最初にマッチしたルールが適用される

正解の根拠・詳細解説

VPCファイアウォールルールでは0〜65535の範囲で優先度を指定し、数値が小さいほど優先度が高く評価されます。複数ルールがマッチする場合、最も優先度の高い（数値が小さい）ルールが適用されます。

正解: A. A. サブネットの範囲拡大は可能だが、既存の範囲を縮小したり既に割り当てた範囲と重複させることはできない

正解の根拠・詳細解説

VPCサブネットのプライマリIP範囲は、既存範囲を含む形でCIDRを拡大することが可能ですが、縮小や他の既存範囲との重複は許可されません。

正解: A. A. 特定のタグが付与されたインスタンスにのみ適用されるカスタムスタティックルートを作成できる

正解の根拠・詳細解説

カスタムスタティックルートには次のホップとタグを指定でき、特定のネットワークタグが付与されたインスタンスのみにルートを適用する、より細かい制御が可能です。

正解: A. A. プライベートGoogleアクセスまたはGoogle API用のPrivate Service Connectエンドポイントを構成する

正解の根拠・詳細解説

VPC内のリソースやオンプレミスからVertex AIへプライベートにアクセスするには、プライベートGoogleアクセスの有効化、またはGoogle API用のPrivate Service Connectエンドポイントの構成が必要です。

正解: A. A. 特定のスポークから他のスポークへ伝播するルートのCIDR範囲を制限し、意図しない範囲の到達可能性を防ぐ

正解の根拠・詳細解説

NCCのスポークレベルでのIP/CIDR範囲フィルタは、特定のスポークから他のスポークに伝播されるルートの範囲を制限し、意図しない広範な到達可能性やルートの重複を防止します。

正解: A. A. ノードのプライマリIPとは別にPod用のエイリアスIP範囲をサブネットのセカンダリ範囲から割り当て、VPCネットワーク内でPod IPを直接ルーティング可能にする

正解の根拠・詳細解説

VPCネイティブクラスタでは、各ノードにエイリアスIP範囲（セカンダリ範囲から割り当て）を付与し、Pod IPをVPCネットワーク内で直接ルーティング可能にすることで、ルートベース方式より高いスケーラビリティを実現します。

正解: A. A. 許可・拒否されたトラフィックの詳細をCloud Loggingに記録し、監査やトラブルシューティングに利用する

正解の根拠・詳細解説

ファイアウォールルールのロギングを有効にすると、ルールにマッチしたトラフィックの送信元・宛先・アクション等の詳細がCloud Loggingに記録され、セキュリティ監査やネットワークトラブルシューティングに活用できます。

正解: A. A. MED（マルチ出口識別子）などの優先度設定により、Google Cloud側はどの経路を優先するかを決定できる

正解の根拠・詳細解説

Cloud RouterはBGPのMED（マルチ出口識別子）やローカルプレファレンスに相当する優先度設定をサポートし、グローバル動的ルーティングモードで複数の経路がある場合にどの経路を優先するかを制御できます。

正解: A. A. 高可用性のNVA（ネットワーク仮想アプライアンス）クラスタへのトラフィックを負荷分散しながらルーティングする場合

正解の根拠・詳細解説

高可用性を確保するため複数のNVAインスタンスをバックエンドとする内部ロードバランサをカスタムルートのネクストホップとして指定することで、NVA経由のトラフィックを負荷分散しつつ冗長性を持たせられます。

正解: A. A. スポーク間でNAT変換されたアドレスの到達可能性を共有し、ハイブリッドネットワーク全体でアドレス変換ポリシーを統一する

正解の根拠・詳細解説

Private NATはVPC内のRFC1918範囲同士のアドレス重複を解決する目的で使われ、NCC経由でその変換結果の到達可能性を他のスポークに伝播することで、ハイブリッド全体で整合性のあるアドレス変換ポリシーを実現します。

正解: A. A. VPCネットワークでService Networking APIが有効化され、十分な大きさのCIDR範囲が予約されていること

正解の根拠・詳細解説

プライベートサービスアクセスを利用するには、Service Networking APIを有効化し、利用予定のマネージドサービス（Cloud SQL、Memorystoreなど）の規模に応じた十分なサイズのCIDR範囲をVPC内に予約しておく必要があります。

正解: A. A. 既存のPod用セカンダリ範囲のIPアドレスが枯渇しそうな大規模クラスタにおいて、追加のセカンダリ範囲を割り当ててPod IPの枯渇を防ぐ

正解の根拠・詳細解説

VPCネイティブのGKEクラスタでは、Pod用のIPはサブネットのセカンダリ範囲（エイリアスIP範囲）から払い出され、各ノードにはその一部が固定サイズのブロックとして割り当てられます。1ノードあたりの最大Pod数が既定の110であればノードごとに/24が確保される計算になるため、ノード数が増えるとセカンダリ範囲は想像以上に速く枯渇します。従来はこの範囲を後から広げられず、クラスタを作り直す必要がありましたが、追加のPod範囲（discontiguous multi-Pod CIDR）を使うと、既存クラスタに連続していない別のセカンダリ範囲を追加し、ノードプール単位でその範囲からPod IPを払い出せます。これによりクラスタを再作成せずにスケールを継続できます。あわせて、1ノードあたりの最大Pod数を実態に合わせて小さくすればノードごとのブロックも小さくなり、同じ範囲でより多くのノードを収容できるため、設計段階の見積もりと組み合わせて検討すると効果的です。

正解: A. A. グローバル外部ロードバランサは複数リージョンのバックエンドに対応し単一のエニーキャストIPでトラフィックを最寄りのリージョンに転送できる

正解の根拠・詳細解説

グローバル外部アプリケーションロードバランサは単一のエニーキャストIPアドレスで複数リージョンに分散されたバックエンドへトラフィックを転送し、最寄りのリージョンへルーティングできる点が特徴です。

正解: A. A. コンテナベースのワークロードやハイブリッド接続先など、VMインスタンスグループ以外のバックエンドをロードバランサに登録できる

正解の根拠・詳細解説

NEG（ネットワークエンドポイントグループ）は、GKE Pod、サーバーレスサービス、オンプレミスのハイブリッドエンドポイント、インターネット上のエンドポイントなど多様なバックエンドタイプをロードバランサに登録するために使用します。

正解: A. A. 同一クライアントからのリクエストを可能な限り同じバックエンドインスタンスに転送し、セッション状態の継続性を保つ

正解の根拠・詳細解説

セッションアフィニティ（クライアントIP、生成クッキーなど）を設定することで、同一クライアントからの後続リクエストを同じバックエンドに転送し、ステートフルなアプリケーションのセッション継続性を確保できます。

正解: A. A. 同一リージョン内に限らず他リージョンのクライアントからも内部ロードバランサにアクセス可能にする

正解の根拠・詳細解説

内部ロードバランサはデフォルトで同一リージョン内からのみアクセス可能ですが、グローバルアクセスを有効化すると他のリージョンに配置されたクライアントからもアクセスできるようになります。

正解: A. A. Google Cloud外（オンプレミスやサードパーティのオブジェクトストレージ）にあるコンテンツをGoogleのエッジでキャッシュして配信を高速化したい場合

正解の根拠・詳細解説

Cloud CDNはインターネットNEGを使うことで、Google Cloud外にあるオリジン（オンプレミスのWebサーバーやサードパーティのオブジェクトストレージなど）のコンテンツもGoogleのエッジロケーションでキャッシュし、配信を高速化できます。

正解: A. A. キャッシュ無効化（cache invalidation）リクエストを発行し、指定したパスパターンのキャッシュエントリを強制的に削除する

正解の根拠・詳細解説

Cloud CDNではURLパスパターンを指定したキャッシュ無効化リクエストを発行することで、TTL満了を待たずに古いキャッシュエントリを強制的に削除し、最新コンテンツへの切り替えを即時に反映できます。

正解: A. A. 有効期限付きの一意なURLを生成し、認可されたユーザーのみが特定のコンテンツにアクセスできるようにする

正解の根拠・詳細解説

署名付きURLは有効期限とアクセス条件を含む暗号署名をURLに付与し、その条件を満たすリクエストのみがCDN経由でコンテンツにアクセスできるようにする、コンテンツ保護のための機能です。

正解: A. A. クライアントの地理的な発信元に基づいて、最も近いリージョンのエンドポイントを指すDNS応答を返す

正解の根拠・詳細解説

Cloud DNSの位置情報ルーティングポリシーは、クエリの発信元の地理的位置に基づいて、最も近いリージョンのリソースを指すレスポンスを返すことで、レイテンシの最適化を実現します。

正解: A. A. ヘルスチェックと連携し、プライマリエンドポイントが異常な場合に自動的にバックアップエンドポイントへDNS応答を切り替える

正解の根拠・詳細解説

Cloud DNSのフェイルオーバールーティングポリシーはヘルスチェックの結果と連携し、プライマリのエンドポイントが異常と判定された場合に自動的にバックアップのエンドポイントを指すDNS応答に切り替えます。

正解: A. A. 同じドメイン名に対して、内部（VPC内）と外部（インターネット）のクライアントで異なるDNS応答を返す

正解の根拠・詳細解説

スプリットホライズンDNSは、Cloud DNSのプライベートゾーンとパブリックゾーンを使い分けることで、同一のドメイン名に対し内部クライアントには内部IP、外部クライアントには外部IPを返すなど、利用者の立場に応じた異なる応答を実現します。

正解: A. A. DNS応答に電子署名を付与し、DNSキャッシュポイズニングなどの応答改ざん攻撃を検知・防止する

正解の根拠・詳細解説

DNSSECはDNS応答に暗号署名を付与し、リゾルバ側でその署名を検証することで、DNSキャッシュポイズニングなどによる応答の改ざんやなりすましを検知・防止する仕組みです（通信内容自体の暗号化ではありません）。

正解: A. A. KubernetesのServiceやIngressリソースの作成に応じて、対応するDNSレコードをCloud DNSに自動的に作成・更新する

正解の根拠・詳細解説

external-dns（外部DNSオペレーター）は、Kubernetes内のServiceやIngressリソースの状態変化を検知し、対応するDNSレコードをCloud DNSなどの外部DNSプロバイダーに自動的に反映するOSSツールです。

正解: A. A. 本番トラフィックのコピーをテスト環境やセキュリティ分析用バックエンドに転送し、本番トラフィックには影響を与えずに分析する

正解の根拠・詳細解説

アプリケーションロードバランサのトラフィックミラーリング機能は、実際のトラフィックのコピーを別のバックエンド（テストやセキュリティ分析用）に送信し、本番トラフィックのレスポンスには影響を与えずに新バージョンの検証等が行えます。

正解: A. A. あるプロジェクトのプライベートゾーンを別のプロジェクトのVPCネットワークから解決可能にする

正解の根拠・詳細解説

DNSのプロジェクト間バインディング（cross-project binding）は、あるプロジェクトで作成したCloud DNSプライベートゾーンを、別プロジェクトのVPCネットワークにも関連付けて名前解決できるようにする機能です。

正解: A. A. チェック間隔（interval）・タイムアウト・正常/異常判定の連続しきい値（healthy/unhealthy threshold）

正解の根拠・詳細解説

ヘルスチェックのチェック間隔、タイムアウト、連続して何回成功/失敗したら状態を切り替えるかのしきい値（healthy/unhealthy threshold）を適切に調整することで、一時的な遅延による誤検知を防ぎつつ、実際の障害を適切に検出できます。

正解: A. A. リクエストのホストやパスに基づいて異なるバックエンドサービスへトラフィックを振り分ける

正解の根拠・詳細解説

URLマップは、リクエストのホスト名やURLパスのパターンに基づいて、どのバックエンドサービス（またはバケット）にトラフィックをルーティングするかを定義するロードバランサの中核的な設定です。

正解: A. A. GKE Gateway ControllerはKubernetes Gateway APIに基づく新しい設計で、従来のIngressリソースより高度なトラフィック制御機能を提供する

正解の根拠・詳細解説

GKE Gateway ControllerはKubernetes Gateway APIという新しい標準に基づいており、従来のIngressリソースよりも柔軟なルーティングルールやトラフィック分割など、より高度なL7制御機能を提供します。

正解: A. A. Cloud DNSの転送ターゲット（DNS転送ポリシー）を構成し、オンプレミス側のDNSサーバーからのクエリを受け付ける

正解の根拠・詳細解説

Cloud DNSのDNSサーバーポリシー（インバウンド転送）を構成することで、オンプレミスのDNSサーバーがCloud DNSのプライベートゾーンへクエリを転送し、名前解決を統合できます。

正解: A. A. バックエンドインスタンスのCPU使用率などのリソース使用状況に基づいて動的にトラフィックを分散できる

正解の根拠・詳細解説

使用率ベースの分散モードでは、各バックエンドインスタンスのCPU使用率（または指定したカスタム指標）に応じて動的にトラフィック量を調整するため、負荷の偏りを抑えた効率的な分散が可能です。

正解: A. A. パススルー型は元のクライアントIPを保持したままバックエンドに転送し、プロキシ型はロードバランサがTCP/TLS接続を終端してバックエンドと新たな接続を確立する

正解の根拠・詳細解説

パススルー型（Network Load Balancer）はクライアントの送信元IPアドレスを保持してそのままバックエンドに転送しますが、プロキシ型（Application Load Balancerなど）はロードバランサが接続を終端し、バックエンドとは別の接続を新たに確立します。

正解: A. A. スケーリングポリシーの指標（CPU使用率やロードバランシング容量など）をロードバランサのトラフィック特性に合わせて選択する

正解の根拠・詳細解説

MIGの自動スケーリングは、CPU使用率・ロードバランシング容量・カスタム指標などのスケーリングポリシーを設定でき、実際のトラフィック特性（バーストの有無など）に応じて適切な指標を選ぶことで効果的なスケーリングが実現します。

正解: A. A. 既存DNSのゾーンファイルをエクスポートし、Cloud DNSへゾーンとレコードをインポートした後、ネームサーバーの切り替えを段階的に行う

正解の根拠・詳細解説

DNS移行では、既存プロバイダーのゾーンファイルをエクスポートしてCloud DNSにインポートし、レコードの整合性を確認した上でレジストラ側のネームサーバーをCloud DNSのものに切り替えるという段階的な手順が推奨されます。

正解: A. A. Pod IPに直接トラフィックを転送できるため、kube-proxy経由のオーバーヘッドや余分なホップが減少し、ヘルスチェックの精度も向上する

正解の根拠・詳細解説

NEGを使ったコンテナネイティブロードバランシングでは、ロードバランサがPodのIPアドレスへ直接トラフィックを転送できるため、Service経由のNAT変換やkube-proxyによる余分なホップが排除され、より正確なヘルスチェックとレイテンシ改善が得られます。

正解: A. A. CNAMEレコードを設定したホスト名には、同じ名前で他の種類のレコード（A・MX等）を同時に設定できない

正解の根拠・詳細解説

CNAMEはあるホスト名を別の正式名（正規名）へ読み替えるレコードで、DNSの仕様上、CNAMEを設定した名前には同じ名前で他の種類のレコードを共存させることができません。その名前へのあらゆる問い合わせが転送先へ読み替えられるため、AレコードやMXレコードが同居していると、どちらを返すべきかが一意に決まらなくなるからです（DNSSECの署名関連レコードなど、ごく一部だけが例外として認められています）。この制約から特に注意が必要なのがゾーン頂点（apex、たとえばexample.com自体）で、ここにはSOAレコードとNSレコードが必ず存在するためCNAMEを置くことはできません。Cloud DNSでも同様で、頂点をロードバランサーに向けたい場合はCNAMEではなく、予約した静的な外部IPアドレスを指すA/AAAAレコードを登録するのが基本的な回避方法です。なおCNAME自体は限定公開（プライベート）ゾーンでも通常どおり利用でき、1ゾーンあたり1つしか作成できないといった制限もありません。

正解: A. A. 異なるメトロポリタンエリアにある2つ以上のColocation施設から、それぞれ異なるエッジ可用性ドメインに接続する冗長構成を組む

正解の根拠・詳細解説

99.99%のSLAを実現するには、異なるメトロエリアの複数Colocation施設から、Googleの異なるエッジ可用性ドメインへの冗長な接続を構成する必要があります。単一施設・単一リンクでは99.9%程度のSLAにとどまります。

正解: A. A. レイヤ2タイプは顧客側でBGPピアリングをGoogleと直接構成し、レイヤ3タイプはパートナーがBGPピアリングを管理し顧客はパートナーのネットワークサービスとして接続する

正解の根拠・詳細解説

レイヤ2 Partner Interconnectでは顧客自身がCloud Router経由でGoogleと直接BGPピアリングを構成しますが、レイヤ3タイプではパートナーがBGPピアリングや一部のルーティングを管理し、顧客はマネージドサービスとして接続を利用します。

正解: A. A. 2つのインターフェースを持つHA VPNゲートウェイを使い、ピア側も冗長な2つのトンネルで接続する構成

正解の根拠・詳細解説

HA VPN（高可用性VPN）は2つの外部IPインターフェースを持つゲートウェイを使用し、オンプレミス側も冗長な構成で複数トンネルを確立することで、99.99%の可用性SLAを実現します。

正解: A. A. Classic VPNは可用性SLAが提供されず単一の外部IPに依存するが、HA VPNは2つの外部IPで冗長化され99.99%のSLAが提供される

正解の根拠・詳細解説

Classic VPN（従来のVPN）は単一の外部IPアドレスに依存し可用性SLAが提供されませんが、HA VPNは冗長な2つの外部IPインターフェースを持つゲートウェイ構成により99.99%のSLAを提供します。新規構成ではHA VPNが推奨されます。

正解: A. A. 複数の出口経路がある場合に、どの経路が優先されるかをルーターに伝えるための指標として使用する

正解の根拠・詳細解説

MED（Multi-Exit Discriminator）はBGPの属性で、同じASからの複数の経路がある場合にどの経路を優先すべきかを示す指標として機能し、値が小さいほど優先されます（デフォルト設定の場合）。

正解: A. A. BGPピアの障害をBGPのタイマーよりも高速に検出し、フェイルオーバー時間を短縮する

正解の根拠・詳細解説

BFD（双方向フォワーディング検出）はリンクやピアの障害を従来のBGPホールドタイマーよりはるかに高速（ミリ秒単位）に検出するプロトコルで、Cloud Routerと組み合わせることでフェイルオーバー時間を大幅に短縮できます。

正解: A. A. VPC内のサブネットルート以外に、特定の追加CIDR範囲（オンプレミスとの中継用範囲など）をオンプレミス側にBGP広告したい場合

正解の根拠・詳細解説

デフォルトではCloud RouterはVPCのサブネットルートのみをBGPで広告しますが、カスタムアドバタイズルートを設定することで、追加のCIDR範囲（中継用ネットワークなど）も明示的にオンプレミス側へ広告できます。

正解: A. A. オンプレミス側のVPNゲートウェイがIKEv1またはIKEv2をサポートし、Cloud Router経由のBGPによる動的ルーティングに対応していることが推奨される

正解の根拠・詳細解説

HA VPNはIKEv1/IKEv2を使用したIPsecトンネルを確立し、Cloud RouterによるBGP動的ルーティングと組み合わせることで、ルート管理の自動化と高可用性を実現します。オンプレミス側のVPNゲートウェイもこれらの機能をサポートする必要があります。

正解: A. A. VPCピアリングが使えない、または異なる組織が管理する2つのVPC間でセキュアな暗号化接続が必要な場合

正解の根拠・詳細解説

VPCピアリングでは推移的なルーティングができない、または組織やセキュリティ境界が異なるため暗号化された専用の接続が必要な2つのVPC間の通信には、HA VPNによるVPC間接続が有効な選択肢です。

正解: A. A. ポリシーベースはトラフィックセレクタ（IPレンジの組み合わせ）でトンネルを通すトラフィックを定義し、ルートベースはルーティングテーブルのルートに基づいて転送する

正解の根拠・詳細解説

ポリシーベースVPNはローカルとリモートのIPレンジの組み合わせ（トラフィックセレクタ）によってトンネルに送るトラフィックを定義し、ルートベースVPNはルーティングテーブルの設定に基づいて転送先を決定するという違いがあります。

正解: A. A. サードパーティのルーターやSD-WANアプライアンスをVMとして実行し、NCCハブ経由でハイブリッドスポークとして他のスポークと接続させる

正解の根拠・詳細解説

ルーターアプライアンス（RA）はサードパーティのルーティングソフトウェアをVM上で実行し、NCCのハイブリッドスポークとして他のVPCやオンプレミス拠点との接続性を提供する仕組みです。

正解: A. A. 各スポークのルートエクスポート・インポート設定と、ハブのトポロジ構成が意図した通りにルートを伝播しているかを確認する

正解の根拠・詳細解説

トランジットネットワークの問題（ルートの非対称性やルートがどこにも届かないブラックホール化）は、多くの場合スポークのルートエクスポート・インポート設定の誤りやハブのトポロジ構成の不整合が原因であるため、これらを系統的に確認する必要があります。

正解: A. A. Interconnect経由のプライベートな帯域幅を利用しながら、HA VPNによる暗号化を追加してセキュリティを強化できる

正解の根拠・詳細解説

Cloud Interconnect上でHA VPNを構成することで、専用線のプライベートな帯域幅・低レイテンシのメリットを享受しながら、IPsecによる暗号化を追加し、機密性の高いトラフィックにも対応できます。

正解: A. A. 接続先クラウドプロバイダーのリージョンとGoogle Cloudのリージョンのペアリング、および必要な帯域幅単位（10Gbpsまたは100Gbps）を計画する

正解の根拠・詳細解説

Cross-Cloud Interconnectでは、接続したい他クラウドプロバイダーのリージョンとGoogle Cloudリージョンの対応関係、および10Gbpsまたは100Gbps単位の帯域幅を踏まえてVLANアタッチメントを計画する必要があります。

正解: A. A. 専用線（Interconnect）が利用可能で大容量・低レイテンシが必要ならVLANアタッチメント、専用線が未整備または迅速な構築が必要ならVPNを選択する

正解の根拠・詳細解説

Cloud InterconnectのVLANアタッチメントは大容量・低レイテンシの専用線が利用可能な場合に適しており、専用線の構築に時間がかかる場合や迅速な接続が必要な場合はHA VPNが現実的な選択肢になります。

正解: A. A. Verified Peering Providerはパートナーのネットワークを経由するためGoogleとの直接物理接続契約を結ぶ規模に達しない企業でも利用しやすいが、Dedicated Interconnectより制御の自由度はやや制限される

正解の根拠・詳細解説

Verified Peering Providerは認定されたパートナーのネットワークを経由した接続のため、Dedicated Interconnectのような直接の物理接続契約を結ぶ規模に達しない企業でも利用しやすい一方、構成の自由度や帯域幅の選択肢はDedicated Interconnectよりやや制限される場合があります。

正解: A. A. レイヤ2のEthernetフレームレベルで暗号化を行い、Dedicated Interconnect上のトラフィックの機密性を保護する

正解の根拠・詳細解説

MACsec（IEEE 802.1AE）はイーサネットのレイヤ2でフレームを暗号化する技術で、Cloud InterconnectではDedicated Interconnectの接続に対して有効化できます。オンプレミス側のルーターとGoogleのエッジ機器との間でMKAによって鍵を交換し、専用線区間を流れるフレームの機密性と完全性、なりすまし防止を確保します。ここで押さえておきたいのは、保護されるのがあくまで物理的な接続区間であり、コロケーション施設内での盗聴や光ファイバーへの物理的な侵入といった脅威に対する対策だという点です。したがってHA VPNが提供するレイヤ3のIPsec暗号化を置き換えるものではなく、両者は保護する層も区間も異なります。また暗号化がGoogleのエッジで終端されるため、エンドツーエンドの機密性が必要であればアプリケーション層のTLSなど上位レイヤの暗号化を併用します。DNSクエリの暗号化やCDNのキャッシュとは無関係の機能です。

正解: A. A. VM間のネットワークフローのメタデータ（送信元・宛先・ポート・バイト数等）をサンプリング記録し、トラフィック分析やセキュリティ調査に利用する

正解の根拠・詳細解説

VPCフローログは、VM間で発生する通信のメタデータ（5タプル情報、送受信バイト数、開始・終了時刻など）をサンプリングして記録する機能で、ペイロード自体は記録しません。トラフィック分析やセキュリティインシデント調査に活用します。

正解: A. A. ASN設定の不一致、ファイアウォールルールによるBGP（TCP179）のブロック、インターフェースIPアドレスの誤りなど

正解の根拠・詳細解説

BGPピアリングが確立しない場合、まずASNの設定不一致、BGP通信（TCP179）をブロックするファイアウォールルール、インターフェースIPアドレスの誤りなど、基本的な設定項目を順に確認することが効果的なトラブルシューティングの第一歩です。

正解: A. A. 送信元と宛先間の通信経路をシミュレーションし、ルートやファイアウォールルールの設定ミスによる到達不可能性を診断する

正解の根拠・詳細解説

接続テストは実際のトラフィックを送信せずに、構成情報（ルート、ファイアウォールルール、ロードバランサ設定等）を解析して、指定した送信元から宛先への通信が到達可能かどうか、どこでブロックされる可能性があるかを静的に診断します。

正解: A. A. 不要な、または意図しない設定ミスによるファイアウォールルールの整理・最適化を行い、セキュリティポリシーの整合性を保つ

正解の根拠・詳細解説

シャドウルールは優先度の高い別ルールによって常にオーバーライドされ実質的に評価されないルールです。これを特定することで、不要なルールの削除や、意図した通りに機能していない設定ミスの発見につながり、ファイアウォールポリシー全体の整合性向上に役立ちます。

正解: A. A. 問題が自社のプロジェクト内のネットワーク構成に起因するのか、Googleのバックボーンネットワーク全体の問題なのかを切り分けるため

正解の根拠・詳細解説

パフォーマンスダッシュボードでGoogle全体のネットワーク状況と自社プロジェクトのネットワーク状況を比較することで、問題が自社の構成（ルーティングやファイアウォール等）に起因するのか、Google側の広域なネットワーク事象に起因するのかを切り分けられます。

正解: A. A. コネクションドレイン（connection draining）のタイムアウトを設定し、既存接続を完了させながら新規トラフィックを段階的に他のバックエンドへ移行する

正解の根拠・詳細解説

コネクションドレインを設定することで、メンテナンス対象のバックエンドインスタンスへの新規リクエストの送信を停止しつつ、既存の接続は指定したタイムアウト時間内で正常に完了させ、サービス影響を最小化したトラフィックの移行が可能です。

正解: A. A. 実際のVMトラフィックのコピーを収集ツール（IDS等）に転送し、本番トラフィックに影響を与えずにパケットレベルでの詳細な分析が可能になる

正解の根拠・詳細解説

Packet Mirroringは指定したVMインスタンスのトラフィックをそのままコピーし、別の収集先（IDSや分析ツールなど）に転送する機能で、本番環境のトラフィローには影響を与えずにパケットレベルの詳細な調査が可能です。

正解: A. A. 最適でないMTU設定、未使用のファイアウォールルール、IP範囲の使用率の偏りなど一般的な構成上の問題

正解の根拠・詳細解説

ネットワークアナライザはVPC構成を継続的にスキャンし、最適でないMTU設定、利用率の低いファイアウォールルール、IPアドレス使用率の偏りといった一般的な構成上の問題を自動的に検出し、洞察（insight）として提示します。

正解: A. A. トラフィックの集約傾向（トップトーカー、リージョン間トラフィック量等）を可視化し、コスト最適化やキャパシティプランニングに活用する

正解の根拠・詳細解説

Flow AnalyzerはVPCフローログのデータを集約・可視化し、トラフィック量の多い通信先（トップトーカー）やリージョン間転送量などのパターンを分析できるため、ネットワークコストの最適化やキャパシティプランニングに有用です。

正解: A. A. トンネルのステータスとログを確認し、IKEのフェーズ1/フェーズ2のネゴシエーション失敗、共有鍵の不一致、ピアIPアドレスの誤りなどを順に確認する

正解の根拠・詳細解説

VPNトンネルダウンのトラブルシューティングでは、Cloud Loggingのトンネルログでネゴシエーションの失敗箇所（IKEフェーズ1/2）、事前共有鍵の不一致、ピアゲートウェイのIPアドレス設定誤りなどを系統的に確認していくのが基本です。

正解: A. A. Interconnectの診断情報（LOAステータス、リンク状態）とパフォーマンスダッシュボードのメトリクスを確認し、必要に応じてGoogleサポートに物理層の調査を依頼する

正解の根拠・詳細解説

Interconnectで物理層に起因する可能性のある問題は、Google Cloudコンソールの診断情報やパフォーマンスダッシュボードのメトリクスでまず傾向を確認し、ソフトウェア設定に問題がなければGoogleサポート経由で物理リンクの状態調査を依頼する流れになります。

正解: A. A. NAT変換の成功・エラー（ポート割り当て失敗等）のログ記録を有効化し、ポート枯渇などの問題を早期検出する

正解の根拠・詳細解説

Cloud NATのログ機能を有効化すると、NAT変換の成功イベントだけでなく、エフェメラルポートの枯渇によるアロケーション失敗などのエラーイベントも記録され、容量不足の早期検出に役立ちます。

正解: A. A. VPC・サブネット・ロードバランサ間の論理的な接続関係とトラフィック量をグラフィカルに把握し、ボトルネックの特定に役立てる

正解の根拠・詳細解説

Network Intelligence Centerのネットワークトポロジ機能は、VPC・サブネット・ロードバランサ・Interconnect等の論理的な接続関係とトラフィックのメトリクスをグラフィカルに表示し、ネットワーク全体の構成把握とボトルネック特定を支援します。

正解: A. A. オンプレミス側のルートアドバタイズ設定とCloud Router側のルートインポート上限・フィルタ設定を確認する

正解の根拠・詳細解説

学習ルート数が想定より少ない場合、オンプレミス側でアドバタイズされているルートの範囲や、Cloud Router側で設定されているルートのインポート上限・カスタムフィルタの設定を確認することで、原因を特定できます。

正解: A. A. ファイアウォールログでどのルールによりトラフィックが許可/拒否されたかを確認し、VPCフローログで実際の通信フローの詳細（バイト数等）を補完的に分析できる

正解の根拠・詳細解説

ファイアウォールルールのログとVPCフローログは、記録する観点が異なるため補完関係にあります。ファイアウォールルールのログは、ログを有効にしたルールについて、接続がどのルールに一致して許可または拒否されたかを、送信元・宛先・ポート・プロトコル・方向とあわせて記録します。つまり通信が通ったのか、どのルールで止まったのかという判定の根拠が分かります。一方VPCフローログは、VMのネットワークインタフェースを通過したフローをサンプリングして記録し、送受信バイト数やパケット数、往復遅延といった実際の通信量や品質に関する情報を提供します。片方だけでは、拒否ログがないのに通信できない場合の切り分けや、許可されているのに遅いといった問題の原因追跡が難しく、両者を突き合わせることで、ルールで落ちているのか、そもそもパケットが届いていないのか、経路や帯域の問題なのかを判断できます。なおどちらもパケットのペイロードそのものは記録しません。

正解: A. A. エッジセキュリティポリシーはCDNキャッシュヒット時にも評価される、より早い段階（エッジ）でのフィルタリングを行い、バックエンドセキュリティポリシーはオリジンサーバーに到達する前に評価される

正解の根拠・詳細解説

エッジセキュリティポリシーはCloud CDNのキャッシュヒットも含むエッジでの早期フィルタリングに使われ、バックエンドセキュリティポリシーはキャッシュミス時にオリジンへ到達する前のリクエストを評価します。両者を組み合わせて多層防御を構成できます。

正解: A. A. 事前定義されたOWASP CRSベースのWAFルール（sqli関連）をセキュリティポリシーにルールとして追加する

正解の根拠・詳細解説

Cloud ArmorはOWASP ModSecurity Core Rule Set（CRS）をベースにした事前定義のWAFルール（SQLインジェクション、XSS、RFIなど）を提供しており、これをセキュリティポリシーのルールとして追加するだけで一般的な攻撃パターンを防御できます。

正解: A. A. 機械学習を用いてアプリケーション層DDoS攻撃のパターンを検出し、攻撃シグネチャに基づいたルールを自動的に提案・適用する

正解の根拠・詳細解説

Adaptive Protectionは機械学習でアプリケーション層のDDoS攻撃の異常なトラフィックパターンをリアルタイムに検出し、攻撃を緩和するためのCloud Armorルールを自動的に生成・提案する機能です。

正解: A. A. 特定の送信元からの単位時間あたりのリクエスト数を制限し、ブルートフォース攻撃やスクレイピングを緩和する

正解の根拠・詳細解説

Cloud Armorのレート制限は、指定したキー（IPアドレスなど）ごとに単位時間あたりのリクエスト数の閾値を設定し、超過した場合にリクエストを拒否またはスロットルすることで、ブルートフォース攻撃やスクレイピングなどの過剰なアクセスを緩和します。

正解: A. A. Enterpriseティアでのみレイヤ7のパケット検査（侵入防止機能含む）が利用可能で、Essentialsは基本的なファイアウォール機能のみを提供する

正解の根拠・詳細解説

Cloud NGFWはEssentials（基本機能）、Standard（中間機能）、Enterprise（レイヤ7パケット検査や侵入防止などの高度な機能）という段階的なティア構成になっており、要件に応じて選択します。

正解: A. A. 既存のVPCファイアウォールルールの優先度・条件を整理し、リージョン/グローバル/階層型ポリシーのどのレベルで同等のルールを再構成するかを計画する

正解の根拠・詳細解説

VPCファイアウォールルールからCloud NGFWへの移行では、既存ルールの優先度や適用範囲を整理し、組織ポリシーとして階層型で管理するか、VPC単位のリージョン/グローバルポリシーとして管理するかを計画的に設計する必要があります。

正解: A. A. 組織全体で一貫したセキュリティベースラインルールを強制し、個々のプロジェクトのVPCファイアウォールルールより優先して評価できる

正解の根拠・詳細解説

階層型ファイアウォールポリシーを組織やフォルダレベルで構成することで、配下の全プロジェクトに一貫したセキュリティベースラインルールを強制でき、個別プロジェクトのVPCファイアウォールルールより優先して評価させることが可能です。

正解: A. A. IPアドレスに依存せず、ワークロードのID（タグやサービスアカウント）に基づいてファイアウォールルールを適用できるため、動的にスケールする環境でもポリシーの整合性を保てる

正解の根拠・詳細解説

セキュアタグやサービスアカウントに基づくファイアウォールルールは、インスタンスのIPアドレスが動的に変化する環境（自動スケーリング等）でも、ワークロードのID属性に基づいて一貫したマイクロセグメンテーションを維持できる点が利点です。

正解: A. A. 静的割り当てはVMごとに固定数のポートを事前に割り当て、動的割り当てはトラフィック量に応じてポート数を自動的に増減させる

正解の根拠・詳細解説

Cloud NATの静的ポート割り当てはVMインスタンスごとに固定のポート数を割り当てますが、動的ポート割り当ては実際のトラフィック需要に応じてポート数を最小値と最大値の範囲内で自動的に調整します。

正解: A. A. VM等のワークロードからインターネットへの送信（下り）トラフィックをURLベースでフィルタリングし、許可されたドメインのみへのアクセスを制御する

正解の根拠・詳細解説

Secure Web Proxyは、VPC内のワークロードが発信するインターネットへの下りHTTP(S)トラフィックをURL/ドメインベースでフィルタリングし、ポリシーで許可されたサイトのみへのアクセスを許可するセキュアウェブゲートウェイ機能です。

正解: A. A. 複数のアプライアンスインスタンスを内部ロードバランサの背後に配置し、ネクストホップとして指定する

正解の根拠・詳細解説

マルチNIC VMのファイアウォールアプライアンスを複数台用意し、内部ロードバランサの背後に配置してカスタムルートのネクストホップとして指定することで、単一障害点を排除した高可用性のトラフィック検査構成を実現できます。

正解: A. A. トラフィックのコピーをセキュリティアプライアンスに転送して検査するため、実際の通信パスに直接介在せずレイテンシへの影響が少ない

正解の根拠・詳細解説

アウトオブバンド方式のNSIは、Packet Mirroring等を用いてトラフィックのコピーをセキュリティアプライアンスに送って検査するため、実際の通信パスには介在せず、インライン方式と比べてレイテンシへの影響を抑えられます。

正解: A. A. VPC内のトラフィックをミラーリングし、既知の脅威シグネチャや異常な振る舞いを検出してアラートを生成する

正解の根拠・詳細解説

Cloud IDSはPalo Alto Networksの脅威検出技術をベースに、ミラーリングされたVPCトラフィックを分析し、既知の脅威シグネチャやマルウェア、エクスプロイトなどの不審な挙動を検出してセキュリティチームにアラートを提供します。

正解: A. A. L3/L4レベルの基本的なアクセス制御はVPCファイアウォールルールで行い、L7レベルの高度な検査が必要な場合はNVAやCloud NGFW Enterpriseを組み合わせる

正解の根拠・詳細解説

VPCファイアウォールルールはL3/L4レベルの基本的なアクセス制御に適していますが、アプリケーション層の詳細な検査（マルウェア検出、URL分類など）が必要な場合は、Cloud NGFW EnterpriseやNVAを組み合わせた多層的なファイアウォール戦略が有効です。

正解: A. A. 既知の悪意あるIPアドレスやTor出口ノードなど脅威情報フィードに基づいてリクエストを自動的に評価・ブロックする

正解の根拠・詳細解説

Cloud ArmorにGoogle Threat Intelligenceの脅威情報フィード（既知の悪性IP、Tor出口ノード、検出された脆弱性スキャナー等）を適用することで、これらの脅威源からのリクエストをルールベースで自動的に評価・ブロックできます。

正解: A. A. reCAPTCHA Enterpriseと連携してトラフィックがbotか人間かを評価し、悪意あるbotトラフィックをブロックまたはチャレンジする

正解の根拠・詳細解説

Cloud Armorのbot管理は、reCAPTCHA Enterpriseと連携して、外部HTTP(S)ロードバランサに到達したリクエストが人間の操作によるものか自動化されたbotによるものかを評価する仕組みである。reCAPTCHA側が発行するトークンにはリスクスコアが含まれ、Cloud Armorのセキュリティポリシーではこのスコアをルールの条件として参照できる。これにより、botらしさが強くスコアの低いリクエストは拒否し、判断がつかない中間帯はreCAPTCHAのチャレンジページへ誘導して人間かどうかを確かめ、スコアの高いものはそのまま通す、といった段階的な制御が可能になる。送信元IPアドレスによる一律の遮断や単純なレート制限と違い、正規の利用者を巻き込みにくく、IPを次々に変えながらアクセスしてくるスクレイピングやクレデンシャルスタッフィングにも対応しやすい点が利点である。またスコアに基づく判定であるため、検索エンジンのクローラーのように通したいbotまで一律に遮断してしまうわけではない。DNSレコードの自動更新やCloud NATの構成とは無関係の機能である。