模擬問題集一覧

GCP-PCNE 模擬問題集(練習問題)

Professional Cloud Network Engineer 合格に向けた本番形式の模擬問題集。すべての問題に詳しい解説と、ドメイン別の弱点分析つき。

4 練習テスト 200 問 合格ライン 70% 各 120 分

この模擬問題集で身につくこと

  • 本番と同じ形式・難易度の問題で実力を確認
  • 制限時間つきの試験モードで時間配分を体得
  • 演習モードで1問ずつ解説を読みながら学習
  • すべての問題に正解の根拠つきの詳しい解説
  • ドメイン別スコアで弱点分野をひと目で把握
  • 完了後も何度でも復習して本番前に仕上げ

練習テストの内容

4 テスト · 全 200 問
1
模擬問題集①先頭 15 問 無料
50 問 120 分 合格 70%
2
模擬問題集② プラン限定
50 問 120 分 合格 70%
3
模擬問題集③ プラン限定
50 問 120 分 合格 70%
4
模擬問題集④ プラン限定
50 問 120 分 合格 70%

説明

GCP-PCNE(Professional Cloud Network Engineer)の合格に向けた、本番形式の模擬問題集です。全 200 問を4 回の練習テストに分割し、 試験モード/演習モードで受験できます。各問題には正解の根拠と誤答の理由を記した詳しい解説が付き、受験後はドメイン別のスコアで弱点を把握できます。 各試験は先頭の問題から無料でお試しいただけます。

月額 ¥980 で全 200 問+全解説が受け放題

模試プラン(¥980/月)なら、ロックされた練習テストと詳しい解説、ドメイン別の弱点分析がすべて使い放題。本番に向けて実力を仕上げましょう。

GCP-PCNE の出題範囲(カバーしている分野)

全 200 問を、本番の試験ガイドに沿った次の分野から出題しています。 受験後はドメイン別の正答率が表示され、弱点が特定できます。 難易度・学習時間・合格までの進め方はGCP-PCNE の学習ガイドにまとめています。

GCP-PCNE の無料練習問題(15 問・解説つき)

会員登録なしで、全 200 問のうち 15 問を正解と解説つきでご覧いただけます。 問題をクリックすると選択肢と解説が開きます。

問題 1これらの要件を満たし、冗長性も提供する暗号化戦略を決定する必要があります。Google Cloud VPC ネットワークの設計と計画
問題
金融サービス企業のために、オンプレミス データセンターと Google Cloud の間に、可用性が高く安全な接続を設計しています。この企業は 10 Gbps の帯域幅を必要としており、オンプレミス ネットワークと Google Cloud の VPC の間のすべてのトラフィックをエンドツーエンドで暗号化することを義務付けています。すでに 10 Gbps の Dedicated Interconnect 接続を 2 本プロビジョニング済みです。これらの要件を満たし、冗長性も提供する暗号化戦略を決定する必要があります。どうすればよいですか。

選択肢と解説

  • ✓
    各 Dedicated Interconnect 接続に 4 つの HA VPN ゲートウェイをデプロイする。
  • 2
    各 Dedicated Interconnect 接続に 2 つの HA VPN ゲートウェイをデプロイする。
  • 3
    各 Dedicated Interconnect 接続で MACsec を構成する。
  • 4
    1 本の Dedicated Interconnect をトラフィックに使い、インターネット経由の HA VPN をバックアップに使う。

解説

【正解】A

【0からの解説】
①前提知識
・Dedicated Interconnect は、オンプレミスのルーターと Google のピアリング エッジを物理回線で直結するサービスです。回線そのものは閉域ですが、既定ではトラフィックは暗号化されていません。
・Cloud Interconnect の暗号化の方法は主に 2 つあります。
 (1) MACsec for Cloud Interconnect:レイヤ 2 の暗号化。暗号化される区間は「オンプレミスのルーター ⇔ Google のピアリング エッジ ルーター」の 1 ホップだけです。公式ドキュメントにも、MACsec は Google 内部での転送中の暗号化は提供しないため、エンドツーエンドが必要なら IPsec や TLS を重ねるよう書かれています。
 (2) HA VPN over Cloud Interconnect(Cloud Interconnect を介した HA VPN):VLAN アタッチメントの上に HA VPN の IPsec トンネルを張る方式。暗号化区間は「オンプレミスの VPN ゲートウェイ ⇔ VPC の HA VPN ゲートウェイ」で、オンプレミスと VPC の間をエンドツーエンドで暗号化できます。
・HA VPN トンネル 1 本の帯域は最大 3 Gbps(さらに 1 トンネルあたり 250,000 pps の上限)です。そのため大きな帯域を暗号化するには複数のトンネル(=複数の HA VPN ゲートウェイ/インターフェース)を並べる必要があります。
・公式の構成ガイドでは、VLAN アタッチメント容量ごとの必要トンネル数の目安として「10 Gbps → VLAN アタッチメントあたり 4 トンネル、冗長用の 2 アタッチメントで合計 8 トンネル」と示されています。HA VPN ゲートウェイのインターフェース 0 を 1 本目のアタッチメント(エッジ可用性ドメイン 1)、インターフェース 1 を 2 本目のアタッチメント(エッジ可用性ドメイン 2)に対応付けるので、4 つの HA VPN ゲートウェイを使えば、各 Interconnect 上に 4 本ずつ、合計 8 本のトンネルができます。

②要件と制約語の整理
・帯域 10 Gbps が必要
・「オンプレミス ネットワークと VPC の間」を「エンドツーエンドで」暗号化
・冗長性(片方の Interconnect が落ちても 10 Gbps を維持したい)

③正解の理由(検算)
・10 Gbps ÷ 3 Gbps/トンネル ≒ 3.4 → 1 本の Interconnect あたり 4 トンネル(4 × 3 = 12 Gbps ≥ 10 Gbps)が必要。
・片方の Interconnect が障害になっても残り 1 本の上の 4 トンネルで 10 Gbps を運べるよう、両方の Interconnect にそれぞれ 4 トンネル(合計 8 トンネル)を用意する。これが公式表の「10 Gbps:4 / 8」に一致します。
・よって「各 Interconnect 上に 4 つの HA VPN ゲートウェイ(のトンネル)」を配置する A が、エンドツーエンド暗号化・10 Gbps・冗長性をすべて満たします。
【単位の違いに注意】公式表の「4 / 8」は HA VPN「トンネル」の本数(VLAN アタッチメント 1 つあたり 4 本、冗長用の 2 アタッチメント合計で 8 本)であり、HA VPN「ゲートウェイ」の数ではありません。一方、選択肢はゲートウェイの数で書かれています。両者は次の関係で結び付きます。
 ・HA VPN ゲートウェイ 1 つはインターフェースを 2 つ持ち、インターフェース 0 を 1 本目のアタッチメント、インターフェース 1 を 2 本目のアタッチメントに対応付けて、インターフェースごとにトンネルを 1 本作ります。つまりゲートウェイ 1 つで「各アタッチメントに 1 本ずつ」トンネルが増えます。
 ・したがって「アタッチメントあたりのトンネル数 = HA VPN ゲートウェイの数」になります。実際に Google Cloud コンソールのウィザードも、VLAN アタッチメントの容量に応じてこの数の HA VPN ゲートウェイを自動作成します(例:5 Gbps のアタッチメントならゲートウェイ 2 つ)。
 ・10 Gbps では、アタッチメントあたり 4 トンネルが必要なので、HA VPN ゲートウェイは 4 つです。選択肢 A の「各 Dedicated Interconnect 接続に 4 つの HA VPN ゲートウェイ」は、「4 つのゲートウェイが各 Interconnect 上(のアタッチメント)にそれぞれ 1 本ずつトンネルを持ち、各 Interconnect 上に 4 トンネルずつ、合計 8 トンネルになる」構成を表したものと読み取ってください(Interconnect ごとに別々のゲートウェイを 4 つずつ、計 8 つ作るという意味ではありません)。
 ・逆に、表の「8」をゲートウェイの総数、または「4」を 2 本の Interconnect で分け合うゲートウェイの総数と読み違えると「各接続に 2 つ」の B が正しく見えてしまいます。しかしゲートウェイ 2 つでは各アタッチメントのトンネルが 2 本(表の 5 Gbps の行に相当)にしかならず、10 Gbps には足りません。

