GCP-PCNE

Google Cloud Professional Cloud Network Engineer (GCP-PCNE)

The Professional Cloud Network Engineer certification validates your ability to design, implement, and manage network architectures on Google Cloud. This professional-level certification is aimed at network engineers who leverage Google Cloud networking technologies to build enterprise-grade, secure, and high-performance network topologies. The exam covers designing, implementing, and managing VPC networks, configuring network services such as load balancing and DNS, implementing hybrid connectivity, securing network infrastructure, and optimizing network performance. Candidates should have 3+ years of industry experience with at least 1 year designing and managing Google Cloud network solutions. A strong understanding of IP addressing, routing, firewalls, VPNs, load balancers, and network security concepts is essential for success on this exam.

Exam Details

Domain Weights

Study Tips

• Master VPC networking fundamentals: subnets, routes, firewall rules, VPC peering, and Shared VPC; these form the backbone of every question
• Understand all load balancer types deeply: HTTP(S), TCP/UDP, internal, external, regional, global, proxy-based, and passthrough; know when to use each
• Study hybrid connectivity options: Cloud VPN (HA VPN vs Classic VPN), Cloud Interconnect (Dedicated vs Partner), and Cloud Router for dynamic routing with BGP
• Know Private Google Access, Private Service Connect, and VPC Service Controls for securing access to Google APIs and services
• Practice network troubleshooting with VPC Flow Logs, Firewall Insights, Connectivity Tests, and Network Intelligence Center
• Understand DNS architecture: Cloud DNS zones (public and private), DNS peering, DNS forwarding, and split-horizon DNS configurations
• Study Network Service Tiers (Premium vs Standard) and their impact on routing, latency, and cost

VPC Architecture Fundamentals

Google Cloud VPCs are global resources that span all regions without requiring inter-region connectivity configuration. Subnets are regional, and instances in different regions within the same VPC can communicate using internal IP addresses. This global VPC model is a key differentiator from other cloud providers where VPCs are regional. Understanding this architecture is fundamental to designing efficient network topologies on Google Cloud.

VPC Connectivity Options

Exam Tip: VPC Peering is non-transitive. If VPC-A peers with VPC-B and VPC-B peers with VPC-C, VPC-A cannot reach VPC-C through VPC-B. To achieve hub-and-spoke connectivity, use Network Connectivity Center or deploy VPN gateways. Also remember that Shared VPC is within one organization while VPC Peering works across organizations.

IP Address Management

GKE Networking Models

• VPC-Native (Alias IP): Recommended model; pods get IPs from subnet secondary ranges; enables direct VPC routing to pods; required for Private Google Access, VPC Flow Logs on pods, and Network Policies
• Private Clusters: Nodes have only internal IPs; control plane accessible via private endpoint; use Cloud NAT for outbound internet access; authorized networks restrict control plane access
• Dataplane V2: eBPF-based dataplane replacing iptables; better performance and observability; built-in network policy enforcement; required for some advanced features
• Gateway API: Next-generation Kubernetes ingress; supports multi-cluster, multi-team scenarios; richer routing rules than Ingress; integrates with Google Cloud load balancers

Google Cloud Load Balancing

Google Cloud offers a comprehensive suite of load balancers that are fully distributed, software-defined, and require no pre-warming. Load balancers are critical for distributing traffic across backends, providing health checking, enabling SSL termination, and supporting global anycast routing. The key decision points are: external vs internal, global vs regional, proxy-based vs passthrough, and the protocol being load balanced (HTTP/HTTPS, TCP, UDP).

Cloud DNS

Exam Tip: DNS forwarding is a critical topic for hybrid environments. Know the difference between inbound forwarding (on-prem resolvers query Cloud DNS via a forwarding IP in the VPC) and outbound forwarding (Cloud DNS forwards queries to on-prem DNS servers). Both require Cloud VPN or Interconnect connectivity.

Cloud CDN and Cloud Armor

Cloud NAT

• Purpose: Provides outbound internet connectivity for VMs and GKE nodes without external IPs; fully managed, no NAT gateway VM needed; regional resource configured per Cloud Router
• IP Allocation: Automatic IP allocation (Google assigns IPs) or manual (you reserve and assign static IPs); useful for allowlisting outbound IPs at destination firewalls
• Port Allocation: Static port allocation (fixed ports per VM) or dynamic port allocation (ports assigned on demand); dynamic recommended for variable workloads; configure minimum ports per VM
• Endpoint-Independent Mapping: Enables consistent outbound IP and port for connections to different destinations; important for protocols requiring consistent source addressing
• Logging: NAT logging captures translations for troubleshooting; filter logs for errors only or all translations; exported to Cloud Logging

