【PCNE】WEB問題集:VPC実装編

正解：A

正解の根拠

カスタムモードの VPC を作成すると、サブネットは自動生成されず、管理者が CIDR とリージョンを個別に決められるため、要件である「自分で CIDR を決定」「段階的にリージョン追加」「自動範囲予約の回避」を同時に満たせます。さらに --bgp-routing-mode=global を指定しておくことで、後段で Cloud Router を導入した際にリージョンをまたいで動的ルートを伝播できる構成になります。

VPC サブネットモード比較

サブネットを後で追加する手順

1. VPC をカスタムモードで作成します。
2. gcloud compute networks subnets create でリージョン別に CIDR を割り当てます。
3. 必要に応じて Alias IP 用のセカンダリ範囲を追加します。

作成コマンド例

gcloud compute networks create prod-vpc 
  --subnet-mode=custom 
  --bgp-routing-mode=global

gcloud compute networks subnets create web-asia-ne1 
  --network=prod-vpc 
  --region=asia-northeast1 
  --range=10.10.0.0/20

不正解の理由

• B: auto-mode は 10.128.0.0/9 を全リージョンに自動展開するため、CIDR 自由決定および範囲予約回避の要件を満たせません。
• C: legacy モードはサブネット概念を持たない旧形式であり、新規作成は推奨されず Cloud Router 等の現行機能と整合しません。
• D: サブネットモードを省略すると auto がデフォルト適用されるため、要件と相反する自動 CIDR 割当が発生してしまいます。

参考：VPC ネットワーク概要

正解：B

正解の根拠

Google Cloud の VPC は auto-mode から custom-mode への変換は可能ですが、逆方向の変換はサポートされていません。これは、custom-mode で任意 CIDR のサブネットを追加してしまうと、auto-mode の固定 10.128.0.0/9 マップと整合性が取れなくなるためです。したがって変換は一方向であり、サブネットは以後手動管理となります。

変換手順

gcloud compute networks update default 
  --switch-to-custom-subnet-mode

変換可否の比較

不正解の理由

• A: 変換は非可逆であり、custom-mode から auto-mode への復帰機能は提供されていないため、戻すには VPC を新規作成する必要があります。
• C: 既存サブネットの CIDR は変換時に維持されるため、自動再採番は発生せず IP 体系は連続性を保ちます。
• D: VM が稼働中でも変換は可能であり、業務影響を抑えつつ非中断で切替えできる点が運用上の利点です。

参考：auto-mode から custom-mode への変換

正解：C

正解の根拠

GKE の VPC ネイティブクラスタでは、Node IP がサブネットのプライマリ範囲から、Pod IP と Service IP がそれぞれセカンダリ範囲から払い出されます。Terraform の google_compute_subnetwork ではプライマリ範囲 (ip_cidr_range) を 1 つ定義し、Pod / Service 用に secondary_ip_range ブロックを 2 つ追加する構成が標準的です。

Terraform 構成例

resource "google_compute_subnetwork" "gke" {
  name          = "gke-subnet"
  network       = google_compute_network.vpc.id
  region        = "asia-northeast1"
  ip_cidr_range = "10.10.0.0/20"

  secondary_ip_range {
    range_name    = "pods"
    ip_cidr_range = "10.20.0.0/14"
  }
  secondary_ip_range {
    range_name    = "services"
    ip_cidr_range = "10.24.0.0/20"
  }
}

範囲ごとの役割

不正解の理由

• A: プライマリ範囲のみでは Pod / Service 用の独立した範囲が確保できず、Alias IP の前提となるセカンダリ範囲が不足します。
• B: 1 サブネットに 2 つのプライマリ範囲は定義できず、プライマリは常に 1 つで他はセカンダリとして扱う設計になっています。
• D: プライマリ範囲を省略するとサブネット自体が成立せず、Node IP の払い出し元が無くなるため作成に失敗します。

参考：Alias IP 範囲

正解：D

正解の根拠

Google Cloud の VPC サブネットでは、--stack-type=IPV4_IPV6 と --ipv6-access-type の組合せで IPv6 の振舞いを決めます。内部限定で外部到達不要であれば INTERNAL を選択し、ULA (fd20::/20 由来) 範囲の IPv6 が割当てられます。これにより同一 VPC や VPC ピアリング先との通信に閉じられ、インターネットには到達しません。

IPv6 アクセスタイプ比較

追加コマンド例

gcloud compute networks subnets update web-subnet 
  --region=asia-northeast1 
  --stack-type=IPV4_IPV6 
  --ipv6-access-type=INTERNAL

不正解の理由

• A: EXTERNAL タイプは GUA を割当ててインターネットへ直接到達できる構成のため、内部限定の要件には過剰な公開リスクを伴います。
• B: IPV6_ONLY スタックは Preview の限定機能であり、既存 IPv4 通信が遮断されるため通常のワークロードでは選択しません。
• C: PRIVATE_NAT 用 purpose は Cloud NAT 専用サブネットを示すフラグであり、IPv6 通信の有効化とは独立した設定です。

参考：サブネット IPv6 範囲

正解：C

正解の根拠

VPC の静的ルートと動的ルートが衝突する場合、ロンゲストプレフィックスマッチが優先され、同一プレフィックス長では priority 値の小さい方が優先されます。動的ルート (BGP 学習) のデフォルト priority は通常 100 前後ですが、対象 VM をネクストホップにする静的ルートを priority 100 で追加し、より具体的な /24 を指定すれば、ロンゲストマッチで静的ルートが選ばれます。

静的ルート定義例

gcloud compute routes create to-onprem-gw 
  --network=prod-vpc 
  --destination-range=192.168.50.0/24 
  --next-hop-instance=gw-vm-1 
  --next-hop-instance-zone=asia-northeast1-a 
  --priority=100

ルート選択順序

不正解の理由

• A: advertised prefix は VPC から外への広告制御であり、内向きトラフィックを別 VM にリダイレクトする要件には合致しません。
• B: ルーティングモード変更はリージョン間学習スコープの設定であり、特定プレフィックスの優先制御を行う機構ではありません。
• D: デフォルトルート優先度の引下げは全インターネット向けトラフィックの挙動を変えてしまい、副作用が大きすぎる対処になります。

参考：VPC ルート