【誤りの選択肢】
B:HA VPN ゲートウェイが 2 つだと、上記のとおり各 Interconnect 上のトンネルは 2 本(2 × 3 Gbps = 6 Gbps)にとどまり、10 Gbps の帯域要件を満たせません。公式表のトンネル数(4 / 8)をゲートウェイ数と取り違えると選びやすい誤答です。両方の Interconnect が正常なときでも合計 12 Gbps ですが、冗長性(片側障害時に 10 Gbps を維持)を満たせないうえ、公式の推奨トンネル数(10 Gbps ではアタッチメントあたり 4 本)にも届きません。
C:MACsec は回線速度で暗号化でき性能面では魅力的ですが、暗号化されるのはオンプレミスのルーターと Google のピアリング エッジ ルーターの間だけで、Google 内部から VPC までは暗号化されません。「オンプレミスと VPC の間のエンドツーエンド暗号化」という要件を満たしません。
D:Interconnect を 1 本しかトラフィックに使わないため、そのトラフィックは暗号化されず要件を満たしません。またインターネット経由の HA VPN は帯域が小さく、すでに用意した 2 本目の Interconnect も無駄になります。

【参考】
Cloud Interconnect を介した HA VPN の概要
Cloud VPN の概要
この問題のページを開く →
問題 2また、トラフィックがインターネットを経由しないようにする必要があります。VPC ネットワークの実装
問題
あなたは、クライアントが特定の Google API に接続できるように、組織のアーキテクチャを設計しています。計画には Cloud Storage と BigQuery に接続する方法を含める必要があります。また、トラフィックがインターネットを経由しないようにする必要があります。ソリューションはクラウドファーストで、構成手順が最も少ないものにしたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    VPC リソースで限定公開の Google アクセスを構成する。インターネットへのデフォルト ルートを作成する。
  • ✓
    サブネット リソースで限定公開の Google アクセスを構成する。インターネットへのデフォルト ルートを作成する。
  • 3
    Cloud NAT を構成し、インターネットへのデフォルト ルートを削除する。
  • 4
    グローバル Secure Web Proxy を構成し、インターネットへのデフォルト ルートを削除する。

解説

【正解】B

【0からの解説】
①前提知識:限定公開の Google アクセス(Private Google Access)は、外部 IP アドレスを持たない VM が、Cloud Storage や BigQuery などの Google API・サービスの外部 IP アドレスに到達できるようにする機能です。この機能は VPC 全体ではなく「サブネット単位」で有効にします。トラフィックは VPC から Google のネットワーク内で直接 Google API に届き、インターネットには出ません。
ただし、Google API の既定のドメイン(*.googleapis.com)や private.googleapis.com の IP アドレスへ届くには、そのアドレスへ向かうルートが必要です。通常はネクストホップが「デフォルト インターネット ゲートウェイ」のデフォルト ルート(0.0.0.0/0)を使います。名前は「インターネット ゲートウェイ」ですが、Google API 宛てのパケットは Google のネットワーク内にとどまり、外部 IP を持たない VM はインターネット上の他の宛先には出られません。

②要件の整理:Cloud Storage と BigQuery に接続すること、インターネットを経由しないこと、クラウドファーストで構成手順が最も少ないこと。
本問で見分けるべき点は 2 つです。(1) 限定公開の Google アクセスを「どの単位で」有効にするか(VPC かサブネットか)、(2) 「インターネットを経由しない」という言葉につられてデフォルト ルートを削除してよいか、です。どちらも誤解されやすいポイントで、選択肢はこの 2 点の組み合わせで作られています。

③正解の根拠:サブネットで限定公開の Google アクセスを有効にし、デフォルト インターネット ゲートウェイへのデフォルト ルートを用意する(既定の VPC には最初から存在)だけで、Cloud Storage と BigQuery を含む Google API にインターネットを経由せず接続できます。設定はサブネットのチェック 1 つとルートの確認だけで、最も手順が少ない構成です。より厳格にしたい場合は、private.googleapis.com(199.36.153.8/30)や restricted.googleapis.com 向けのルートと DNS を構成する方法もあります。

【誤りの選択肢】
A:限定公開の Google アクセスは VPC リソース全体の設定ではなく、サブネットごとに有効にする設定です。VPC 単位で構成するという前提が誤っています。
C:Cloud NAT は外部 IP を持たない VM がインターネットへ出るための送信元 NAT であり、Google API へのアクセスを「インターネットを経由させない」ための仕組みではありません。さらに、Cloud NAT はデフォルト インターネット ゲートウェイへのルートを必要とするため、デフォルト ルートを削除すると Cloud NAT 経由の通信も Google API への到達もできなくなります。
D:Secure Web Proxy は下り(外向き)ウェブ トラフィックを URL やホスト名で制御するプロキシで、Google API への私設接続の手段ではありません。プロキシのデプロイ・ポリシー・クライアント設定などが必要で、「構成手順が最も少ない」に反します。デフォルト ルートを削除すると Google API へのルートもなくなります。

【参考】
プライベート Google アクセス | Virtual Private Cloud
限定公開の Google アクセスを構成する | Virtual Private Cloud
この問題のページを開く →
問題 3構成が実際のポート番号に依存せず、ベスト プラクティスに従うようにする必要があります。マネージド ネットワーク サービスの構成
問題
Google Kubernetes Engine(GKE)上のコンテナ化されたアプリケーション環境を管理しています。メインのエンドポイント用に名前付きポート http-api を定義した Kubernetes Service マニフェストを使って、マイクロサービスをデプロイしました。現在、このマイクロサービスを公開するために外部 HTTP(S) ロードバランサを構成しています。構成が実際のポート番号に依存せず、ベスト プラクティスに従うようにする必要があります。どうすればよいですか。

選択肢と解説

  • 1
    GKE ノードのインスタンス グループをバックエンドとして使用するバックエンド サービスを作成し、そのバックエンド サービスで名前付きポート http-api を構成する。
  • ✓
    Kubernetes Service 用に自動的に作成された GCE_VM_IP_PORT ネットワーク エンドポイント グループ(NEG)をバックエンド構成で参照し、トラフィックに名前付きポート http-api を指定する。
  • 3
    Kubernetes Service マニフェストにアノテーションを追加して GCE_VM_IP ネットワーク エンドポイント グループ(NEG)を作成し、バックエンド サービスがこの NEG を使用するように構成する。
  • 4
    Kubernetes Ingress マニフェストにアノテーションを追加して http-api のポート番号を直接指定し、バックエンド サービスがこのハードコードされたポート番号を使用するように構成する。

解説

【正解】B

【0からの解説】
①前提知識
・ネットワーク エンドポイント グループ(NEG)は、ロードバランサのバックエンドとして「IP アドレス(+ポート)」の集合を登録する仕組みです。ゾーン NEG には、エンドポイントが「IP:ポート」の GCE_VM_IP_PORT 型と、「IP のみ」の GCE_VM_IP 型があります。
・GKE のコンテナ ネイティブ負荷分散では、GCE_VM_IP_PORT 型の NEG に Pod の IP アドレスとポートを直接登録します。ロードバランサからノードを経由せず Pod に直接届くため、余分なホップ(kube-proxy による再転送)がなく、ヘルスチェックも Pod 単位で正確になります。VPC ネイティブ クラスタでは Ingress/Gateway が NEG を既定で使い、Service の cloud.google.com/neg アノテーションによって NEG が自動作成・自動更新されます。
・Kubernetes の Service では、targetPort に数値ではなく名前付きポート(例: http-api)を指定でき、実際のコンテナ ポート番号は Pod 側の定義から解決されます。NEG のエンドポイントは、この名前付きポートが解決された Pod の IP:ポートとして GKE コントローラが自動で登録・更新します。

②要件と制約語の整理
・外部 HTTP(S) ロードバランサ(現在の外部アプリケーション ロードバランサ)で公開する
・構成を実際のポート番号から独立させる(名前付きポートを使う)
・ベスト プラクティスに従う

③正解の理由
Service 用に自動作成された GCE_VM_IP_PORT NEG をバックエンドとして参照し、名前付きポート http-api を指定すれば、ポート番号が変わっても GKE が NEG のエンドポイントを自動で更新するため、ロードバランサ側の構成を変える必要がありません。Google が推奨するコンテナ ネイティブ負荷分散の形でもあります。

【誤りの選択肢】
A:インスタンス グループ(ノード)をバックエンドにする方式は、NodePort 経由でノードに届いた後に kube-proxy が Pod に再転送するため、余分なホップと不正確なヘルスチェックが生じます。インスタンス グループの名前付きポートはノード側のポート番号(NodePort)への対応付けであり、Kubernetes Service の名前付きポートとは別物です。コンテナ ネイティブ負荷分散が推奨される現在では、ベスト プラクティスに劣ります。
C:GCE_VM_IP 型の NEG はポートを持たない「IP のみ」のエンドポイントで、内部パススルー ネットワーク ロードバランサ(GKE のサブセット化)などのレイヤ 4 用です。外部 HTTP(S) ロードバランサのバックエンドには使えず、名前付きポートによる指定もできません。
D:ポート番号を直接ハードコードしており、「構成が実際のポート番号に依存しない」という要件に真っ向から反します。ポートが変わるたびにマニフェストとバックエンドの修正が必要になります。

