What does the Google Cloud Professional Cloud Network Engineer exam cover?
The Google Cloud Professional Cloud Network Engineer exam covers designing, planning, and prototyping Google Cloud networks including VPC design, hybrid connectivity (Cloud VPN, Cloud Interconnect), load balancing, DNS, network security, and network monitoring. The exam costs $200 USD and targets network engineers with deep GCP networking expertise.
The Google Cloud Professional Cloud Network Engineer (PCNE) certification validates expertise in designing and implementing GCP networking solutions. Network engineers with this certification demonstrate mastery of VPC design, hybrid connectivity, load balancing architectures, and network security controls.
Networking is foundational to every GCP deployment — the PCNE certification is pursued by network engineers, cloud architects, and infrastructure engineers who own the networking layer for GCP environments.
Exam Overview
| Detail | Information |
|---|---|
| Certification | Professional Cloud Network Engineer |
| Provider | Google Cloud |
| Number of Questions | 50 |
| Time Limit | 2 hours |
| Passing Score | Not published |
| Cost | $200 USD |
| Prerequisites | ACE recommended |
| Validity | 2 years |
The exam covers five domains:
- Designing, planning, and prototyping a GCP network (26%)
- Implementing a GCP virtual private network (21%)
- Configuring network services (23%)
- Implementing hybrid interconnectivity (14%)
- Implementing network security (16%)
"The PCNE exam requires real depth in GCP networking concepts. It is not enough to know what each service does — you need to understand the trade-offs between Cloud VPN and Cloud Interconnect for different bandwidth and reliability requirements, how BGP community tags affect route propagation in hybrid connectivity, and when to choose each load balancer type. Candidates without hands-on VPC and hybrid connectivity experience find this exam significantly harder than the architect certifications." -- Google Cloud Professional Network Engineer community
VPC Design
VPC Architecture Patterns
Shared VPC: Centrally managed VPC hosting network resources used by multiple service projects:
Host Project: shared-vpc-host
VPC: enterprise-network
Subnet: prod-us-central1 (10.10.0.0/20)
Subnet: prod-europe-west1 (10.20.0.0/20)
Subnet: dev-us-central1 (10.30.0.0/20)
Service Projects:
web-team-prod → uses prod-us-central1
api-team-prod → uses prod-us-central1
dev-team → uses dev-us-central1
Shared VPC benefits:
- Centralized network management
- Centralized firewall policy enforcement
- Projects cannot modify shared VPC networking
- Network team owns network; app teams deploy resources
VPC Peering: Connect two VPCs without shared VPC:
# Peer VPC A to VPC B (must peer both directions)
gcloud compute networks peerings create vpc-a-to-b \
--network=vpc-a \
--peer-network=vpc-b \
--peer-project=project-b
gcloud compute networks peerings create vpc-b-to-a \
--network=vpc-b \
--peer-network=vpc-a \
--peer-project=project-a
VPC Peering limitations:
- Routes are not transitive (A-B-C peering does not give A access to C)
- Overlapping CIDR ranges cannot be peered
- No transitive IAM (cannot use Hub-and-spoke through peering for centralized services)
IP Address Planning
RFC 1918 private address ranges for GCP VPCs:
| Range | Prefix | Common Use |
|---|---|---|
| 10.0.0.0/8 | /16 to /20 per region | Large enterprise |
| 172.16.0.0/12 | /20 to /24 per subnet | Medium organizations |
| 192.168.0.0/16 | /24 per site | Small deployments |
Secondary IP ranges: Enable IP aliasing for GKE pods and services:
# Create subnet with secondary ranges for GKE
gcloud compute networks subnets create gke-subnet \
--network=my-vpc \
--region=us-central1 \
--range=10.0.0.0/20 \
--secondary-range=gke-pods=10.4.0.0/14 \
--secondary-range=gke-services=10.8.0.0/20
Hybrid Connectivity
Cloud VPN
Cloud VPN connects on-premises networks to GCP over IPsec tunnels:
| VPN Type | Description | Best For |
|---|---|---|
| HA VPN | Two tunnels, 99.99% SLA | Production workloads |
| Classic VPN | Single tunnel, 99.9% SLA | Non-critical, legacy |
HA VPN configuration:
# Create HA VPN gateway
gcloud compute vpn-gateways create my-ha-vpn \
--network=my-vpc \
--region=us-central1
# Create VPN tunnel (create two for HA)
gcloud compute vpn-tunnels create tunnel-1 \
--region=us-central1 \
--vpn-gateway=my-ha-vpn \
--peer-gcp-gateway=peer-ha-vpn \ # or --peer-address for on-prem
--shared-secret=SHARED_SECRET \
--ike-version=2 \
--interface=0
Cloud Interconnect
Cloud Interconnect provides private, high-bandwidth connectivity between on-premises and GCP:
| Type | Bandwidth | Connection | SLA |
|---|---|---|---|
| Dedicated Interconnect | 10/100 Gbps | Direct physical connection | 99.99% (dual) |
| Partner Interconnect | 50 Mbps - 50 Gbps | Through service provider | 99.99% (dual) |
| Cross-Cloud Interconnect | 10/100 Gbps | To other cloud providers | 99.99% |
When to use Cloud VPN vs. Cloud Interconnect:
Cloud VPN:
- Bandwidth < 3 Gbps
- Testing, development, or backup connectivity
- Locations where Interconnect is not available
- Lower cost priority
Cloud Interconnect:
- Bandwidth > 3 Gbps (or consistent need for > 1 Gbps)
- Consistent latency and reliability requirements
- Large data transfer volumes (Interconnect cheaper at scale)
- Compliance requiring private connectivity (no public internet)
BGP Route Management
Cloud Router uses BGP to exchange routes between GCP and on-premises:
# Create Cloud Router for BGP
gcloud compute routers create my-router \
--network=my-vpc \
--region=us-central1 \
--asn=65001
# Add BGP interface for VPN tunnel
gcloud compute routers add-interface my-router \
--region=us-central1 \
--interface-name=bgp-tunnel-1 \
--vpn-tunnel=tunnel-1 \
--ip-address=169.254.0.1 \
--mask-length=30
# Add BGP peer (on-premises router)
gcloud compute routers add-bgp-peer my-router \
--region=us-central1 \
--interface=bgp-tunnel-1 \
--peer-name=on-prem-router \
--peer-ip-address=169.254.0.2 \
--peer-asn=65002
Load Balancing
Load Balancer Selection
| Load Balancer | Scope | Protocol | Backend |
|---|---|---|---|
| External HTTPS (Global) | Global | HTTP/S, HTTP/2, gRPC | GCE, GKE, Cloud Run, NEG |
| External TCP Proxy | Global | TCP | GCE MIGs |
| External SSL Proxy | Global | SSL/TLS | GCE MIGs |
| External TCP/UDP Regional | Regional | TCP/UDP | GCE, NEGs |
| Internal HTTP(S) | Regional | HTTP/S | GCE, GKE, Cloud Run |
| Internal TCP/UDP | Regional | TCP/UDP | GCE, GKE |
Network Endpoint Groups (NEGs): Allow load balancing to non-VM backends:
- Zonal NEGs: GCE VMs or GKE pods with direct IP:port targeting
- Serverless NEGs: Cloud Run, Cloud Functions, App Engine
- Internet NEGs: External backends (for CDN origin or hybrid load balancing)
- Private Service Connect NEGs: Published services
DNS Architecture
Cloud DNS
# Create a private DNS zone for internal resolution
gcloud dns managed-zones create internal-zone \
--description="Internal DNS zone" \
--dns-name=internal.example.com. \
--visibility=private \
--networks=my-vpc
# Add an A record
gcloud dns record-sets create app.internal.example.com. \
--zone=internal-zone \
--type=A \
--ttl=300 \
--rrdatas=10.0.1.5
DNS forwarding: Forward queries for specific zones to on-premises DNS servers:
gcloud dns managed-zones create onprem-zone \
--description="Forwarding to on-prem DNS" \
--dns-name=corp.example.com. \
--visibility=private \
--networks=my-vpc \
--forwarding-targets=10.100.0.53 # On-prem DNS server
Frequently Asked Questions
When should I use Shared VPC instead of VPC Peering? Use Shared VPC when you need centralized network management where a network team controls all networking resources and service project teams deploy workloads without network modification rights. Use VPC Peering when you need to connect two independently managed VPCs — often for connecting application VPCs to a shared services VPC (DNS, Active Directory). Shared VPC is typically preferred for large enterprises; VPC Peering is common for simpler multi-team setups.
What is the bandwidth limit for Cloud VPN? A single Cloud VPN tunnel provides up to 3 Gbps of throughput. You can achieve higher aggregate bandwidth by using ECMP (Equal-Cost Multi-Path) routing across multiple tunnels — each HA VPN gateway supports multiple tunnels that can be load-balanced. For consistently higher bandwidth requirements (> 3 Gbps), Cloud Interconnect is the appropriate solution. Cloud Interconnect provides 10 Gbps or 100 Gbps per link.
How does Private Google Access work for private instances? Private Google Access allows VM instances without external IP addresses to reach Google APIs and services (Cloud Storage, BigQuery, Pub/Sub, etc.) using private IP addresses. Enable Private Google Access on the subnet containing the private VMs. Traffic routes to Google's private infrastructure without traversing the public internet. For on-premises access to Google APIs over Interconnect or VPN, use Private Service Connect or Private Google Access for on-premises hosts.
References
- Google Cloud. (2025). Professional Cloud Network Engineer Certification. https://cloud.google.com/certification/cloud-network-engineer
- Google Cloud. (2025). VPC Documentation. https://cloud.google.com/vpc/docs
- Google Cloud. (2025). Cloud Interconnect Documentation. https://cloud.google.com/network-connectivity/docs/interconnect
- Google Cloud. (2025). Cloud VPN Documentation. https://cloud.google.com/network-connectivity/docs/vpn
- Google Cloud. (2025). Cloud Load Balancing Documentation. https://cloud.google.com/load-balancing/docs
- Google Cloud. (2025). Cloud DNS Documentation. https://cloud.google.com/dns/docs