Hybrid Connectivity Options

Hybrid connectivity connects on-premises or other cloud networks to Google Cloud VPCs. Choosing the right connectivity option depends on bandwidth requirements, latency tolerance, cost budget, and redundancy needs. Google Cloud offers VPN for encrypted tunnels over the internet and Interconnect for dedicated high-bandwidth private connections. Cloud Router provides dynamic routing using BGP to automatically exchange routes between your on-premises network and VPC.

Cloud Router and BGP

Exam Tip: Know the HA VPN topology for 99.99% SLA: two HA VPN gateways (GCP side has 2 interfaces, each with a tunnel to the on-prem peer). Cloud Router with dynamic routing (BGP) is required for HA VPN. Understand the difference between regional and global dynamic routing modes on the VPC.

Private Access to Google APIs

Network Service Tiers

• Premium Tier (Default): Traffic routed over Google's global private backbone; lowest latency; global load balancing with single anycast IP; higher cost; recommended for latency-sensitive applications
• Standard Tier: Traffic routed over the public internet after leaving Google's network; regional load balancing only; lower cost; suitable for non-latency-sensitive workloads or cost-optimized architectures
• Per-Resource Configuration: Network tier is set per external IP address or forwarding rule; you can mix tiers in the same project; Standard Tier available for Compute Engine, GKE, and Cloud NAT

Firewall Architecture

Google Cloud uses a layered firewall model with hierarchical firewall policies at the organization and folder levels, network firewall policies at the VPC level, and traditional VPC firewall rules. Understanding the evaluation order is critical: hierarchical policies are evaluated first (org then folder), followed by network firewall policies, then VPC firewall rules. Within each level, rules are evaluated by priority (lower number = higher priority). This layered approach allows central security teams to enforce organization-wide controls while giving project teams flexibility for service-specific rules.

Network Security Services

Firewall Best Practices

• Use Service Accounts Over Tags: Service account-based targeting is more secure than network tags because service accounts are tied to IAM; tags can be changed by anyone with instance edit permissions
• Default Deny Ingress: The implied deny-all ingress rule is your baseline; explicitly allow only necessary traffic; document the purpose of each allow rule
• Egress Controls: The implied allow-all egress rule should be restricted in security-sensitive environments; use egress deny rules with specific allow exceptions
• Firewall Insights: Use Firewall Insights to identify overly permissive rules, shadowed rules, and unused rules; optimize firewall configurations based on actual traffic patterns
• Enable Logging: Enable firewall rule logging for audit and troubleshooting; filter logs to reduce costs; use log-based metrics for monitoring firewall activity

Exam Tip: Know the firewall evaluation order: hierarchical policies (org, then folder) are evaluated first, then network firewall policies (global, then regional), then VPC firewall rules. The GOTO_NEXT action in hierarchical policies delegates the decision to the next level. Also understand that deny rules at a higher level cannot be overridden by allow rules at a lower level.

Packet Mirroring

• Purpose: Clone network traffic from specific instances and send copies to a collector (IDS, forensics, monitoring); does not affect original traffic flow
• Configuration: Define mirrored sources (instances, subnets, tags), a collector (internal load balancer with packet-mirroring-enabled IGs), and optional filters (protocols, IP ranges)
• Integration: Used with Cloud IDS for managed threat detection; third-party security tools for deep packet inspection; forensic analysis of network traffic patterns

Network Intelligence Center

VPC Flow Logs

Network Monitoring with Cloud Monitoring

Network Troubleshooting Methodology

• Step 1 - Connectivity Tests: Use Network Intelligence Center Connectivity Tests to analyze the configuration path between source and destination; identifies misconfigurations in routes, firewall rules, or NAT without sending traffic
• Step 2 - VPC Flow Logs: Examine flow logs to confirm whether traffic is reaching the destination; check for allowed vs denied flows; correlate with firewall rule logging
• Step 3 - Firewall Rule Logging: Enable logging on suspect firewall rules; verify which rules are matching traffic; check for priority conflicts or shadowed rules
• Step 4 - Cloud Trace: For application-layer issues, use distributed tracing to identify latency between microservices; correlate with network metrics
• Step 5 - Packet Mirroring: For deep packet inspection, mirror traffic to a collector instance for detailed analysis; useful for complex issues not visible in flow logs

Exam Tip: Connectivity Tests are a configuration-analysis tool that does NOT send actual packets. They trace the logical path through VPC resources and identify where traffic would be blocked. This is different from active probing. Know when to use Connectivity Tests vs VPC Flow Logs vs Packet Mirroring for different troubleshooting scenarios.