【参考】
スタンドアロン NEG によるコンテナ ネイティブのロード バランシング | GKE networking
ゾーン ネットワーク エンドポイント グループの概要 | Cloud Load Balancing
アプリケーション ロードバランサ用の GKE Ingress | GKE networking
この問題のページを開く →
問題 4VPC 間の通信を可能にするため、この 2 つの VPC の間に安全で、プライベートで、暗号化された接続を確立する必要が…ハイブリッド/マルチクラウド ネットワーク相互接続の構成と実装
問題
あなたの組織では、2 つのアプリケーションが別々のプロジェクトにある別々の Google Cloud VPC ネットワーク(vpc-a と vpc-b)で実行されています。VPC 間の通信を可能にするため、この 2 つの VPC の間に安全で、プライベートで、暗号化された接続を確立する必要があります。このソリューションは高可用性を備え、動的ルーティングを使用するものでなければなりません。どうすればよいですか。

選択肢と解説

  • 1
    2 つのネットワーク間に VPC ネットワーク ピアリングを構成し、特定のサブネット間で必要なトラフィックが流れるよう両側のファイアウォール ルールを調整する。
  • 2
    vpc-a にアプリケーション用の内部アプリケーション ロードバランサをデプロイする。Private Service Connect を使用してこのサービスを vpc-a で公開し、vpc-b に PSC コンシューマー エンドポイントを作成する。
  • 3
    各 VPC に Classic VPN ゲートウェイをデプロイし、認証に事前共有鍵を使用する。もう一方の VPC へトラフィックを転送する静的ルートを構成する。
  • ✓
    各 VPC に HA VPN ゲートウェイと Cloud Router をデプロイする。各ゲートウェイに 2 本の VPN トンネルを作成し、動的ルーティング用に BGP セッションを構成する。

解説

【正解】D

【0からの解説】
①前提知識
・HA VPN は、2 つのインターフェース(2 つの外部 IP)を持つ高可用性の Cloud VPN ゲートウェイです。2 本のトンネルを正しく構成すると 99.99% の SLA が適用されます。HA VPN は Cloud Router による BGP(動的ルーティング)が必須で、IPsec によって通信を暗号化します。Google Cloud の VPC 同士(別プロジェクトでも可)を HA VPN で接続するトポロジも公式にサポートされています。
・Cloud Router は BGP でルートを動的に交換するマネージド サービスで、サブネットの追加などが自動で相手側に反映されます。
・VPC ネットワーク ピアリングは、2 つの VPC を Google の内部ネットワークで直結してサブネット ルートを交換する機能です。低レイテンシで追加のゲートウェイも不要ですが、IPsec のような暗号化トンネルや BGP による動的ルーティングを構成するものではありません。

②要件と制約語の整理
・安全・プライベート・「暗号化された」接続
・高可用性
・「動的ルーティング」を使用

③正解の理由
各 VPC に HA VPN ゲートウェイと Cloud Router を置き、ゲートウェイの 2 つのインターフェースそれぞれにトンネルを張って(各ゲートウェイに 2 本)BGP セッションを構成すれば、IPsec による暗号化、99.99% SLA の高可用性、BGP による動的ルーティングの 3 条件をすべて満たします。

【誤りの選択肢】
A:VPC ネットワーク ピアリングはプライベートな接続ですが、明示的な暗号化トンネル(IPsec)も BGP による動的ルーティングも構成しないため、「暗号化」「動的ルーティング」という要件を明示的に満たしません。
B:Private Service Connect は、特定のサービスをコンシューマー側に公開する一方向のサービス公開の仕組みです。VPC 間の汎用的な相互通信を提供するものではなく、動的ルーティングも使いません。
C:Classic VPN はゲートウェイが 1 インターフェースで SLA は 99.9% にとどまり、静的ルートでは動的ルーティングの要件を満たしません。Classic VPN は現在、HA VPN への移行が推奨されている旧方式です。

【参考】
HA VPN トポロジ
Cloud VPN の概要
この問題のページを開く →
問題 5オブザーバビリティ ツールを使ってこの問題を診断し、根本原因を特定する必要があります。ネットワーク運用の管理・監視・トラブルシューティング
問題
あなたの会社は、多数のスポーク VPC 間の通信を実現するために Network Connectivity Center(NCC)を利用しています。開発チームから、app-dev-spoke-vpc のアプリケーション インスタンスが db-dev-spoke-vpc にある新しいデータベース サービスに接続できないという報告がありました。オブザーバビリティ ツールを使ってこの問題を診断し、根本原因を特定する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    Firewall Insights を使用してファイアウォール ルールの構成を分析し、該当するルールを修正する。
  • 2
    app-dev-spoke-vpc と db-dev-spokevpc の両方で、各ファイアウォール ルールを確認する。
  • 3
    Network Connectivity Center に接続された app-dev-spoke-vpc のアプリケーション インスタンスに、データベース サービスへ到達するための外部 IP アドレスが割り当てられていることを確認する。
  • ✓
    Network Intelligence Center の接続テスト(Connectivity Tests)を使用して、app-dev-spoke-vpc のインスタンスと db-dev-spoke-vpc のデータベース サービスの間の到達性分析を行う。

解説

【正解】D

【0からの解説】
①前提知識
・Network Connectivity Center(NCC)は、ハブに複数の VPC スポーク(やハイブリッド スポーク)を接続し、スポーク間でサブネット ルートを交換させるハブ&スポーク型の接続サービスです。スポーク間で通信できない原因としては、ルートが交換されていない(エクスポート フィルタ、スポークの未接続、IP 範囲の重複など)、ファイアウォール ルールで拒否されている、宛先サービスの設定ミスなど、複数の可能性があります。
・Network Intelligence Center の接続テスト(Connectivity Tests)は、送信元と宛先(IP・ポート・プロトコル)を指定すると、VPC のルート・ファイアウォール ルール(階層型ファイアウォール ポリシーや Cloud NGFW ポリシーを含む)・NCC・ピアリング・VPN などの構成を静的に解析し、パケットがどこまで届き、どの段階で何によって破棄されるかを経路として示す診断ツールです(ライブ データプレーン分析を行える場合もあります)。

②要件と制約語の整理
・オブザーバビリティ ツールを使って診断する
・根本原因を特定する(原因がルートかファイアウォールかなど、まだわかっていない)

③正解の理由
接続テストで app-dev-spoke-vpc のインスタンスから db-dev-spoke-vpc のデータベース サービスまでの到達性を分析すれば、NCC 経由のルートの有無、ファイアウォールによる拒否、宛先側の問題などを 1 回で切り分けられ、どのリソースが原因かが結果に示されます。「ツールで診断し根本原因を特定する」要件に最も直接的に合致します。

【誤りの選択肢】
A:Firewall Insights はファイアウォール ルールの使用状況(シャドウ化されたルール、使われていない許可ルール、過度に許可的なルールなど)を分析するツールで、特定の 2 地点間の到達性を診断するものではありません。また原因がファイアウォールだと決めつけており、NCC のルート交換の問題などを見逃します。さらに「ルールを修正する」のは原因特定前の対処で、手順として飛躍しています。
B:両 VPC のファイアウォール ルールを 1 つずつ手作業で確認するのは、オブザーバビリティ ツールを使っておらず、手間がかかり見落としも起きやすい方法です。原因がルートにある場合は発見できません。
C:NCC のスポーク間通信は内部 IP アドレスで行われ、外部 IP アドレスは不要です。外部 IP を割り当てるのは不要な露出を増やすだけで、原因の診断にもなりません。

【参考】
接続テストの概要 | Network Intelligence Center - Connectivity Tests
Network Connectivity Center の概要
この問題のページを開く →
問題 6production-critical のタグが付いた仮想マシンからのすべてのアウトバウンド インターネット トラフィッ…クラウド ネットワーク セキュリティ ソリューションの構成・実装・管理
問題
あなたの会社は、Google Cloud 環境のアウトバウンド インターネット トラフィックに関する新しいルールを導入しようとしています。production-critical のタグが付いた仮想マシンからのすべてのアウトバウンド インターネット トラフィックは検査のために Secure Web Proxy(SWP)を経由させ、それ以外のすべての仮想マシンはインターネットへ直接下り(外向き)通信できるようにする構成を設計する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    production-critical の VM からのトラフィックを変換してインターネットに転送するよう構成した Cloud NAT ゲートウェイをデプロイする。
  • ✓
    production-critical ネットワーク タグに対して、宛先 0.0.0.0/0、ネクストホップを SWP の IP アドレスとするカスタム静的ルートを構成する。
  • 3
    production-critical ネットワーク タグに対して、宛先 0.0.0.0/0、ネクストホップを SWP の IP とするポリシーベース ルートを構成する。
  • 4
    送信元を production-critical の VM のサブネット、宛先を 0.0.0.0/0、ネクストホップを SWP の IP とするポリシーベース ルートを構成する。

