Section 1 問題集 — VPC 設計と計画
各問題は実試験を意識した4択 (必要に応じ複数選択)。解答と解説は問題の直後に。
Q1
ある企業はマルチプロジェクト構成で、共通の VPC を中央のネットワーク管理チームが管理し、各開発チームが個別プロジェクトでワークロードを動かしたい。最も推奨される構成は?
A. 各プロジェクトに別々の VPC を作り、VPC Network Peering で全てを接続する
B. 全プロジェクトで Default network を使う
C. Shared VPC (host project + service projects) で構成し、subnet level で networkUser を付与する
D. プロジェクトごとに Cloud VPN で接続する
解答
C。Shared VPC は GCP がマルチプロジェクト集中管理で推奨する構成。subnet levelで roles/compute.networkUser を付与するのが原則 (project level は粒度が粗すぎる)。
Q2
3つの VPC (VPC-A, VPC-B, VPC-C) を相互に通信させたい。VPC Peering を A↔B, B↔C で張ったが、A → C が通らない。最も推奨される解決策は?
A. VPC Peering A↔C を追加する
B. Cloud VPN で全 VPC を接続する
C. Network Connectivity Center の Hub を作成し、A/B/C を VPC spoke として接続する
D. Cloud Router 経由で transitive route を有効にする
解答
C。VPC Peering は transitive 不可。3 VPC以上なら NCC で hub-spoke にするのが GCP 推奨。A も正解だがスケールしない (mesh 拡張で N² peering)。
Q3
オンプレ環境と GCP の VPC を 99.99% SLA で接続したい。最小限の構成は?
A. 1 metro / 2 attachments / 1 Cloud Router
B. 2 metros / 4 attachments / 2 Cloud Routers, global dynamic routing
C. HA VPN tunnel × 2 active/active
D. Direct Peering with BGP
解答
B。99.99% Dedicated/Partner Interconnect の要件は 2 metros、4 VLAN attachments、2 Cloud Routers、active/active、global routing mode。A は 99.9% 構成。
Q4 (複数選択)
オンプレと GCP 間の DNS 統合で、オンプレ DNS から GCP の private zone (*.gcp.example.com) を解決可能にしたい。必要な構成は2つ?
A. Cloud DNS で inbound DNS server policy を有効化
B. Cloud DNS の forwarding zone を作成
C. オンプレ DNS で *.gcp.example.com を inbound IP に conditional forward
D. Private zone を public zone に変える
解答
A, C。オンプレ → GCP 名前解決には inbound server policy で払い出される IP を、オンプレ DNS の forwarder に設定。B は GCP → オンプレ方向。
Q5
GKE クラスタの Pod IP 範囲が枯渇しそうである。最も推奨される対策は?
A. クラスタを作り直して大きな Pod range にする
B. Additional Pod ranges を追加する (PUPI や non-RFC1918 も可)
C. NAT で複数 Pod を 1 IP に集約する
D. ノード数を減らす
解答
B。gcloud container clusters update --additional-pod-ipv4-ranges で追加可能。非中断で対応できる。
Q6
2 つの VPC が同じ CIDR (10.0.0.0/16) を使用しており、統合したい。最も推奨される解決策は?
A. 片方の VPC を作り直して別 CIDR に変更
B. VPC Network Peering を貼って ECMP で振り分け
C. NCC の hybrid spoke で Private NAT を経由させ、重複 IP を解決
D. すべての VM の IP を手動で再アサイン
解答
C。Private NAT (NCC) は重複 IP 問題のための公式ソリューション。A も論理的には可能だが、運用コストが大。
Q7
Shared VPC 環境で、service project の開発者が host project の subnet を使って VM を起動できない。最も可能性が高い原因は?
A. host project に roles/compute.xpnAdmin が無い
B. service project に roles/compute.networkAdmin が無い
C. 開発者の service account に subnet レベルの roles/compute.networkUser が付与されていない
D. VPC Peering が必要
解答
C。Shared VPC 利用で最頻のミス。subnet レベルで networkUser を付与すべき。
Q8
GKE control plane への kubectl アクセスを、ファイアウォール穴あけや VPN 経由なしに、IAM で制御したい。最新の推奨方式は?
A. Public endpoint + Authorized networks
B. Private endpoint + master global access
C. DNS-based endpoint for control plane
D. Cloud VPN + Authorized networks
解答
C。DNS-based endpoint は最新の推奨。公開 IP 不要、IAM 認証のみで kubectl 可能。
Q9
高速かつ低レイテンシに加え、リージョン間冗長で 99.99% SLA が必要。AWS と GCP を直接接続する必要がある。最も推奨される接続方式は?
A. Cloud VPN with HA configuration
B. Cross-Cloud Interconnect (2 metros 構成)
C. Direct Peering with BGP
D. Public Internet via NAT
解答
B。Cross-Cloud Interconnect は他クラウドへの物理回線接続。99.99% SLA も 2 metros 構成で実現可能。
Q10
VPC 内の MTU を 1500 から 8896 (jumbo) に変更したい。最も適切な手順は?
A. gcloud compute networks update --mtu=8896
B. すべての VM の interface MTU を変更
C. VPC を作り直して MTU=8896 で再作成する
D. Cloud Router の MTU を上げる
解答
C。VPC の MTU は 作成時のみ設定可能。変更は再作成が必要 (もしくは新規 VPC を作って移行)。