WEB問題集
大手金融グループの基盤刷新で、本番／開発／監査の三系統を単一の Google Cloud 組織配下に集約する計画が進行中です。本番ワークロードは複数チームが同居しますが、ネットワーク管理はネットワーク中央部門が一元管理し、利用部門にはサブネット単位での起動権限のみ与える要件があります。各サービスプロジェクトでは独自の課金分離と IAM 境界を維持しつつ、共通の VPC ルーティングテーブルとファイアウォール基盤を共有する必要があります。最小の運用コストで要件を満たすには、どのネットワーク設計を採用すべきですか。
正解：B
正解の根拠
Shared VPC はホストプロジェクトにネットワーク資産を集約し、サービスプロジェクトに対しサブネット粒度で compute.networkUser を付与できる仕組みであり、中央集権の運用と利用部門の自律性を両立できます。
| 方式 | 中央管理 | 課金分離 | 運用負荷 |
|---|---|---|---|
| Shared VPC | 容易 | 可能 | 低 |
| VPC Peering | 分散 | 可能 | 高 |
| NCC ハブ | 中程度 | 可能 | 中 |
不正解の理由
- A: VPC Peering は推移ルーティング非対応で N×N の管理が必要なため運用負荷が増大します。
- C: NCC は主にハイブリッドや異 VPC 連携が目的で、サブネット委譲の要件には合致しません。
- D: 単一プロジェクトでは課金分離と IAM 境界を維持できず、要件を満たせません。
製造業のグローバル展開で、北米／欧州／アジアの三リージョンに同一サービスを配置する計画があります。事業要件として、リージョンを跨いだ内部通信は Google のバックボーン経由で完結させ、各拠点のサブネットアドレスを将来の M&A に備えて 10 年単位で重複なく拡張できるようにしたいと考えています。さらに、Google が自動付与する既定サブネットは監査ポリシー違反になります。最初に採用すべき VPC 設計はどれですか。
正解：B
正解の根拠
Custom Mode VPC は単一のグローバル VPC として全リージョンを跨ぎ、各サブネットアドレスを明示的に計画できるため、重複回避と監査要件の双方を満たせます。リージョン間通信は Google バックボーン経由で完結します。
| 項目 | Auto Mode | Custom Mode |
|---|---|---|
| サブネット自動付与 | あり | なし |
| アドレス計画の自由度 | 低 | 高 |
| 監査適合 | 困難 | 容易 |
不正解の理由
- A: Auto Mode の自動付与は固定範囲のため自由な再設計には不向きです。
- C: VPC Peering は管理コストが高く、単一 VPC で済む要件には過剰です。
- D: Default VPC は監査違反となるうえ Cloud VPN は Google バックボーン要件と整合しません。
SaaS スタートアップが、開発者数が 6 か月で 3 倍に増加する見込みで、東京リージョンの一つのサブネットに Compute Engine と GKE Pod／Service の三層構成を配置しようとしています。Pod CIDR と Service CIDR は将来の拡張に備えて余裕を持ち、ノード側のホスト用範囲とは衝突しないように設計したい状況です。どの設計が最も適切ですか。
正解：A
正解の根拠
VPC ネイティブな GKE では、サブネットのプライマリ範囲をノードに、セカンダリ範囲を Pod と Service にそれぞれ割り当てることで、衝突なく拡張可能な設計が可能になります。alias IP により Pod IP は VPC で直接ルーティングされます。
| 範囲 | 用途 | 備考 |
|---|---|---|
| プライマリ | ノード | 必須 |
| セカンダリ A | Pod | 大きめに確保 |
| セカンダリ B | Service | クラスタ全体共有 |
不正解の理由
- B: 経路ベース型は新規非推奨で、Cloud NAT 共有は Pod 直接到達性を満たしません。
- C: VPC を分割すると Pod ルーティングが複雑化し、必要のない設計上の負債となります。
- D: Auto Mode の自動範囲は計画的なセカンダリ確保ができず将来拡張に不向きです。
金融子会社のセキュリティ部門から、本番 VPC と DMZ VPC を完全に分離した上で、双方向に推移ルートを発生させず、共通の Network Virtual Appliance 経由で全トラフィックを検査したいという要望が出されました。VPC は同一組織配下に複数存在し、将来的にも増減します。設計として最も適切なのはどれですか。
正解：B
正解の根拠
Network Connectivity Center の VPC スポーク機能は、複数 VPC をハブにアタッチしてフルメッシュ的なルーティング基盤を提供しつつ、検査用スポークを介したセキュリティチェイニングが可能です。VPC Peering と異なり推移経路を統制できます。
| 方式 | 推移経路 | 検査統合 |
|---|---|---|
| NCC ハブ | 制御可能 | 容易 |
| VPC Peering | 非対応 | 困難 |
| Shared VPC | 単一 VPC 内 | 分離不可 |
不正解の理由
- A: VPC Peering は推移ルーティングをサポートせず多 VPC では破綻します。
- C: VPC 統合は要件である完全分離に反します。
- D: VPN は VPC 間接続として非推奨かつスケールしません。
大学病院の研究系システムを Google Cloud に移行する計画で、患者情報を扱う閉域系と、論文公開用のインターネット系を同一組織内で運用します。閉域系のサブネットからは外部 IP を持たない VM が Google API へ到達できる必要があり、また将来的に IPv6 にも対応する余地を残したいと考えています。どの設計が最適ですか。
正解：A
正解の根拠
プライベート Google アクセスを有効化すると、外部 IP を持たない VM でも Google API への閉域到達が可能になります。Custom Mode の内部 IPv6 オプションは将来の二重スタック対応にも備えられます。
| 機能 | 外部 IP 要否 | IPv6 設計余地 |
|---|---|---|
| Private Google Access | 不要 | あり |
| Cloud NAT | 不要 | 限定的 |
| 外部 IP 直付け | 必要 | 不向き |
不正解の理由
- B: 外部 IP の運用切替は閉域要件の趣旨に反します。
- C: Cloud NAT 経由は経路上インターネットを介し閉域要件を満たしません。
- D: Direct Peering は VPC 内 VM の Google API 到達手段としては推奨されません。