解説

【正解】B

【0からの解説】
①前提知識
・Secure Web Proxy(SWP)は、下り(外向き)の HTTP/HTTPS トラフィックを URL・ホスト名・セキュア タグ・サービス アカウントなどの条件で許可 / 拒否し、TLS 検査もできるマネージドのプロキシです。クライアントがプロキシを明示的に指定する「明示的プロキシ」モードのほか、ルートで SWP に誘導する「ネクストホップ」ルーティング モードがあります。
・公式ドキュメント「Secure Web Proxy をネクストホップとしてデプロイする」では、トラフィックを SWP に誘導する方法として (1) 静的ルート(ネクストホップに SWP の IP、ネットワーク タグで対象 VM を限定、優先度はデフォルト インターネット ルート(通常 1000)より小さい値)と、(2) 送信元 IP 範囲で対象を指定するポリシーベース ルート(加えて、既定のルーティングに戻すポリシーベース ルートも必要)の 2 つが示されています。
・VPC のルート選択では、宛先が最も長く一致するルートが優先されるため、静的ルート 0.0.0.0/0 は社内宛ての通信(サブネット ルート)には影響しません。一方、ポリシーベース ルートはサブネット ルートを含む他のルートより先に評価されるため、宛先 0.0.0.0/0 にすると VPC 内部宛ての通信まで SWP に送られてしまい、除外用のルートを別途用意する必要があります。

②要件と制約語の整理
・「production-critical のタグが付いた VM」のインターネット向け通信だけを SWP 経由にする
・それ以外の VM はインターネットへ直接出られるようにする

③正解の理由
production-critical タグに適用する宛先 0.0.0.0/0 の静的ルートを、デフォルト インターネット ルートより高い優先度(小さい値)で作成し、ネクストホップを SWP の IP にします。タグの付いた VM のインターネット宛て通信だけが SWP に送られ、タグのない VM は従来どおりデフォルト インターネット ゲートウェイで直接出ていきます。ネットワーク タグでの対象指定は、公式の SWP ネクストホップ構成手順そのものです。

【誤りの選択肢】
A:Cloud NAT は送信元アドレスを変換してインターネットに出すためのサービスで、トラフィックの検査は行いません。SWP を経由させるという要件を満たしません。
C:一見、静的ルートと同じことができる別解に見えますが、次の 2 点で B に劣ります。
 (1) 評価順序の問題:VPC では、ポリシーベース ルートがサブネット ルートを含む他のすべてのルートより先に評価されます。宛先 0.0.0.0/0 のポリシーベース ルートは「インターネット宛て」だけでなく「VPC 内の他の VM や社内宛て」の通信にも一致するため、production-critical の VM の内部通信まで SWP に送られてしまいます。SWP は外向きの Web 通信を検査するプロキシなので、内部通信が届くと通信障害の原因になります。避けるには内部の宛先を除外する追加のポリシーベース ルートが必要で、構成が複雑になり設定漏れのリスクも増えます。これに対し静的ルートは「最長一致」で選ばれるため、宛先 0.0.0.0/0 にしても、より具体的なサブネット ルートが優先され、内部通信はそのまま VPC 内で届きます。
 (2) 公式手順との違い:公式ドキュメント「Secure Web Proxy をネクストホップとしてデプロイする」では、ネットワーク タグで対象 VM を絞るのは静的ルートの方法として説明されています。ポリシーベース ルートの方法は、送信元 IP 範囲(--source-range)と宛先範囲で対象トラフィックを指定する例で示されており、さらに既定のルーティングに戻すためのポリシーベース ルートも別途作成する必要があります。「タグで対象を選ぶ」という要件には、公式手順どおりの静的ルート(B)がそのまま当てはまります。
 以上から、タグ単位で SWP に誘導するという要件に対しては、単純で内部通信に影響しない B が最適であり、C は正解になりません。
D:送信元をサブネット単位で指定すると、同じサブネットにある production-critical 以外の VM の通信まで SWP に送られてしまい、「それ以外の VM はインターネットへ直接出る」という要件を満たしません。また C と同様に、VPC 内部宛ての通信も SWP に送られてしまいます。

【参考】
Secure Web Proxy をネクストホップとしてデプロイする
静的ルート | Virtual Private Cloud
ポリシーベースのルート | Virtual Private Cloud
この問題のページを開く →
問題 7余分なコストの発生や、新しい事業部のネットワーク チームへの不必要な権限の付与は避けたいと考えています。Google Cloud VPC ネットワークの設計と計画
問題
あなたの会社は新しい事業部を買収しました。新しい事業部のネットワーク チームは、自分たちのネットワーク インフラストラクチャを完全に制御することを求めています。単一の VPC で構成されている既存の Google Cloud ネットワーク インフラストラクチャを拡張し、すべての事業部のワークロードが相互に通信できるようにする必要があります。余分なコストの発生や、新しい事業部のネットワーク チームへの不必要な権限の付与は避けたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    ・新しい事業部のネットワーク チーム用に新しいプロジェクトを作成する。・新しいプロジェクト内に新しい VPC を作成する。・既存の VPC と新しい事業部の VPC の間に VPC ピアリングを確立する。・新しい事業部のワークロード専用の新しいサブネットを作成する。・新しいプロジェクトに対する roles/compute.networkUser を新しい事業部のネットワーク チームのグループに付与する。
  • ✓
    ・新しい事業部のネットワーク チーム用に新しいプロジェクトを作成する。・新しいプロジェクト内に新しい VPC を作成する。・既存の VPC と新しい事業部の VPC の間に VPC ピアリングを確立する。・新しく作成したプロジェクトに対する roles/compute.networkAdmin を新しい事業部のネットワーク チームのグループに付与する。
  • 3
    ・既存のネットワーク インフラストラクチャをホストしているプロジェクトが、ホスト プロジェクトとして有効になっていることを確認する。・既存の VPC に新しい事業部のワークロード専用の新しいサブネットを作成する。・新しく作成したサブネットに対する roles/compute.networkUser を新しい事業部のネットワーク チームのグループに付与する。
  • 4
    ・新しい事業部のネットワーク チーム用に新しいプロジェクトを作成する。・新しいプロジェクト内に新しい VPC を作成する。・既存の VPC と新しい事業部の VPC の間に VPN 接続を確立する。・新しく作成したプロジェクトに対する roles/compute.networkAdmin を新しい事業部のネットワーク チームのグループに付与する。

解説

【正解】B

【0からの解説】
①前提知識
・VPC ネットワーク ピアリングは、2 つの VPC(別プロジェクト・別組織でも可)を Google の内部ネットワークで接続し、内部 IP で通信できるようにする機能です。各 VPC は独立して管理され、それぞれの管理者が自分の VPC のサブネット・ルート・ファイアウォールを管理できます。ピアリング自体に料金はかからず、ゲートウェイなどの追加リソースも不要です。
・共有 VPC は、ホスト プロジェクトの VPC をサービス プロジェクトに共有する仕組みで、ネットワークの管理権限はホスト プロジェクト側(中央のネットワーク チーム)に集中します。
・roles/compute.networkUser(ネットワーク ユーザー)は、共有 VPC のサブネットなどを「使う」だけのロールで、ネットワークを作成・変更する権限はありません。roles/compute.networkAdmin(ネットワーク管理者)は、VPC・サブネット・ルート・ピアリングなどのネットワーク リソースを作成・変更・削除できるロールです(ファイアウォール ルールや SSL 証明書の管理は compute.securityAdmin の範囲)。

②要件と制約語の整理
・新しい事業部のネットワーク チームが自分たちのネットワークを「完全に制御」できること
・全事業部のワークロードが相互に通信できること
・「余分なコストを避ける」
・「不必要な権限を付与しない」(既存 VPC の管理権限は渡さない)

③正解の理由
新しいプロジェクトに新しい VPC を作り、既存の VPC とピアリングすれば、追加料金なしで相互通信できます。新しい事業部には「新しいプロジェクトに対する」networkAdmin だけを付与するので、自分たちの VPC は自由に管理でき、既存の VPC には権限が及びません。完全な制御・コスト回避・最小権限をすべて満たします。

