Google Cloud Professional Cloud Network Engineer
Last reviewed: May 2026
A scannable reference of architectural patterns the PCNE exam tests. Read top-to-bottom, or jump to a section.
Plan IP addressing for large-scale or hybrid cloud deployments.
Use custom-mode VPCs. Allocate non-overlapping RFC 1918 CIDR blocks (e.g., 172.16.0.0/12) to avoid conflicts with on-prem (often 10.0.0.0/8). Use 100.64.0.0/10 for GKE pod secondary ranges.
Why: Avoids IP conflicts with on-prem for future hybrid connectivity and provides full control over address space, which is essential for scale and avoiding costly re-IPing.
Provide network isolation for multiple tenants/environments (dev, prod) while centralizing network management and shared services.
Use Shared VPC. The host project contains the VPC, subnets, firewalls, and interconnects. Tenants/environments are service projects attached to the host project.
Why: Centralizes network administration in the host project while delegating resource management to service projects. More scalable and governable than VPC peering for many projects within an organization.
Plan IP addressing for large GKE clusters using VPC-native networking.
In a custom-mode VPC, plan for three CIDR ranges: a primary range for nodes, a secondary range for Pods, and another for Services. For expansion, use discontiguous multi-pod CIDR.
Why: VPC-native networking requires dedicated, non-overlapping secondary ranges for pods and services. Proper sizing prevents IP exhaustion, a common and disruptive issue in large clusters.
VMs with no external IPs need to access Google Cloud APIs (e.g., Cloud Storage, BigQuery).
Enable Private Google Access on the subnet. Optionally, configure DNS to resolve `*.googleapis.com` to `restricted.googleapis.com` (199.36.153.4/30) to enforce VPC-SC.
Why: Routes traffic to Google APIs over Google's internal network without requiring public IPs on VMs. Using `restricted.googleapis.com` adds a layer of data exfiltration protection.
Provide private access to a service in your VPC for consumers (partners, other BUs) whose VPCs have overlapping IP ranges.
Publish the service (via an Internal Load Balancer) using a Private Service Connect (PSC) service attachment. Consumers create a PSC endpoint in their VPC with an IP from their own range.
Why: PSC decouples producer and consumer networks, using NAT to handle overlapping IPs. It provides secure, service-level access, not full network connectivity like VPC peering.
Connect a large number (50+) of VPCs and/or on-prem sites in a hub-and-spoke topology for centralized management and connectivity.
Use Network Connectivity Center. Configure the hub and attach VPCs as VPC spokes and on-prem connections (VPN/Interconnect) as hybrid spokes.
Why: NCC is Google's managed solution for large-scale hub-and-spoke topologies, simplifying route management and scaling beyond the 25-peer limit of VPC peering.
Deploy a GKE cluster where nodes and the control plane have no public IP addresses for enhanced security.
Create a Private GKE cluster. This assigns only internal IPs to nodes and creates a private endpoint for the control plane. Configure authorized networks to restrict control plane access.
Why: A private cluster removes the control plane and nodes from the public internet, significantly reducing the attack surface. All management and workload traffic remains on the private network.
Serverless workloads (Cloud Run, Functions) need to access resources (e.g., Cloud SQL, Memorystore) inside a VPC.
Create a Serverless VPC Access connector in the target VPC. Configure the serverless service to use this connector for egress traffic.
Why: The connector acts as a proxy, allowing serverless services (which run in a Google-managed environment) to send traffic into a customer-managed VPC using internal IPs.
An application (e.g., HPC, financial trading) requires the absolute lowest network latency between a group of VMs.
Create a compact placement policy and apply it to the VMs. Use machine types with Tier_1 networking.
Why: Collocating VMs within the same network rack minimizes network hops and physical distance, significantly reducing latency compared to standard VM placement.
Implement a zero-trust security model for microservices, requiring strong identity, encrypted communication (mTLS), and fine-grained authorization.
Deploy Anthos Service Mesh. Enable automatic mTLS for all service-to-service communication. Use `AuthorizationPolicy` resources to define allowed communication.
Why: A service mesh decouples security from the underlying network, providing workload identity, transparent mTLS, and L7 authorization, which are core tenants of a zero-trust architecture.
Workloads (VMs, GKE pods) with no public IPs need a stable, predictable source IP for outbound connections to external APIs that use allow-listing.
Deploy Cloud NAT. Use the "manual NAT IP allocation" option and assign reserved static external IP addresses to the NAT gateway.
Why: Cloud NAT with manual allocation provides a shared pool of static egress IPs. This decouples the workload from the IP, allowing scaling without needing to update external allow-lists.
VPC peering is established but VMs cannot communicate between peered VPCs.
Verify that firewall rules in *both* VPCs allow ingress traffic from the other VPC's IP range. The peering connection only establishes routing; it does not implicitly create firewall allows.
Why: A common mistake is assuming peering opens firewall ports. The implied deny-all ingress rule blocks traffic until an explicit allow rule is created.
In a Shared VPC, grant a team/service project permission to use only a specific subnet, not the entire VPC.
In the host project, grant the `compute.networkUser` IAM role to the service project's identity (e.g., service account, group) at the subnet-level resource.
Why: IAM roles can be scoped to specific resources. Applying `compute.networkUser` at the subnet level enforces least-privilege, allowing use of only that subnet.
Implement microsegmentation for a multi-tier application (e.g., web, app, db) on Compute Engine.
Assign network tags to VMs based on their tier (e.g., `web-server`). Create firewall rules that use these tags as source and target specifiers.
Why: Tags provide a flexible, scalable alternative to IP-based rules. The firewall policy is independent of the number or IPs of the VMs in a tier.
Capture traffic metadata for compliance/auditing while minimizing log volume and storage costs.
Enable VPC Flow Logs with a longer aggregation interval (e.g., 10 minutes), a reduced sampling rate (e.g., 0.5), and metadata filtering to exclude unneeded fields.
Why: The default settings generate massive amounts of data. Tuning these parameters significantly reduces cost while still providing sufficient visibility for most audit use cases.
Deliver a global application with low latency, routing users to the nearest healthy backend with automatic failover.
Use a Global External Application Load Balancer (or TCP/SSL Proxy LB for non-HTTP). Configure backend services/NEGs in multiple regions. Use Premium Tier networking.
Why: The load balancer's anycast IP directs users to the nearest Google edge PoP. Traffic then travels over Google's private backbone to the closest healthy backend for optimal performance.
Route internal traffic based on URL path or hostname, with SSL termination, accessible only within the VPC or from on-prem.
Use a Regional Internal Application Load Balancer. Configure a URL map to direct traffic based on host/path rules. Requires a proxy-only subnet.
Why: This is Google's managed L7 internal load balancer. It provides advanced routing features not available with the L4 Internal Passthrough Network LB.
Use Cloud CDN to cache and serve private or user-specific content without making it public.
Enable Cloud CDN on a private backend (e.g., GCS bucket). Generate Cloud CDN Signed URLs or Signed Cookies in your application to grant users temporary, authenticated access.
Why: Signed URLs/Cookies provide a secure token that Cloud CDN validates before serving a cached object, leveraging edge caching while maintaining strict access control.
Enable bidirectional DNS resolution between an on-prem network and a GCP VPC.
1) On-prem resolves GCP: Create a Cloud DNS inbound server policy. Configure on-prem DNS to forward to the inbound forwarder IPs. 2) GCP resolves on-prem: Create a Cloud DNS forwarding zone that points to the on-prem DNS servers.
Why: This standard two-part configuration provides seamless, private name resolution for hybrid environments, a critical component for application interoperability.
Cloud CDN cache hit ratio is low due to unnecessary URL variations (e.g., tracking parameters).
Configure a custom cache key policy for the backend service. Exclude non-essential query parameters, cookies, and headers from the cache key.
Why: By default, the full URL is the cache key. Normalizing the key by excluding irrelevant parameters prevents cache fragmentation and dramatically improves hit ratio.
Resolve a DNS name to an internal IP for internal clients and a public IP for external clients.
Create a Cloud DNS private zone for the domain (visible to your VPC) with the internal IP record. Create a matching Cloud DNS public zone with the public IP record.
Why: Cloud DNS automatically serves the response from the private zone to clients within the authorized VPC, and the public zone response to everyone else.
An internal application in one region needs to be accessible by clients (VMs, on-prem) in other regions.
Enable the "Global Access" option on the Internal TCP/UDP Load Balancer or Internal Application Load Balancer's forwarding rule.
Why: By default, internal LBs are regional. Global Access makes them accessible from any region within the VPC network, simplifying multi-region internal service architectures.
Establish highly available (99.99% SLA), high-bandwidth (10G+) connectivity between on-prem and GCP.
Provision a minimum of four Dedicated Interconnect connections, two in one metro and two in another, with each metro pair in different edge availability domains. Configure BGP.
Why: Redundancy across separate metropolitan areas and failure domains (edge availability domains) is required for the 99.99% SLA.
Need an encrypted, reliable (99.9% or 99.99% SLA), and quickly deployable hybrid connection with moderate bandwidth (< 6 Gbps).
Use HA VPN with BGP for dynamic routing. For 99.99% SLA, use two HA VPN gateways. For 99.9% SLA, use a single gateway with two tunnels.
Why: HA VPN is faster to set up than Interconnect, provides a strong SLA, and offers sufficient bandwidth for many use cases, making it the default choice for non-physical connections.
Encrypt all traffic traversing a Dedicated or Partner Interconnect link for compliance.
Configure HA VPN over Interconnect. Create HA VPN tunnels that use the Interconnect's VLAN attachments for their underlying transport.
Why: This pattern combines the high bandwidth and low latency of Interconnect with the IPsec encryption of HA VPN, providing the best of both worlds.
Establish dedicated, private, high-bandwidth connectivity between GCP and another major cloud provider (AWS, Azure, OCI).
Use Cross-Cloud Interconnect. Provision a dedicated physical connection between Google's network and the other cloud provider's network. Configure BGP with Cloud Router.
Why: Provides a direct, SLA-backed, low-latency path between clouds, avoiding the public internet and the variable performance of VPNs.
An on-prem network connected via Interconnect to one GCP region needs to access resources in all other GCP regions.
Enable "Global" dynamic routing mode on the VPC. The Cloud Router will then advertise routes for all subnets in the VPC, not just those in its local region.
Why: Global routing allows a single hybrid connection point to serve as an on-ramp to Google's entire global network, simplifying multi-region access.
Influence traffic path selection over redundant hybrid connections (VPN/Interconnect) using BGP.
To influence GCP-to-on-prem traffic, have on-prem advertise more specific routes or use a shorter AS_PATH for the preferred path. To influence on-prem-to-GCP, advertise from Cloud Router with a lower MED value for the preferred path.
Why: BGP path selection follows a clear algorithm. Longest prefix match is key for outbound traffic, while MED influences inbound traffic decisions.
Configure an active/passive failover between a primary Dedicated Interconnect and a backup HA VPN.
Use BGP on both. On Cloud Router, advertise routes over Interconnect with a lower base priority (e.g., 100) and over VPN with a higher base priority (e.g., 200).
Why: GCP prefers BGP routes with a lower priority value (higher preference). Traffic uses the primary Interconnect. Upon failure, its routes are withdrawn, and the backup VPN routes become active.
Prevent data exfiltration from sensitive Google Cloud services (e.g., BigQuery, GCS), ensuring access only from authorized networks.
Implement VPC Service Controls. Create a service perimeter around projects with sensitive data. Configure access levels to define authorized sources (IP ranges, device state, identity).
Why: VPC-SC creates a virtual network boundary around Google-managed services, blocking access from outside the perimeter even with valid credentials. A critical data governance control.
Enforce consistent, non-overridable baseline firewall rules across an organization, while allowing project-level customization.
Implement Hierarchical Firewall Policies at the organization or folder level. Place critical rules here. Use the `goto_next` action to delegate evaluation to lower-level policies.
Why: Hierarchical policies are evaluated before VPC-level rules and cannot be modified by project owners, ensuring centralized governance. `goto_next` provides flexibility.
Protect a web application from OWASP Top 10 vulnerabilities and apply per-client IP rate limiting.
Attach a Cloud Armor security policy to the Global External Application LB. Apply pre-configured WAF rules (e.g., `sqli-v3.3-stable`) and add a rate-based rule.
Why: Cloud Armor provides edge security. Pre-configured WAF rules offer managed protection, while rate-based rules mitigate DoS and brute-force attacks.
Implement fine-grained, pod-level network security within a GKE cluster based on labels.
Enable Network Policy enforcement on the GKE cluster. Create Kubernetes `NetworkPolicy` resources that define ingress/egress rules for pods using label selectors.
Why: Kubernetes NetworkPolicy is the native way to implement microsegmentation at the pod level, offering more granularity than VPC firewall rules which operate at the node level.
Inspect all inter-VPC or VPC-to-internet traffic using a centralized third-party firewall/NVA.
Create a hub-and-spoke topology. Deploy the NVA(s) in a hub VPC. Configure custom routes in spokes that direct traffic to an Internal Load Balancer in the hub as the next-hop.
Why: This pattern forces traffic through a central inspection point. The ILB provides a stable, highly available next-hop IP for the NVAs.
Provide secure, identity-based, zero-trust access for users to internal web applications or VMs without using a VPN.
For web apps, enable IAP on an External HTTPS LB backend service. For SSH/RDP, use IAP for TCP forwarding. Grant appropriate IAP IAM roles to users.
Why: IAP moves access control from the network perimeter to the user's identity, authenticating and authorizing every request. It is a core component of Google's BeyondCorp zero-trust model.
Implement threat prevention (IDS/IPS) for inter-VPC or VPC-to-internet traffic, including malware detection and TLS inspection.
Use Cloud NGFW. Associate a firewall policy with the VPC, create rules with security profiles for threat prevention, and optionally enable TLS inspection.
Why: Cloud NGFW is Google's distributed, managed firewall service providing advanced L7 inspection capabilities from Palo Alto Networks, integrated directly into the VPC.
Centrally inspect, log, and control all internet-bound egress traffic from a VPC for security and compliance.
Deploy Secure Web Proxy. Configure security policies for URL filtering and TLS inspection. Route traffic from subnets to the proxy using custom routes.
Why: This is Google's managed solution for secure egress, providing L7 visibility and control without requiring self-managed proxy fleets.
Quickly diagnose a connectivity failure between two endpoints within GCP (e.g., VM-to-VM, VM-to-Cloud SQL).
Use Network Intelligence Center's Connectivity Tests. Specify the source and destination, and it will analyze the entire configured path for issues.
Why: This non-intrusive tool provides a definitive analysis of the path, pinpointing the exact point of failure (firewall, route, etc.) much faster than manual inspection.
A BGP session over a hybrid connection is intermittently resetting ("flapping").
Check for a mismatch in BGP keepalive/hold timers. If timers expire under load, increase them (e.g., 60s keepalive, 180s hold). Also, check MTU settings and enable BFD.
Why: Mismatched or overly aggressive timers are a common cause of BGP flaps, as transient network congestion can delay keepalive packets beyond the hold time.
Investigate reports of increased latency for traffic between GCP regions.
Use the Network Intelligence Center's Performance Dashboard to view historical and real-time latency and packet loss metrics between all GCP zone pairs.
Why: This tool gives direct visibility into Google's backbone network performance, helping to distinguish between an application issue and a network infrastructure issue.
VMs using Cloud NAT experience intermittent outbound connection failures, and NAT logs show `OUT_OF_RESOURCES` drops.
This is likely NAT port exhaustion. Increase the number of NAT IPs allocated, increase the "Minimum ports per VM instance", and/or enable Dynamic Port Allocation.
Why: High connection rates from many VMs can exhaust the allocated source port pool per NAT IP. Allocating more resources is the required fix.
