Home / networking / Google Cloud Professional Cloud Network Engineer / Cheat Sheet
Google Cloud Professional Cloud Network Engineer

GCP PCNE Cheat Sheet

PCNE Tests SLA Topologies, Route Precedence and Control Placement — Not Subnet Math Alone

For engineers who design and run VPC, hybrid and multicloud networks. The shift: count connections, interfaces and availability domains against the quoted SLA, and put each control at the layer and level that can enforce it.

Check Your Readiness →
Among the harder certs
Avg: Not published by Google
Pass: 750 / 1000
Most candidates understand Google Cloud Professional Cloud Network Engineer concepts — and still fail. This exam tests how you apply knowledge under pressure.

Professional Cloud Network Engineer Section Map (six-section guide)

Fifty to sixty scenarios built around one deciding adjective: central team, 99.99%, no public IPs, overlapping ranges, client IP preserved. This follows the current six-section PDF; some localised pages still show an older five-section outline. Prefer in-place changes over rebuilds.

  1. 01
    Designing and planning a VPC network (~21%) — Shared VPC vs. peering vs. NCC vs. PSC, IP plans, GKE Pod sizing, tiers, MTU
  2. 02
    Implementing a VPC network (~20%) — custom mode, subnet expansion, route selection, policy-based routes, NCC star vs. mesh, GKE datapath
  3. 03
    Managed network services (~16%) — load balancer families, global access, NEGs, URL maps, Cloud CDN modes, Cloud DNS zones and policies
  4. 04
    Hybrid and multicloud interconnectivity (~16%) — Dedicated, Partner and Cross-Cloud Interconnect, HA VPN, Cloud Router MED, BFD
  5. 05
    Network operations and troubleshooting (~14%) — Connectivity Tests, Flow Logs, Network Intelligence Center, BGP vs. tunnel faults, NAT ports
  6. 06
    Network security (~13%) — Cloud Armor, hierarchical NGFW policies, secure tags, NGFW Enterprise, Secure Web Proxy, NVA next hops

Wrong instinct vs correct approach

Prod and shared-services VPCs are peered; on-premises reaches shared-services via HA VPN, but prod cannot reach on-premises
✕ Wrong instinct

Add another firewall rule or a second VPN to prod

✓ Correct approach

Enable custom route export on shared-services and import on prod, and add a Cloud Router custom advertisement for the prod range toward on-premises. Peering never shares dynamic routes or advertises peered ranges automatically.

On-premises resolvers must query a Cloud DNS private zone corp.internal over HA VPN
✕ Wrong instinct

Create a Cloud DNS forwarding zone pointing on-premises

✓ Correct approach

Create an inbound server policy, which assigns entry-point addresses from VPC subnets for on-premises resolvers to forward to. Forwarding zones handle outbound queries; outbound forwarding replies from 35.199.192.0/19 also need a route back.

An HA VPN tunnel shows Established but the BGP session is down after on-premises replaced its router
✕ Wrong instinct

Delete and recreate the VPN tunnel

✓ Correct approach

IPsec is up, so the fault is BGP: check peer ASN, link-local addresses, MD5 key and TCP 179 on the new router. Tunnel-down symptoms point instead to shared secret, IKE version, ciphers or peer IP.

A new GKE cluster needs Pod addresses but 10.0.0.0/8 is fully used on-premises
✕ Wrong instinct

Carve another slice of RFC 1918 space for Pods

✓ Correct approach

Use non-RFC 1918 or privately used public (PUPI) ranges to avoid hybrid overlap. Size Pod ranges from nodes times the per-node block, which is a /24 at 110 maximum Pods per node; add ranges for new node pools later.

Twenty VPCs must all reach each other, while dev, test and prod stay isolated from one another
✕ Wrong instinct

Build a full mesh of VPC Network Peering connections

✓ Correct approach

Network Connectivity Center VPC spokes give transitive reach without peering quotas. A star topology lets edge spokes reach centre shared services while staying isolated from each other; mesh would let every environment talk.

Know these cold

  • ▸ Route choice — ongest prefix first, then lowest priority number, then tags; policy-based routes evaluate earlier
  • ▸ Subnet primary ranges can expand in place but never shrink
  • ▸ HA VPN gives 99.99% only with both interfaces and tunnels; Classic VPN tops out at 99.9%
  • ▸ Partner Interconnect Layer 3 — rovider runs BGP; Layer 2: you configure BGP on Cloud Router
  • ▸ Interconnect is unencrypted by default; add MACsec or HA VPN over Cloud Interconnect
  • ▸ Health check probes come from 35.191.0.0/16 and 130.211.0.0/22; allow them
  • ▸ Passthrough Network Load Balancers preserve client IP and handle UDP; proxies terminate connections
  • ▸ Cloud CDN and global anycast require the global external Application Load Balancer on Premium Tier
  • ▸ Hierarchical firewall policies evaluate before VPC rules; goto_next defers to the next level
  • ▸ Connectivity Tests before Packet Mirroring; Flow Logs hold metadata only, never payloads

Can you answer these without checking your notes?

In this scenario: "Prod and shared-services VPCs are peered; on-premises reaches shared-services via HA VPN, but prod cannot reach on-premises" — what should you do first?
Enable custom route export on shared-services and import on prod, and add a Cloud Router custom advertisement for the prod range toward on-premises. Peering never shares dynamic routes or advertises peered ranges automatically.
In this scenario: "On-premises resolvers must query a Cloud DNS private zone corp.internal over HA VPN" — what should you do first?
Create an inbound server policy, which assigns entry-point addresses from VPC subnets for on-premises resolvers to forward to. Forwarding zones handle outbound queries; outbound forwarding replies from 35.199.192.0/19 also need a route back.
In this scenario: "An HA VPN tunnel shows Established but the BGP session is down after on-premises replaced its router" — what should you do first?
IPsec is up, so the fault is BGP: check peer ASN, link-local addresses, MD5 key and TCP 179 on the new router. Tunnel-down symptoms point instead to shared secret, IKE version, ciphers or peer IP.

Common Exam Mistakes — What candidates get wrong

Ordering one Dedicated Interconnect with two VLAN attachments for a 99.99% SLA

99.99% needs four connections across two metros, each pair split over different edge availability domains, attached in two regions with global dynamic routing. Redundant links sharing one edge availability domain fail together during maintenance.

Leaving VPC dynamic routing in regional mode for cross-region hybrid failover

In regional mode, Cloud Router only programs learned routes into its own region, so losing one region's Interconnect strands that region's VMs. Global mode lets the surviving link serve every region, with advertised priority (MED) steering preference.

Setting a lower advertised route priority on the intended backup link

Lower MED is preferred, so that link becomes primary. Give the active path the lower value. Enable BFD for sub-second failure detection instead of BGP hold timers, and keep subnets advertised when switching Cloud Router to custom advertisements.

Using a VPC firewall rule to stop SQL injection or login floods

VPC and NGFW rules match addresses, ports and protocols. Cloud Armor on the global external Application Load Balancer inspects HTTP with OWASP-based WAF rules, applies per-client rate limiting, and Adaptive Protection suggests rules for layer 7 DDoS.

Expecting Cloud NAT to restrict which websites VMs can reach

Cloud NAT only translates addresses; intermittent drops usually mean port exhaustion, fixed with more minimum ports, dynamic allocation or extra NAT IPs. Domain allowlists need Secure Web Proxy or an egress firewall policy with FQDN objects.

Resources to help you pass Google Cloud Professional Network Engineer on your first attempt

Test whether your Interconnect layouts, routing and firewall placements would pass PCNE scrutiny.