【誤りの選択肢】
A:構成はピアリングで問題ありませんが、付与しているのが networkUser のため、新しい事業部のネットワーク チームは自分たちの VPC やサブネットを作成・変更できず、「完全に制御する」要件を満たしません。
C:共有 VPC のサブネットに networkUser を付与するだけでは、サブネットを使えるだけでネットワークの制御権はホスト プロジェクト側に残ります。「ネットワーク インフラストラクチャを完全に制御する」要件を満たしません。
D:権限の付与は B と同じで要件を満たしますが、VPC 間を VPN で接続すると、VPN ゲートウェイとトンネルの料金や VPN 経由の通信料が発生し、帯域もトンネルあたり約 3 Gbps に制限されます。無料のピアリングで済むところに余分なコストをかけるため、「余分なコストを避ける」要件に反します。

【参考】
VPC ネットワーク ピアリング | Virtual Private Cloud
ネットワーク関連ジョブ機能の IAM ロール | Identity and Access Management (IAM)
共有 VPC | Virtual Private Cloud
この問題のページを開く →
問題 8VPC ネットワークの実装VPC ネットワークの実装
問題
あなたの組織では、すべてのデータベース VM が使用する内部 IP アドレスはすべて静的に割り当てることが義務付けられています。VPC の IP アドレス割り当てを分析したところ、データベース VM に静的 IP アドレスが割り当てられていないことがわかりました。現在の運用を一切中断させることなく、組織の義務に従うように VPC を構成する必要があります。どうすればよいですか?

選択肢と解説

  • ✓
    すべてのデータベース VM の内部 IP アドレスを静的割り当てに昇格する。
  • 2
    データベース VM に割り当てられている IP アドレス宛てのトラフィックのみを許可するファイアウォール ルールを作成する。
  • 3
    メンテナンスの時間枠を定義し、データベース VM を 1 台ずつシャットダウンして、内部 IP アドレスを静的割り当てに昇格し、VM を再起動する。
  • 4
    VM に静的に割り当てられた IP アドレスのみを許可する組織のポリシーを定義する。プレフィックスがデータベース VM と一致するようにする。

解説

【正解】A

【0からの解説】
①前提知識
Compute Engine の VM の内部 IP アドレスには、エフェメラル(一時的)と静的(予約済み)の 2 種類があります。エフェメラル内部 IP は VM を削除すると解放され、再作成時に別のアドレスになる可能性があります。静的内部 IP は予約されたアドレス リソースとして保持され、VM を削除しても失われません。
Google Cloud では、使用中のエフェメラル内部 IP アドレスをそのまま静的内部 IP アドレスに「昇格(promote)」できます。この操作はアドレスを予約リソースとして登録するだけで、VM の停止や IP アドレスの変更は伴いません。

②要件の整理
・データベース VM の内部 IP をすべて静的にする。
・現在の運用を中断させない(ダウンタイムを発生させない)。

③正解の理由
A のとおり、各データベース VM が現在使っているエフェメラル内部 IP を静的アドレスに昇格すれば、IP アドレスは変わらず、VM も稼働したままで組織の要件を満たせます。
実務の手順は次のとおりです。
・対象の洗い出し:コンソールの[IP アドレス]ページの[内部 IP アドレス]タブで「タイプ」列がエフェメラルのものに絞り込むか、gcloud compute instances describe で各 VM の networkIP を確認します(gcloud compute addresses list に表示されるのは予約済みの静的アドレスだけなので、そこに出てこない VM の IP がエフェメラルです)。
・昇格:コンソールでは該当アドレスの[その他の操作]から[静的 IP アドレスに昇格]を選び、名前を付けて予約します。gcloud では gcloud compute addresses create 名前 --addresses=現在の IP --region=リージョン --subnet=サブネット を実行します。複数台分は名前とアドレスを同じ順序で並べて一度に昇格できます。
・注意点:静的内部 IP はリージョン リソースで、プロジェクトの割り当て(クォータ)の範囲内でしか予約できません。また VM を削除してもアドレスは自動では解放されないため、不要になったら手動で解放します。
なお、場面の異なる類題では「VM を削除しても同じ IP が他の VM に払い出されないようにしたい」という目的で同じ昇格操作が問われます。本問の着眼点はそれとは異なり、「既存の稼働中 VM に対して、停止を伴わずにコンプライアンス要件を満たせるか」です。昇格は VM の停止も IP の変更も伴わないため、無停止という制約に対しても A が唯一の答えになります。

【誤りの選択肢】
B:ファイアウォール ルールは通信の許可 / 拒否を制御するもので、IP アドレスの割り当て方式(エフェメラル / 静的)を変えることはできません。要件を満たしません。
C:最終的に静的 IP にはなりますが、昇格に VM の停止は不要です。不要なシャットダウンと再起動によってデータベースのダウンタイムが発生し、「運用を中断させない」という要件に反します。
D:「静的に割り当てられた IP アドレスのみを許可する」という組織のポリシーの制約は用意されておらず、仮に新規作成を制限できたとしても、既存 VM のエフェメラル IP を静的に変換することはできません。

【参考】
静的内部 IP アドレスの予約 | Virtual Private Cloud
IP アドレス | Virtual Private Cloud
この問題のページを開く →
問題 9特に重要なワークロードの移行には時間がかかるため、Google Cloud CDN を設定し、AWS 上の既存のアプリケ…マネージド ネットワーク サービスの構成
問題
あなたの組織は AWS から Google Cloud へワークロードを移行しています。特に重要なワークロードの移行には時間がかかるため、Google Cloud CDN を設定し、AWS 上の既存のアプリケーションを参照するようにする必要があります。どうすればよいですか。

選択肢と解説

  • ✓
    ・アプリケーションの既存の FQDN を参照するインターネット NEG を作成する。・その NEG をバックエンド サービスとして Application Load Balancer にマッピングする。・バックエンド サービスで Cloud CDN を有効にする。
  • 2
    ・アプリケーションの既存の IP を参照するハイブリッド NEG を作成する。・その NEG をターゲット プールとしてパススルー ネットワーク ロードバランサにマッピングする。・ターゲット プールで Cloud CDN を有効にする。
  • 3
    ・アプリケーションの既存の FQDN を参照するインターネット NEG を作成する。・その NEG をバックエンド サービスとしてパススルー ネットワーク ロードバランサにマッピングする。・バックエンド サービスで Cloud CDN を有効にする。
  • 4
    ・アプリケーションの既存の IP を参照するハイブリッド NEG を作成する。・その NEG をバックエンド サービスとして Application Load Balancer にマッピングする。・バックエンド サービスで Cloud CDN を有効にする。

解説

【正解】A

【0からの解説】
①前提知識
・Cloud CDN は、外部アプリケーション ロードバランサ(Application Load Balancer)のバックエンド サービスまたはバックエンド バケットで有効にするキャッシュ機能です。レイヤ 7(HTTP/HTTPS)で動作するため、パススルー ネットワーク ロードバランサ(レイヤ 4)では使えません。
・インターネット NEG は、Google Cloud の外にあり公開インターネットから到達できるエンドポイント(FQDN または外部 IP とポート)をロードバランサのバックエンドとして登録する NEG です。オンプレミスや他クラウドのオリジンに Cloud CDN を適用する「外部バックエンド(カスタム オリジン)」の標準的な構成として公式ドキュメントに記載されています。
・ハイブリッド接続 NEG(ハイブリッド NEG)は、Cloud VPN や Cloud Interconnect などのハイブリッド接続を介して到達する「内部 IP」のエンドポイントを登録する NEG です。

②要件と制約語の整理
・Cloud CDN を使う
・オリジンは AWS 上で稼働中の既存アプリケーション(インターネットから FQDN で到達可能、AWS とのハイブリッド接続は問題文にない)

③正解の理由
アプリケーションの FQDN を指すインターネット NEG を作り、外部 Application Load Balancer のバックエンド サービスに設定して Cloud CDN を有効にすれば、AWS 上のアプリケーションをオリジンとしてキャッシュ配信できます。FQDN を使うので、AWS 側の IP アドレスが変わる構成(ELB など)でも追従でき、移行完了後はバックエンドを Google Cloud 上のものに切り替えるだけで済みます。

