GCP PNEのサンプル問題（本番形式・解説付き）

GCP PNE（Google Cloud・Professional Cloud Network Engineer（PNE））の出題形式を、実際の問題で確かめられます。ここに掲載する5問は、無料の会員登録で解ける模試第1回（55問）の冒頭から抜粋したオリジナル問題です。当サイトは全605問を本番CBT準拠の形式で収録しており、この5問はそのごく一部にあたります。

設問1

ある企業は、オンプレミスのシステムから Google の API へ、インターネットを経由せずにプライベートな経路で到達させたい。使う API の中には、VPC Service Controls に対応していない API も含まれており、それらも同じ経路で使えなければならない。オンプレミスとは Cloud Interconnect でつながっている。どの到達先を使うべきか。

restricted.googleapis.com。VPC Service Controls に対応した API だけを対象とする範囲である
Cloud NAT の外部 IP。オンプレミスからの通信を変換して Google の API へ届ける経路である
Direct Peering の経路。Google のエッジと BGP でピアリングして公開 API へ到達する経路である
private.googleapis.com。VPC Service Controls 非対応の API も含めて到達できる範囲である（正解）

解説

private.googleapis.com（199.36.153.8/30）は VPC Service Controls 非対応の API も含めて到達できる。restricted.googleapis.com は対応 API だけに限定されるため要件を満たさない。Direct Peering は Cloud Interconnect とは別枠の公開サービス向けのピアリングで、VPC からの API 到達の手段にはならない。Cloud NAT は方向が逆でクラウドから外へ出るための機能である。

設問2

教育プラットフォームの運用チームは、利用者の増加に伴って GKE クラスタの名前解決の遅延が目立ち始めたため、名前解決の方式を見直している。候補の方式を比較した資料を作り、どれを採用するかを判断する必要がある。資料に誤った説明が含まれていると、判断を誤るおそれがある。クラスタは Standard モードで運用しており、Pod の数は数千に達している。正しい説明はどれか。（2つ選択）

kube-dns はマネージドの実装であり、Pod 数が増えてもボトルネックにならない
Cloud DNS for GKE の cluster スコープでは、クラスタ外の VM からも Service 名を解決できる
NodeLocal DNSCache は各ノード上のキャッシュとして kube-dns への問い合わせを減らす（正解）
external-DNS operator はクラスタ内部の Service 名の解決を担う
Cloud DNS for GKE はマネージドで、クラスタ内の DNS Pod が不要になる（正解）

解説

NodeLocal DNSCache は各ノード上のキャッシュ DaemonSet として kube-dns への問い合わせを減らし、Cloud DNS for GKE はマネージドでクラスタ内の DNS Pod が不要になります。kube-dns はクラスタ内の Pod による実装で、Pod 数が増えるとボトルネックになりえます。クラスタ外の VM から Service 名を解決できるのは vpc スコープです。external-DNS operator は Cloud DNS にレコードを自動で作る道具で、クラスタ内部名の解決を担うものではありません。

設問3

ある企業は、北米・欧州・アジアの各リージョンで同じ API を提供している。応答を速くするため、Cloud DNS では利用者に最も近いリージョンのエンドポイントを返したい。利用者の地域に対応する設定が無い場合は、ほかのエンドポイントへ寄せてかまわない。各リージョンのエンドポイントは、いずれも同じ内容の API を返す。どのルーティングポリシーを使うべきか。

geofencing
failover
geolocation（正解）
weighted round robin

解説

geolocation はクライアントの位置（またはリージョン）に最も近い設定のエンドポイントを返すポリシーです。failover は health check と連動して primary と backup を切り替えるポリシーです。geofencing は位置に一致するものだけを返し、近いものへのフォールバックをしません。weighted round robin は重みに応じて振り分けるポリシーで、位置を見ません。

設問4

ある製造業のセキュリティチームは、Google Cloud への移行を進めている。経営層からは、オンプレミスで長く運用してきた他社製のファイアウォール製品を、移行後もそのまま使い続けたいという要望が出ている。運用手順や監査の仕組みがその製品に依存しているためである。他社製のファイアウォール製品は、仮想アプライアンスとしても提供されている。Cloud NGFW の層の分類で、この要望に対応する選択肢はどれか。

hierarchical firewall rules に他社製品と同じ内容のルールを書き写して組織全体に適用する
regional network firewall policy を作り、他社製品と同じルールをリージョンごとに複製する
third-party integration として、NVA または Cloud NGFW Enterprise のエンドポイントを使う（正解）
VPC firewall rules をプロジェクトチームが管理し、他社製品の設定を個別のアプリ要件として写す

解説

third-party integration の適用範囲は NVA や Cloud NGFW Enterprise のエンドポイントで、既存の他社製品を使い続けたい場合に使う層である。hierarchical firewall rules は組織のセキュリティチームが全社共通の禁止事項や許可を書く層で、他社製品そのものを使い続ける手段ではない。regional network firewall policy と VPC firewall rules も Google Cloud のルールを書く層であり、いずれも他社製品の継続利用には対応しない。

設問5

ある企業のネットワークチームは、拠点との接続を Network Connectivity Center に集約するため、hybrid spoke を作成しようとしている。作成に失敗して作業が止まることがないよう、事前に満たしておく要件を確認する必要がある。スポークにする接続は、HA VPN のトンネルである。満たしておく必要がある要件はどれか。（2つ選択）

hybrid spoke をハブと同じプロジェクトに置くこと（正解）
スポークにするリソースが同一ゾーンにそろえて配置されていること
VPC の best path selection mode が standard に切り替えられていること
スポークにするリソースが、あらかじめ Cloud Router に紐づけて構成されていること（正解）
ハブのトポロジが mesh に設定されていること

解説

hybrid spoke はハブと同じプロジェクトに置き、スポークにするリソースは作成の前に Cloud Router に紐づけて正しく構成しておく必要があります。冗長性のためには同一リージョンの複数のリソースをまとめられますが、同一ゾーンという要件はありません。best path selection mode は VPC 単位の経路比較アルゴリズムの設定です。トポロジの star と mesh はスポーク同士が直接通信できるかを決めるもので、作成の要件ではありません。

続きは、会員登録なしでそのまま50問解けます。採点と解説つきで、上と同じ本物の問題です。

登録なしで50問解く

← GCP PNE の資格ページへ