Professional Cloud Network Engineer
Professional Cloud
Network Engineer
完全試験対策ガイド
ネットワーク初学者から中級者まで対応。VPC設計からハイブリッド接続、ロードバランシング、セキュリティ、監視まで、試験に出るすべての技術領域をステップバイステップで解説します。
◆ 試験時間: 120分◆ 問題数: 50〜60問◆ 受験料: $200◆ 推奨経験: 3年以上◆ 更新: 2年ごと
🌐 VPC 設計🔗 ハイブリッド接続⚖️ ロードバランシング🖧 ネットワークサービス🛡️ セキュリティ🔍 監視・トラブルシュート
INTRO
試験の全体像と準備方法
PCNEは、Google Cloudのネットワークインフラを設計・実装・管理・最適化する能力を証明する上級資格です。単なる操作知識でなく、アーキテクチャ設計の判断力が問われます。
出題セクション別 配点
S1: VPCネットワーク設計~21%
S2: ハイブリッド接続・ネットワーク相互接続~23%
S3: ロードバランシングとトラフィック管理~19%
S4: CDN・DNS・IPアドレス管理~15%
S5: ネットワークセキュリティの設計と実装~12%
S6: ネットワーク操作と監視~10%
推奨学習ステップ
1
公式試験ガイドを熟読する（必須）
試験範囲の正式定義を確認。本ガイドと照らし合わせながら学習計画を立てる。
2
Cloud Skills Boost のPCNEラーニングパスを修了
体系的な動画学習と実践演習。GCPのネットワーキング基礎から始められる。
3
ハンズオンラボで実際に操作する
VPC・Cloud VPN・Cloud Interconnect・ロードバランサーの実際の構築体験が合否を分ける。
4
公式サンプル問題・模擬試験で実力測定
弱点を可視化して集中補強。シナリオベースの設問形式に慣れる。
5
弱点分野を公式ドキュメントで補強して試験登録
本ガイドの各セクションの「参照URL」から公式ドキュメントを直接確認する。
Section 1 (21%)
VPC ネットワークの設計・実装
Google Cloud のネットワーク基盤である VPC (Virtual Private Cloud) の設計原則、 IPアドレス管理、ルーティング、ファイアウォール、通信制御（Private Google Access, Cloud NAT, PSC）について学びます。
1.1 VPCの根本概念 ─ グローバルスコープとモード選択
Google Cloud の VPC は AWS や Azure とは異なり、グローバルリソースです。サブネットのみがリージョナルリソースとなります。
| 比較要素 | Auto モード（自動） | Custom モード（カスタム） |
|---|---|---|
| サブネット作成 | 各リージョンに自動作成（10.128.0.0/9 を分割） | 手動でIPレンジを指定して作成（試験の推奨・実運用向け） |
| IPの重複リスク | オンプレミスや他VPCとVPN接続時に重複しやすい | 設計者がレンジを管理するため重複を防げる |
| 変更可能か？ | Auto → Custom への変換は可能 | Custom → Auto への変換は不可 |
試験対策「会社がオンプレミス環境とVPN/Interconnectで接続する予定である」という要件があれば、「Custom モード」の VPC を選択し、オンプレのIPレンジと重複しないサブネットを設計するのが正解です。
1.2 VPCファイアウォールルール ─ ステートフル・優先度・階層型ポリシー
GCP のファイアウォールルールはステートフルであり、許可した上り（Ingress）トラフィックの戻り（Egress）は自動的に許可されます。
- 適用先（Target）の指定方法：
- タグ（Network Tags）： VM インスタンスに直接付与。手軽だが文字列ベースなので運用ミスに注意。
- サービスアカウント（推奨）： インスタンスに関連付けられたサービスアカウントをターゲットとする。IAM で厳密に管理でき、セキュリティレベルが高い。
- 優先度（Priority）：
0（最高）〜65535（最低）。デフォルトルールは1000ではなく65534（暗黙のルールが65535）。
階層型ファイアウォールポリシー（Hierarchical Firewall Policies）
- VPC 単位ではなく、組織（Organization）またはフォルダ（Folder）レベルで適用可能。
- 配下の全プロジェクト・全 VPC に一括適用されるため、「社内共通のセキュリティ要件（例：全社で SSH は特定 IP からのみ許可）」を強制するのに最適。
- 各プロジェクトの管理者が VPC ルールで「許可」しても、上位のフォルダレベルで「拒否」されていれば上位が優先（上書き）される。
1.3 VPCピアリング vs Shared VPC ─ 設計パターンの選択
複数のプロジェクトや VPC 間をどう接続するかは PCNE の最頻出トピックです。
| 機能 | VPC ピアリング (VPC Peering) | 共有 VPC (Shared VPC) |
|---|---|---|
| 主な用途 | 異なる組織間、または独立性の高い部署間の接続 | 単一組織内で、ネットワーク管理を中央集権化しつつ、リソース管理は各部署（プロジェクト）に委譲したい場合 |
| 推移的ルーティング (Transitive Routing) | サポートしない（A-B, B-C は通信できても、A-C は通信不可） | 同じホストプロジェクトの同一VPCに所属すれば通信可能 |
| 管理の所在 | 各VPCの管理者がそれぞれのルーティングを管理 | ホストプロジェクトの管理者がサブネット・FWを一元管理し、サービスプロジェクトに権限を委譲 |
| オンプレへのVPN共有 | ピアリングの設定で「カスタムルートのエクスポート/インポート」を有効にすれば可能 | ホストプロジェクトで構築したVPNを全サービスプロジェクトで自動共有 |
試験対策「ネットワークチームがサブネットやファイアウォールを一元管理し、開発チームはVMの作成のみを行えるようにしたい」という要件は、Shared VPC（共有VPC）を構築するのが絶対の正解パターンです。
1.4 プライベート通信制御 ─ Cloud NAT・PGA・PSC
外部IPを持たない VM が外部や Google API とどうやって通信するか、使い分けが問われます。
Cloud NAT
内部IPのみのVMがインターネットにアクセス（OSのアップデートや外部APIの呼び出し）するためのマネージドサービス。
※ インターネットからVMへの受信通信（Ingress）は不可。
Private Google Access
内部IPのみのVMがGoogle API（Cloud Storage や BigQuery など）にアクセスするための機能。インターネットを経由せず、Google 内部網を通る。サブネット単位で有効化する。
Private Service Connect
自社で公開したサービスや、他社・サードパーティのマネージドサービス（MongoDBやElasticなど）を、自VPCのプライベートIPエンドポイントとしてマッピングし、VPCピアリングなしで接続する最新手法。
💡 PSA (Private Services Access) との違い：PGA は「Google の公開API」へアクセス。PSA (Private Services Access) は「Cloud SQL」などのマネージドサービスに対し、VPCピアリングを使って専用のプライベートIP範囲で接続する手法です。
Section 2 (23%)
ハイブリッド接続とネットワーク相互接続
試験最大配点（約23%）のセクション。Cloud VPN・Interconnect・Cloud Routerの選択基準と設定方法、SLAの違いが頻出。シナリオベースで「どの接続方式を選ぶか」が問われます。
2.1 接続方式の全体比較 ─ 帯域・コスト・SLAで選択する
| 接続方式 | 帯域幅 | SLA | 推奨場面 |
|---|---|---|---|
| HA VPN | 最大 3Gbps/トンネル | 99.99% | 帯域が少なく、コスト優先の場合 |
| Classic VPN | 最大 3Gbps/トンネル | 99.9% | 新規非推奨 |
| Partner Interconnect | 50Mbps〜50Gbps | 99.9〜99.99% | Googleコロケ外・小〜中帯域 |
| Dedicated Interconnect | 10G / 100G × 最大8回線 | 99.9〜99.99% | 大帯域・低レイテンシ必須 |
試験対策① 大帯域（数十Gbps以上）+ 低レイテンシ必須 → Dedicated Interconnect
② Googleコロケ施設に物理接続できない → Partner Interconnect
③ コスト優先・帯域が3Gbps以下で十分 → HA VPN
④ Classic VPNは新規構築で使わないこと（99.9% SLAのみ）
② Googleコロケ施設に物理接続できない → Partner Interconnect
③ コスト優先・帯域が3Gbps以下で十分 → HA VPN
④ Classic VPNは新規構築で使わないこと（99.9% SLAのみ）
2.2 HA VPN ─ 99.99% SLAを実現する高可用性VPN設計
HA VPN（High Availability VPN）は99.99% SLAを提供します。2つの独立したインターフェースに2本のトンネルを張り、BGPで動的ルーティングを行います。
ベストプラクティス
- 新規VPN構築は必ずHA VPNを使用（Classic VPNは非推奨）
- IKEv2を使用（IKEv1より安全で効率的）
- BGP（動的ルーティング）を必ず設定する（静的ルートは管理コストが高い）
- 帯域不足の場合はECMP（等コストマルチパス）でトンネルをスケールする
2.3 Cloud Interconnect ─ 専用線による99.99%冗長設計
Dedicated InterconnectはGoogleのコロケーション施設に物理的に直接接続する専用線サービスです。10Gbps/100Gbps単位で回線を確保します。
99.99% SLA冗長構成（本番環境必須）
Metro-A が完全停止してもMetro-Bで継続 = 99.99% SLA（異なる2 Metro × 2回線 = 合計4回線）
同一Metro内2本のみ = 99.9% SLA（非推奨）
Metro-A が完全停止してもMetro-Bで継続 = 99.99% SLA（異なる2 Metro × 2回線 = 合計4回線）
同一Metro内2本のみ = 99.9% SLA（非推奨）
VLAN Attachmentとは
1本の物理専用線を論理的に複数に分割する仕組み（VLAN）。各アタッチメントが1つのVPCに対応し、1本の回線で複数のVPCに接続できます。
2.4 Cloud Router と BGP ─ 動的ルーティングの仕組みと設定
Cloud RouterはBGPセッションを管理し、オンプレとGCP間でルートを自動交換します。データプレーンのトラフィック自体は通過しません（コントロールプレーンのみ）。
| モード | ルートの適用範囲 | 用途 |
|---|---|---|
| Regional | 学習したルートを同一リージョンのサブネットにのみ適用 | リージョン内に閉じた構成・コスト最適化 |
| Global（推奨） | 全リージョンの全サブネットに学習ルートを反映 | マルチリージョン構成・HA設計 |
💡 BGP MED (Multi-Exit Discriminator)複数のBGPパスがある場合に、どのパスを優先するかを制御する属性。MEDが小さい方が優先されます。アクティブ/スタンバイの制御に活用します。
Section 3 (~19%)
ロードバランシングとトラフィック管理
約19%を占める重要セクション。6種類のLBを状況に応じて選択できるかが問われる。Global vs Regional、Proxy型 vs Passthrough型の違いが最重要。
3.1 ロードバランサー選択の決定フロー
主要ロードバランサー比較表
| LB名 | スコープ | レイヤー | プロトコル | Cloud Armor | クライアントIP |
|---|---|---|---|---|---|
| Global External HTTP(S) LB | グローバル | L7 | HTTP/HTTPS/HTTP2/gRPC | ✓ 対応 | X-Forwarded-For |
| Regional External HTTP(S) LB | リージョン | L7 | HTTP/HTTPS | ✓ 対応 | X-Forwarded-For |
| External TCP/SSL Proxy LB | グローバル | L4 Proxy | TCP / SSL | ✗ 不可 | Proxy Protocol |
| External Network LB | リージョン | L4 Pass | TCP / UDP | ✗ 不可 | ネイティブ保持 |
| Internal HTTP(S) LB | リージョン | L7 | HTTP/HTTPS | ✓ 対応 | X-Forwarded-For |
| Internal TCP/UDP LB | リージョン | L4 Pass | TCP / UDP | ✗ 不可 | ネイティブ保持 |
試験頻出⚠Cloud ArmorはProxy型LBにのみ対応します。Passthrough型（Network LB, Internal TCP/UDP）には使えません。クライアントIPを保持したい場合はNetwork LBを選びますが、DDoS/WAF保護はできません。
3.2 Global External HTTP(S) LB ─ URLMapとNEGの設計
コンポーネント構成
1
Forwarding Rule
外部IPとポート（80/443）を定義。グローバルIPの場合はAnycastとして機能。
2
Target HTTP(S) Proxy
SSL証明書を管理し、URL Mapにトラフィックを渡す。HTTPSの場合はSSL終端もここで行う。
3
URL Map
ホスト名・URLパスに基づいてバックエンドサービスへルーティング。高度なトラフィック制御が可能。
4
Backend Service + Health Check
バックエンド（MIG・NEG・GCS）の設定と死活監視。セッション維持・タイムアウト設定もここで行う。
NEG（Network Endpoint Groups）の種類
| NEGの種類 | エンドポイント | 主な用途 |
|---|---|---|
| Zonal NEG | GKE Pod・特定ゾーンのVM | GKEとの統合（コンテナへの直接転送） |
| Serverless NEG | Cloud Run・Cloud Functions・App Engine | サーバーレスサービスをLBのバックエンドに |
| Internet NEG | オンプレ・他クラウドのエンドポイント | ハイブリッドLB構成 |
| Hybrid NEG | Interconnect/VPN経由の外部エンドポイント | オンプレサービスへの転送 |
✅ ベストプラクティス
- マルチリージョンバックエンドで高可用性を実現する
- Cloud CDNと組み合わせて静的コンテンツをキャッシュする
- Cloud ArmorでWAF・DDoS保護を必ず有効化する
- SSL PolicyでTLS 1.2以上を強制する（古いバージョンを無効化）
- Google管理SSL証明書（Managed Certificate）を使用して自動更新する
- ヘルスチェックのIPレンジ（
35.191.0.0/16,130.211.0.0/22）をFWルールで許可する
Section 4 (~15%)
CDN・DNS・IPアドレス管理
約15%を占めるセクション。Cloud DNSのゾーン種別と転送設定、IPアドレスのエフェメラル/静的の違い、グローバル/リージョンのスコープが頻出。
4.1 Cloud DNS ─ パブリック/プライベートゾーンと転送設定
| ゾーン種別 | 公開範囲 | 用途 | アクセス元 |
|---|---|---|---|
| パブリックゾーン | インターネット全体 | 外部公開ドメインのDNS管理 | 誰でも |
| プライベートゾーン | 指定VPCのみ | 内部サービスのDNS解決 | 紐づけたVPCのみ |
DNS転送の2方向
DNSピアリング
複数VPC間でプライベートゾーンを共有できます。ハブ＆スポーク構成でHub VPCのDNSをスポークVPCから参照する際に活用します。
✅ ベストプラクティス
- 内部サービスはプライベートゾーンでDNS管理を集中化する
- DNSピアリングでVPC間の名前解決を統合する
- 転送ゾーンでオンプレのDNSと統合する
- パブリックゾーンはDNSSECで完全性を保護する
- 変更頻度に応じてTTLを適切に設定する（短すぎるとDNSトラフィック増加）
4.2 IPアドレス管理 ─ エフェメラル・静的・グローバル・リージョン
| 種別 | 永続性 | コスト | 用途 |
|---|---|---|---|
| エフェメラルIP | VM停止・削除で変わる | 追加コストなし | 開発・テスト環境 |
| 静的IP（リージョン） | 予約して永続化 | 未使用時に課金あり | リージョンLB・VM・Cloud NAT |
| 静的IP（グローバル） | 予約して永続化 | 未使用時に課金あり | Global LB（Anycast） |
注意⚠静的IPを予約したままVMやLBに割り当てていない場合、課金が発生します。使わない静的IPは解放してください。
Section 5 (~12%)
ネットワークセキュリティ設計と実装
約12%を占めるセクション。Cloud Armor・VPC Service Controls・IAP・SSL/TLSの組み合わせが頻出。「どのサービスを使えばデータ漏洩を防げるか」が問われる。
5.1 Cloud Armor ─ WAF・DDoS・Rate Limiting・Adaptive Protection
🛡
DDoS防御
L3/L4のボリューム攻撃（SYN Flood・UDP Flood）をGoogleインフラレベルで自動緩和。ユーザー設定不要。
🔍
WAF（L7）
SQLインジェクション・XSSなどOWASPトップ10対策。事前設定ルール（Preconfigured Rules）を有効化するだけ。
⚡
Rate Limiting
単一IPからの過剰リクエストを制限。スロットリング（503）またはリダイレクトで対応。大量リクエスト攻撃に有効。
🤖
Adaptive Protection
AIがトラフィックパターンを分析し、L7 DDoS攻撃を自動検出して防御ルールを推奨。有効化を強く推奨。
# セキュリティポリシー作成
gcloud compute security-policies create my-security-policy \
--description="WAF and DDoS protection policy"
# OWASP SQLインジェクションルール追加
gcloud compute security-policies rules create 300 \
--security-policy=my-security-policy \
--expression="evaluatePreconfiguredWaf('sqli-v422-stable')" \
--action=deny-403
# 特定IPをブロック
gcloud compute security-policies rules create 100 \
--security-policy=my-security-policy \
--src-ip-ranges=1.2.3.4/32 \
--action=deny-403
# バックエンドサービスにポリシーを適用
gcloud compute backend-services update my-backend \
--security-policy=my-security-policy \
--global
💡 プレビューモードを活用本番環境に適用する前に
--action=deny-403を--action=allow --previewに変えてログを確認し、正規トラフィックがブロックされないかをテストします。✅ ベストプラクティス
- 全外部LBにCloud Armorセキュリティポリシーを適用する（必須）
- Adaptive Protectionを有効化してAI自動検出を活用する
- OWASPの事前設定ルールをすべて有効化する
- 本番適用前にプレビューモードで誤ブロックを確認する
- ログを有効化してアタックパターンを継続的に分析する
5.2 VPC Service Controls ─ データ漏洩（Exfiltration）防止
VPC Service Controls（VPC SC）は、GCPのAPIサービス（BigQuery・GCS・KMS等）の周囲に仮想的なセキュリティ境界を作成し、境界外からのAPIアクセスを遮断します。IAMだけでは防げないデータの持ち出しを防止します。
ℹ アクセスレベルで例外を許可境界外のユーザー・システムに条件付きアクセスを許可できます。条件例：特定のIPレンジ、MFA使用済み、特定のデバイス状態（Access Context Manager）。
✅ ベストプラクティス
- 機密データ（個人情報・金融データ）を扱うプロジェクトに必ず適用する
- まずドライランモードで境界を設定し、正規トラフィックへの影響を確認する
- Access Context Managerでアクセスレベルを細かく管理する
- Ingress/Egressポリシーで必要な例外のみ許可する
5.3 Identity-Aware Proxy（IAP）─ VPNなしのゼロトラストアクセス
IAPを使えばパブリックIPを持たないVMにも、VPNなしで安全にSSH/RDP接続できます。Google Accountと IAMで認証・認可を一元管理します。
# IAP経由でSSH接続（ポート22を外部に開けない！）
gcloud compute ssh my-vm \
--tunnel-through-iap \
--project=my-project \
--zone=us-central1-a
# 必要なFWルール: IAPのCIDR範囲のみSSHを許可
gcloud compute firewall-rules create allow-iap-ssh \
--network=my-vpc \
--action=ALLOW \
--rules=tcp:22 \
--source-ranges=35.235.240.0/20 \
--target-tags=iap-ssh-target
✅ ベストプラクティス
- SSH/RDPは外部からの直接アクセスを廃止し、IAP経由のみに限定する
- 管理画面・内部ツールへのアクセスはすべてIAPで保護する
- BeyondCorp Enterpriseと統合してデバイス状態・場所を条件に追加する
- IAPのIPレンジ（35.235.240.0/20）以外からのSSHを全拒否する
Section 6 (~10%)
ネットワーク監視・トラブルシューティング
約10%を占めるセクション。Network Intelligence Centerの5ツール、VPC Flow Logs、Packet Mirroringの使い方と使い分けが問われる。
6.1 Network Intelligence Center ─ 5つの診断ツール
🔌
Connectivity Tests
2点間の接続性を仮想的なパケットトレースで分析。FW・ルート・NATの問題を即特定。実際にパケットを送らないのがポイント。
📊
Performance Dashboard
ゾーン間・リージョン間のレイテンシ・パケット損失をリアルタイム表示。Googleの基準値との比較も可能。
🔎
Firewall Insights
使われていないFWルールを検出。Shadow Rules（上位ルールに隠れているルール）の発見。過剰権限の整理に活用。
🌐
Network Topology
VPC・サブネット・VMの接続関係を可視化。トラフィックフロー・帯域使用量を直感的に把握できる。
⚙️
Network Analyzer
VPCネットワーク設定を自動分析。問題点・ベストプラクティス違反を自動検出し、改善推奨を提示。
6.2 VPC Flow Logs・FWログ・Packet Mirroring ─ 使い分け
| ツール | 何を記録するか | 主な用途 | コスト |
|---|---|---|---|
| VPC Flow Logs | サブネット内の全トラフィック（サンプリング） src/dst IP・ポート・バイト数 | セキュリティ監査・コスト分析・コンプライアンス | サンプリングレートと容量に比例 |
| FWルールログ | FWルールに一致したトラフィックのALLOW/DENY | FWデバッグ・セキュリティ侵害調査 | ルールごとに有効化 |
| Packet Mirroring | 対象VMの全パケット内容（コピー） | IDS・深層パケット検査・詳細デバッグ | 高（全パケットコピー） |
# VPC Flow Logsの有効化（サブネット単位）
gcloud compute networks subnets update my-subnet \
--enable-flow-logs \
--logging-aggregation-interval=INTERVAL_5_SEC \
--logging-flow-sampling=0.5 \ # 50%サンプリング
--logging-metadata=INCLUDE_ALL_METADATA \
--region=us-central1
トラブルシューティング手順（試験頻出）
1
Connectivity Testで問題箇所を絞り込む
仮想パケットトレースでFW・ルーティング・NATのどこで問題が発生しているか確認する。
2
FWルールを確認（ログを参照）
送信元/宛先のIP・ポートが許可されているか確認。暗黙のDENYに引っかかっていないかを確認。
3
ルーティングを確認
正しいネクストホップにルートが設定されているか確認。VPN/Interconnectトンネルがアップか、BGPセッションが確立しているかを確認。
4
アプリケーション側を確認
サービスが起動しているか、正しいポートでリスニングしているか、ヘルスチェックを通過しているかを確認。
SUMMARY
試験攻略チートシート ─ 頻出サービス早見表
試験直前に確認すべきキーワードとサービスの紐付けを一覧にまとめました。
| サービス | 最重要キーワード | 主な用途 | よく混同されるポイント |
|---|---|---|---|
| VPC | グローバルスコープ / Custom Mode | ネットワーク基盤 | VPCはグローバル、サブネットはリージョン |
| Shared VPC | Host Project / Service Project / 集中管理 | 企業内ネットワーク統合 | 異組織間はVPC Peering（Shared VPCは同一組織のみ） |
| VPC Peering | 推移的ルーティング不可 / CIDR重複不可 | VPC間プライベート通信 | A-B-CでAとCは通信不可（推移的ルーティング禁止） |
| HA VPN | 99.99% SLA / BGP必須 / 2トンネル | オンプレとの暗号化接続 | Classic VPN は99.9% SLA（新規非推奨） |
| Dedicated IC | 専用線 / 10G or 100G / Meet-Me Location | 大帯域オンプレ接続 | Googleコロケ施設に直接接続できない場合はPartner IC |
| Cloud Router | BGP / 動的ルーティング / データ通過なし | ルート交換エンジン | データプレーンは通過しない（コントロールプレーンのみ） |
| Cloud NAT | アウトバウンドのみ / 外部IP不要 | プライベートVM→インターネット | インバウンド接続は絶対に不可 |
| Global HTTP(S) LB | L7 / Anycast / URL Map / CDN連携 | Webアプリグローバル配信 | Cloud ArmorはProxy型のみ対応 |
| Network LB | L4 Passthrough / クライアントIP保持 | 非HTTP・UDP・クライアントIP必要 | Cloud Armor使用不可（Passthrough型のため） |
| Cloud Armor | WAF / DDoS / OWASP / Rate Limiting | Webセキュリティ | 外部Application LBにのみ適用可能 |
| VPC SC | Service Perimeter / データ漏洩防止 / Exfiltration | 高セキュリティ環境のAPI保護 | IAMだけでは防げないデータ持ち出しを防ぐ |
| IAP | VPNなし / ゼロトラスト / 35.235.240.0/20 | セキュアな管理アクセス | 踏み台サーバーを代替する（外部IP不要） |
| Connectivity Test | 仮想パケットトレース / 疎通確認 | トラブルシューティング | 実際にパケットを送らない（仮想的な分析） |
| Private Google Access | 外部IPなし / GCPサービスアクセス | セキュアなGCPサービス利用 | サブネット設定で有効化するだけ（簡単） |
| PSC | プライベートエンドポイント / ピアリング不要 | マネージドサービスへの接続 | VPC Peeringより管理がシンプル |
TRAPS
混同しやすいポイント ─ 試験の落とし穴
受験者が誤りやすい概念の対比をまとめました。試験直前に必ず確認してください。
❌「VPCはリージョンスコープだ」
VPC自体はグローバルスコープです。リージョンスコープなのはサブネットです。1つのVPCが複数リージョンにまたがれるのがGCPの特徴です。
❌「Cloud VPN（全般）は99.99% SLA」
HA VPNが99.99% SLAです。Classic VPNは99.9% SLAです。新規構築ではHA VPNを使用してください。
❌「Cloud NATでインバウンド接続も受けられる」
Cloud NATはアウトバウンドのみです。外部からの受信接続はできません。受信が必要な場合はロードバランサーや外部IPを使用します。
❌「VPC PeeringでA-B-Cがつながれば全VPCが通信できる」
推移的ルーティングは不可です。A→B→CとピアリングしてもAとCは通信できません。A-C間にも直接ピアリングが必要です。
❌「Cloud ArmorはすべてのLBで使える」
Cloud ArmorはProxy型LB（Application LB・TCP Proxy LB等）にのみ対応します。Passthrough型（Network LB・Internal TCP/UDP LB）では使えません。
❌「Dedicated InterconnectはどこでもGoogleと直接接続できる」
Dedicated InterconnectはGoogleが指定するコロケーション施設（Meet-Me Location）に物理接続できる場合のみ利用可能です。施設に接続できない場合はPartner Interconnectを使用します。
❌「IAMポリシーだけでデータ漏洩を完全に防げる」
IAMはユーザーのアクセス権限を制御しますが、正規ユーザーによるデータ持ち出し（Exfiltration）は防げません。VPC Service ControlsでAPIの境界を設定することでデータ漏洩を防止します。
試験当日の解答戦略
🎯
最もシンプルな解決策を選ぶ
複雑な構成より管理が簡単なソリューションが正解になりやすい。「これをしなくてもあれで解決できる」という選択肢を探す。
☁️
マネージドサービスを優先
自分で管理するより「Googleが管理するマネージドサービス」を選ぶのが基本方針。運用コストが低く、SLAも高い。
🔄
冗長性・HAの要件を必ず確認
99.99% SLAが必要ならHA VPN・Interconnect複数Metro。SLAの数字と対応する構成を暗記する。
💰
コストと要件のバランス
Dedicated Interconnectが必須かVPNで十分かを見極める。帯域・レイテンシ要件が鍵になる。
🔐
セキュリティは最小権限
最も限定的なアクセスを許可するソリューションを選ぶ。「最小権限の原則」が常に正しい方向を示す。
📡
帯域要件で接続方式を選ぶ
大帯域→Interconnect、中帯域→Partner IC、小帯域/コスト優先→VPN。この3段階の判断軸を常に意識する。