【誤りの選択肢】
B:パススルー ネットワーク ロードバランサやターゲット プールでは Cloud CDN を有効にできません。また、ハイブリッド NEG は VPN / Interconnect 経由の内部 IP を対象とするもので、問題文にはそのような接続はありません。
C:インターネット NEG の使い方は正しいものの、パススルー ネットワーク ロードバランサは Cloud CDN に対応していません(Cloud CDN は Application Load Balancer でのみ利用可能)。
D:Application Load Balancer と Cloud CDN の組み合わせは正しいですが、ハイブリッド NEG を使うには AWS との間に Cloud VPN や Cross-Cloud Interconnect などのハイブリッド接続を新たに構築する必要があり、構成と運用の負荷が増えます。インターネットから到達できる既存アプリケーションを参照するだけなら、インターネット NEG が適切です。

【参考】
インターネット NEG を使用して指定された外部バックエンド | Cloud CDN
インターネット ネットワーク エンドポイント グループの概要 | Cloud Load Balancing
この問題のページを開く →
問題 10このチームのワークロードのために、低レイテンシのネットワーク接続を確立する必要があります。ハイブリッド/マルチクラウド ネットワーク相互接続の構成と実装
問題
あなたは、ドイツのフランクフルトにある組織のオンプレミス データセンターから、同じくフランクフルト都市圏にある europe-west3 リージョンに向けて、Dedicated Interconnect 接続をセットアップしています。AI チームのリーダーは、チームが Google Cloud の TPU をワークロードに使いたいため、europe-west4 リージョンへの接続性について懸念を示しました。このチームのワークロードのために、低レイテンシのネットワーク接続を確立する必要があります。コストと運用のオーバーヘッドを最小限に抑えたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    europe-west3 リージョンではなく、europe-west4 リージョンに向けて Dedicated Interconnect 接続をセットアップする。
  • 2
    データセンターと europe-west4 リージョンの間に、追加の Partner Interconnect 接続をセットアップする。
  • ✓
    Dedicated Interconnect 接続上に、europe-west4 リージョンへのリモート VLAN アタッチメントをセットアップする。
  • 4
    Dedicated Interconnect の代わりに Cloud VPN を使用し、インターネット経由でトラフィックを送信する。

解説

【正解】C

【0からの解説】
①前提知識:Dedicated Interconnect は、オンプレミスのルーターと Google のネットワークを、コロケーション施設(Interconnect ロケーション)で物理的に直結するサービスです。物理回線(Interconnect 接続)の上に、論理的な接続である VLAN アタッチメントを作成し、VLAN アタッチメントを特定のリージョンの Cloud Router に関連付けて VPC と接続します。VLAN アタッチメントのリージョンは、Interconnect 接続のある都市圏と同じである必要はなく、ワークロードに近い別のリージョンに作成できます(この場合、そのリージョンの Cloud Router と VLAN アタッチメントが Google のバックボーンを経由して物理回線とつながります)。つまり 1 本の物理回線を複数リージョンで共有できます。どのリージョンに VLAN アタッチメントを作れるかは Interconnect ロケーションの地域ごとに決まっており、フランクフルトのような欧州(EMEA)のロケーションでは europe-west3 だけでなく europe-west4 も対象に含まれます。
なお、選択肢 C の「リモート VLAN アタッチメント」は Google Cloud の公式の用語ではありません。ここでは「Interconnect 接続(物理回線)のある都市圏のリージョン(europe-west3)とは別のリージョン(europe-west4)の Cloud Router に関連付けて作成した、通常の VLAN アタッチメント」を指す表現として読んでください。特別な種類のアタッチメントがあるわけではなく、作成時に指定するリージョンと Cloud Router が異なるだけです。

②要件の整理:オンプレミスはフランクフルトにあり、物理回線はフランクフルトの Interconnect ロケーション(europe-west3 の都市圏)に引きます。AI チームは europe-west4(オランダ)の TPU を使うため、europe-west4 への低レイテンシ接続が必要です。制約は「コストと運用のオーバーヘッドを最小限に」です。

③正解の根拠:既存(構築中)の Dedicated Interconnect 接続上に、europe-west4 リージョンの Cloud Router に関連付けた VLAN アタッチメント(設問でいう「リモート VLAN アタッチメント」。公式用語ではなく、別リージョンに作った通常の VLAN アタッチメントのこと)を追加すれば、新しい物理回線や契約を増やさずに、Google のプライベート バックボーン経由で europe-west4 へ低レイテンシで到達できます。追加するのは論理リソース(VLAN アタッチメントと Cloud Router)だけなので、コストも運用負荷も最小です。なお、VLAN アタッチメントを Interconnect 接続と異なるリージョンに置く場合や、リージョンをまたいで経路を使う場合は、必要に応じて VPC の動的ルーティング モードをグローバルにすることも検討します。

【誤りの選択肢】
A:Dedicated Interconnect の物理回線はリージョンではなくコロケーション施設に引くものです。europe-west4 側(オランダ)の施設に回線を引くと、フランクフルトのデータセンターから国をまたぐ長距離回線が必要になり、コストが大幅に増えるうえ、europe-west3 向けの接続性も損なわれます。
B:Partner Interconnect を追加すると、別の回線・別のサービス プロバイダ契約・別の運用が増え、「コストと運用のオーバーヘッドを最小限に」に反します。既存の Dedicated Interconnect 上の VLAN アタッチメントで同じ目的を達成できます。
D:Cloud VPN はインターネット経由のため、Interconnect と比べてレイテンシや帯域が安定せず、「低レイテンシ」の要件を満たしません。また、すでに構築している Dedicated Interconnect を捨てる理由もありません。

【参考】
Dedicated Interconnect の概要
すべてのコロケーション施設 | Cloud Interconnect
この問題のページを開く →
問題 11ネットワーク運用の管理・監視・トラブルシューティングネットワーク運用の管理・監視・トラブルシューティング
問題
あなたは会社のネットワーク セキュリティを管理しており、本番環境のサブネットに属する Compute Engine VM からの異常なアウトバウンド トラフィックに気付きました。その VM が悪意のある外部 IP アドレスと通信しようとしているため、侵害されている可能性を疑っています。この特定の VM との間のすべての IP 接続について、送信元 / 宛先 IP、ポート、プロトコル、転送データ量を含む詳細なメタデータを取得したいと考えています。どうすればよいですか。

選択肢と解説

  • ✓
    ・VM を含むサブネットで VPC フローログを有効にする。・詳細を最大にするためにサンプリング レートを 1.0 に設定し、Cloud Logging で VM の IP アドレスによってログをフィルタする。
  • 2
    ・Network Intelligence Center に移動し、VM に対して新しい接続テストを実行する。・レポートを分析し、どの構成がそのトラフィックを許可しているかを確認する。
  • 3
    ・パケット ミラーリングを使用して、疑わしい VM からのすべてのネットワーク パケットのリアルタイムのコピーを作成する。・そのコピーを分析用のコレクタ VM に転送する。
  • 4
    ・優先度 65535 で、すべてのアウトバウンド トラフィックを許可する新しい下り(外向き)ファイアウォール ルールを作成する。・この新しいルールでファイアウォール ルール ロギングを有効にして、すべての接続の詳細を取得する。

解説

【正解】A

【0からの解説】
①前提知識
・VPC フローログは、VM のネットワーク インターフェースで送受信された IP フロー(接続)のメタデータを記録する機能です。各レコードには、5 タプル(送信元 / 宛先 IP、送信元 / 宛先ポート、プロトコル)、送受信バイト数・パケット数、開始 / 終了時刻、VM 名などの付加情報が含まれ、Cloud Logging で検索・フィルタできます。サブネット単位(現在はネットワークや Interconnect / VPN 単位の構成も可能)で有効化し、サンプリング レート(0.0〜1.0)や集約間隔を設定できます。1.0 にすると記録対象のログをすべて残すため、最も詳細になります。
・パケット ミラーリングは、パケットのヘッダーとペイロードを丸ごと複製してコレクタ(内部パススルー ネットワーク ロードバランサ配下の IDS など)に送る機能です。パケットの中身まで解析するディープ パケット インスペクション向けです。

②要件と制約語の整理
・特定の VM の「すべての IP 接続」について
・送信元 / 宛先 IP、ポート、プロトコル、「転送データ量」という「メタデータ」を取得したい(パケットの中身ではない)

③正解の理由
VPC フローログを VM のサブネットで有効にし、サンプリング レートを 1.0 にすれば、要件にあるフィールド(IP・ポート・プロトコル・バイト数)がそのままログ レコードとして得られます。Cloud Logging で VM の IP アドレス(または VM 名)でフィルタすれば、その VM の接続だけを調査でき、外部の悪性 IP との通信量も確認できます。追加のコレクタ VM などのインフラも不要です。
※ VPC フローログは Google 側の一次サンプリングを伴うため、厳密には「全パケット」ではありませんが、接続単位のメタデータ取得という目的では最適な選択肢です。

【誤りの選択肢】
B:接続テストは、ルートやファイアウォールの「構成」からある通信が到達可能かどうかを解析するツールで、実際に発生した接続の記録(どの IP とどれだけデータを送ったか)は取得できません。
C:パケット ミラーリングでもデータは取れますが、パケット全体を複製するため、コレクタ VM・内部ロードバランサの構築やストレージ、解析の手間とコストが大きくなります。要件は「メタデータ」の取得であり、ペイロードまでのコピーは過剰です。
D:優先度 65535 は最も低い優先度で、より優先度の高い既存ルールに一致した通信はこのルールでは評価されないため、すべての接続は記録されません。また、ファイアウォール ルール ロギングは転送データ量(バイト数)を記録しません。さらに、侵害が疑われる VM に対して「すべての送信を許可」するルールを追加するのはセキュリティ上も逆効果です。

【参考】
VPC Flow Logs | Virtual Private Cloud
VPC Flow Logs のレコードについて | Virtual Private Cloud
この問題のページを開く →
問題 12新しい構成が適用されるように設定を調整する必要があります。クラウド ネットワーク セキュリティ ソリューションの構成・実装・管理
問題
あなたの会社では VPC ファイアウォール ルールを使用しており、すべての下り(外向き)トラフィックを拒否しています。一部の VM が、完全修飾ドメイン名(FQDN)に基づいて外部のウェブサイトにアクセスできるようにする必要があります。新しい構成を適用しましたが、トラフィックは依然として拒否されています。新しい構成が適用されるように設定を調整する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    ネットワーク ファイアウォール ポリシー ルールの優先度を上げる。
  • 2
    ネットワーク ファイアウォール ポリシー ルールの優先度を下げる。
  • ✓
    デフォルトのポリシーとルールの評価順序を BEFORE_CLASSIC_FIREWALL に更新する。
  • 4
    デフォルトのポリシーとルールの評価順序を AFTER_CLASSIC_FIREWALL に更新する。

解説

【正解】C

【0からの解説】
①前提知識:Google Cloud のファイアウォールには、従来からある VPC ファイアウォール ルール(いわゆるクラシック ファイアウォール)と、Cloud NGFW のファイアウォール ポリシー(階層型・グローバル ネットワーク・リージョン ネットワーク ファイアウォール ポリシー)があります。FQDN オブジェクト(宛先をドメイン名で指定する機能)は VPC ファイアウォール ルールでは使えず、ネットワーク ファイアウォール ポリシー(または階層型ポリシー)のルールでのみ使えます。
評価順序は、階層型ファイアウォール ポリシー → VPC ファイアウォール ルールとネットワーク ファイアウォール ポリシーの順です。VPC ネットワークには networkFirewallPolicyEnforcementOrder という設定があり、既定値は AFTER_CLASSIC_FIREWALL(VPC ファイアウォール ルールを先に評価し、その後にネットワーク ファイアウォール ポリシーを評価)です。BEFORE_CLASSIC_FIREWALL に変更すると、ネットワーク ファイアウォール ポリシーが VPC ファイアウォール ルールより先に評価されます。

②状況の整理:既存の VPC ファイアウォール ルールで「すべての下りを拒否」しており、FQDN を使った許可ルールはネットワーク ファイアウォール ポリシーに追加したはずです(FQDN はポリシーでしか使えないため)。既定の AFTER_CLASSIC_FIREWALL のままだと、先に評価される VPC ファイアウォール ルールの「下りすべて拒否」に一致した時点でパケットが拒否され、後で評価されるネットワーク ファイアウォール ポリシーの許可ルールには到達しません。

③正解の根拠:評価順序を BEFORE_CLASSIC_FIREWALL に変更すれば、ネットワーク ファイアウォール ポリシーの FQDN 許可ルールが先に評価され、一致したトラフィックは許可されます(allow は終端アクションのため、その後の VPC ファイアウォール ルールの拒否は評価されません)。一致しないトラフィックは従来どおり VPC ファイアウォール ルールの拒否で止まります。長期的には VPC ファイアウォール ルールをネットワーク ファイアウォール ポリシーへ移行し、ポリシーに一本化するのが推奨です。

【誤りの選択肢】
A:優先度はポリシー(またはルールのグループ)内での順番を決めるもので、VPC ファイアウォール ルールとネットワーク ファイアウォール ポリシーの間の評価順は変わりません。優先度を上げてもポリシーは VPC ファイアウォール ルールの後に評価されるため、拒否は解消されません。
B:優先度を下げても同様に、ポリシーと VPC ファイアウォール ルールの評価順は変わらず、むしろポリシー内で他のルールより後回しになるだけです。
D:AFTER_CLASSIC_FIREWALL は既定値で、まさに現在の状態(VPC ファイアウォール ルールが先に評価され拒否される)です。これに「更新」しても何も変わりません。

【参考】
ファイアウォール ポリシーとルールの評価順序 | Cloud Next Generation Firewall
完全修飾ドメイン名オブジェクトの概要 | Cloud Next Generation Firewall
FQDN への下り(外向き)トラフィックを許可するグローバル ネットワーク ファイアウォール ポリシーを構成する | Cloud Next Generation Firewall
この問題のページを開く →
問題 13帯域幅は 1 Gbps 以上である必要があり、トラフィックがインターネットを経由してはいけません。Google Cloud VPC ネットワークの設計と計画
問題
あなたの組織にはオンプレミスのデータセンターがあります。オンプレミスのデータセンターから Google Cloud への接続を提供する必要があります。帯域幅は 1 Gbps 以上である必要があり、トラフィックがインターネットを経由してはいけません。どうすればよいですか。

選択肢と解説

  • 1
    高可用性ゲートウェイとトンネルを使用して、HA VPN を構成する。
  • 2
    VLAN アタッチメントを作成して Cross-Cloud Interconnect を構成し、接続を有効化してから、ペアリング キーをサービス プロバイダに送信する。
  • 3
    VLAN アタッチメントを作成して Dedicated Interconnect を構成し、接続を有効化して、ペアリング キーをサービス プロバイダに送信する。
  • ✓
    VLAN アタッチメントを作成して Partner Interconnect を構成し、ペアリング キーをサービス プロバイダに送信してから、接続を有効化する。

解説

【正解】D

【0からの解説】
①前提知識:オンプレミスと Google Cloud をつなぐ主な方法は次の 3 つです。
・Cloud VPN(HA VPN):インターネット上に IPsec の暗号化トンネルを張る方式。トンネル 1 本あたり最大約 3 Gbps ですが、トラフィックはインターネットを経由します。
・Dedicated Interconnect:コロケーション施設で自社ルーターと Google のネットワークを物理的に直結する方式(10 Gbps / 100 Gbps 回線単位)。サービス プロバイダは介在せず、ペアリング キーも使いません。
・Partner Interconnect:サポートされているサービス プロバイダの回線を経由して Google に接続する方式(50 Mbps〜50 Gbps の VLAN アタッチメント)。インターネットを経由しません。手順は「Google Cloud で Partner Interconnect 用の VLAN アタッチメントを作成 → 発行されたペアリング キーをサービス プロバイダに渡す → プロバイダが接続を構成した後、VLAN アタッチメントを有効化(activate)する」の順です。
また Cross-Cloud Interconnect は、Google Cloud と他社クラウド(AWS・Azure・OCI・Alibaba Cloud)を直結するサービスで、オンプレミス向けではありません。

②要件の整理:「1 Gbps 以上」「インターネットを経由しない」の 2 条件です。

③正解の根拠:Partner Interconnect はインターネットを経由せず、1 Gbps 以上の容量も選べるので両条件を満たします。D の手順(VLAN アタッチメント作成 → ペアリング キーをプロバイダへ送信 → 接続を有効化)は公式の Partner Interconnect の手順と一致しています。

【誤りの選択肢】
A:HA VPN はインターネット上に暗号化トンネルを張る方式のため、「トラフィックがインターネットを経由してはいけない」という要件を満たしません。
B:Cross-Cloud Interconnect は Google Cloud と他のクラウド サービス プロバイダを接続するためのもので、オンプレミスのデータセンターとの接続には使いません。また、ペアリング キーをサービス プロバイダへ送る手順は Partner Interconnect のものです。
C:Dedicated Interconnect 自体はインターネットを経由せず要件を満たし得ますが、手順が誤っています。Dedicated Interconnect では自社で物理回線を Google に直結するため、ペアリング キーやサービス プロバイダは登場しません(ペアリング キーは Partner Interconnect の概念)。また、有効化してからキーを送るという順序も Partner Interconnect の手順として誤りです。

【参考】
Partner Interconnect の概要
Cloud Interconnect の概要
Cross-Cloud Interconnect の概要
この問題のページを開く →
問題 14VPC ネットワークの実装VPC ネットワークの実装
問題
あなたは、分散したチームを持つ組織のために共有 VPC ネットワークを実装しています。複数のチームにまたがって作業しているアプリケーション開発者の 1 人が、別のアプリケーションのサービス プロジェクト用に予約されているサブネットにアプリケーションをデプロイできることに気付きました。開発者が、それぞれのサービス プロジェクト用に予約されているサブネットにのみリソースをデプロイできるようにしたいと考えています。どうすればよいですか?

選択肢と解説

  • ✓
    constraints/compute.restrictSharedVpcSubnetworks 組織の制約を使用して、各アプリケーションのサービス プロジェクトがアクセスできる共有 VPC サブネットを指定する。
  • 2
    共有 VPC ホスト プロジェクトで、開発者に compute.NetworkViewer ロールを付与する。
  • 3
    constraints/compute.restrictSharedVpcHostProject 組織の制約を使用して、別のアプリケーションのプロジェクトがホスト プロジェクト内の特定のサブネットにアクセスできないように制限する。
  • 4
    特定の共有 VPC サービス プロジェクトで、開発者に compute.NetworkUser ロールを付与する。

解説

【正解】A

【0からの解説】
①前提知識
共有 VPC では、ホスト プロジェクトが VPC ネットワークとサブネットを所有し、サービス プロジェクトのリソース(VM や GKE ノードなど)がそのサブネットを利用します。サービス プロジェクトのユーザーが共有サブネットを使うには、ホスト プロジェクト全体または個々のサブネットに対して Compute ネットワーク ユーザー(roles/compute.networkUser)ロールが必要です。
これに加え、組織のポリシーにも共有 VPC 用のリスト型制約があります。
・constraints/compute.restrictSharedVpcSubnetworks:プロジェクト(またはフォルダ / 組織)内のリソースが使用できる共有 VPC サブネットの一覧を制限する。
・constraints/compute.restrictSharedVpcHostProject:サービス プロジェクトとして接続できるホスト プロジェクトを制限する。

②要件の整理
・開発者は複数チームにまたがって作業しており、複数のサービス プロジェクトで権限を持っている。
・各サービス プロジェクトのリソースが、そのプロジェクト用に予約されたサブネットだけを使えるようにしたい。

③正解の理由
A のように各アプリケーションのサービス プロジェクトに restrictSharedVpcSubnetworks を設定し、許可するサブネットを指定すれば、開発者がどのサービス プロジェクトで作業していても、そのプロジェクトのリソースは割り当てられたサブネットにしかデプロイできません。ユーザー個人の IAM ではなくプロジェクト単位でガードレールをかけるため、複数チームにまたがる開発者がいても確実に制御できます。(なお、サブネット レベルで compute.networkUser を付与してホスト プロジェクト全体には付与しないことも、共有 VPC のベスト プラクティスです。)

【誤りの選択肢】
B:compute.networkViewer はネットワーク リソースの閲覧のみを許可するロールです。既存の権限(デプロイできてしまう状態)を取り消すものではなく、サブネットの利用を制限する効果もありません。
C:restrictSharedVpcHostProject は、サービス プロジェクトが接続できる「ホスト プロジェクト」を制限する制約で、ホスト プロジェクト内の特定のサブネット単位での制限はできません。
D:共有 VPC のサブネットを利用する権限は、ホスト プロジェクトまたはそのサブネットに対して付与します。サービス プロジェクトで compute.networkUser を付与しても共有サブネットへのアクセス範囲は制御できず、別アプリケーション用サブネットへのデプロイも防げません。

【参考】
共有 VPC | Virtual Private Cloud
共有 VPC をプロビジョニングする | Virtual Private Cloud
この問題のページを開く →
問題 15europe-west2 リージョンの VM が、us-east1 リージョンのリージョン内部アプリケーション ロードバ…マネージド ネットワーク サービスの構成
問題
あなたの VPC は、リージョン動的ルーティング モードで構成されています。europe-west2 リージョンに VM と VLAN アタッチメントをデプロイし、us-east1 リージョンにリージョン内部アプリケーション ロードバランサをデプロイしました。europe-west2 リージョンの VM が、us-east1 リージョンのリージョン内部アプリケーション ロードバランサに接続できるようにする必要があります。どうすればよいですか。

選択肢と解説

  • 1
    us-east1 にバックエンドを作成し、各リージョンに複数の転送ルールを作成してから、リージョン アクセスを有効にする。
  • 2
    europe-west2 にバックエンド サービスを作成し、us-east1 に転送ルールを作成してから、リージョン アクセスを有効にする。
  • 3
    us-east1 にバックエンド サービスを作成し、europe-west2 に転送ルールを作成してから、グローバル アクセスを有効にする。
  • ✓
    us-east1 にバックエンド サービスを作成し、us-east1 に転送ルールを作成してから、グローバル アクセスを有効にする。

解説

【正解】D

【0からの解説】
①前提知識:リージョン内部アプリケーション ロードバランサは、転送ルール(フロントエンドの内部 IP)・ターゲット プロキシ・URL マップ・バックエンド サービスをすべて同じ 1 つのリージョンに作るリージョン リソースです。既定では、ロードバランサと同じリージョンのクライアントからしかアクセスできません。別リージョンのクライアントからアクセスさせるには、転送ルールで「グローバル アクセス(global access)」を有効にします。グローバル アクセスを有効にすると、同じ VPC ネットワーク(および接続されたネットワーク)の任意のリージョンのクライアントがその内部 IP に到達できます。
また、VPC のサブネット ルートは動的ルーティング モード(リージョン/グローバル)に関係なく VPC 全体に有効です。動的ルーティング モードが影響するのは Cloud Router が学習した動的ルート(オンプレミスなどへの経路)であり、VPC 内の VM 同士やロードバランサへの到達性には影響しません。

②要件の整理:クライアントは europe-west2 の VM、ロードバランサは us-east1 のリージョン内部アプリケーション ロードバランサです。必要なのは「別リージョンのクライアントからのアクセスを許可すること」です。

③正解の根拠:D のとおり、バックエンド サービスと転送ルールをロードバランサのリージョン(us-east1)に置き、転送ルールでグローバル アクセスを有効にすれば、europe-west2 の VM から us-east1 のロードバランサの内部 IP へ接続できます。リージョン ロードバランサの構成要素は同一リージョンに揃える必要があるため、これが唯一の正しい組み合わせです。
なお、複数リージョンにバックエンドを持ち、クライアントに近いリージョンで受けたい場合はクロスリージョン内部アプリケーション ロードバランサという別の選択肢もありますが、本問は既存のリージョン内部アプリケーション ロードバランサへの接続が要件です。

【誤りの選択肢】
A:「リージョン アクセス」という設定は存在しません(存在するのはグローバル アクセス)。また、リージョン内部アプリケーション ロードバランサの転送ルールはロードバランサと同じリージョンにしか作れず、各リージョンに転送ルールを作る構成はできません。
B:バックエンド サービスを europe-west2、転送ルールを us-east1 にするとリージョンがばらばらになり、リージョン ロードバランサとして構成できません。また「リージョン アクセス」という設定もありません。
C:転送ルールを europe-west2 に置くと、us-east1 のバックエンド サービス(URL マップ・ターゲット プロキシ)とリージョンが一致せず、リージョン内部アプリケーション ロードバランサを構成できません。グローバル アクセスは転送ルールをロードバランサのリージョンに置いたまま有効にする設定です。

【参考】
内部アプリケーション ロードバランサの概要 | Cloud Load Balancing
転送ルールの概要 | Cloud Load Balancing
VM インスタンス グループのバックエンドを使用してリージョン内部アプリケーション ロードバランサを設定する | Cloud Load Balancing
この問題のページを開く →

GCP-PCNE 模擬問題集についてよくある質問

GCP-PCNE の練習問題は無料で試せますか?

はい。GCP-PCNE は先頭 15 問を会員登録なしで、正解と全選択肢の解説つきでご覧いただけます。16 問目以降は模試プラン(月額 ¥980)または Pro プラン(月額 ¥4,980)でご利用ください。

問題は何問ありますか?

GCP-PCNE は本番形式の練習テスト 4 回・全 200 問を収録しています。全問に解説が付いています。

解説は付いていますか?

全ての問題に、正解の理由と各選択肢がなぜ誤りなのかの解説を付けています。ドメイン(出題分野)別の正答率も受験後に確認できます。