Domain 1: Designing and Planning a Google Cloud VPC Network
- A VPC network is a global resource that spans all regions automatically, while subnets are regional resources whose IP range is bound to one region; VMs in any zone of a region can use that region's subnets.
- Custom-mode VPCs require you to manually create each subnet and choose its CIDR, whereas auto-mode VPCs auto-create one /20 subnet per region; production designs favor custom mode for explicit IP control.
- VPC Network Peering connects two VPCs so VMs communicate over internal RFC 1918 IPs with no external hops, but it is non-transitive and requires completely non-overlapping subnet CIDR ranges (primary and secondary).
- When CIDR ranges overlap, peering is rejected; remediate by re-IPing one VPC or by using Private Service Connect to expose only a specific service endpoint instead of the whole network.
- Shared VPC designates one host project whose subnets, firewall rules, and routes are centrally managed, while service projects deploy workloads into those shared subnets - centralizing network administration across an organization.
- Cloud Interconnect (Dedicated or Partner) and Cloud VPN are the two hybrid connectivity options; Interconnect provides a private physical link (10/100 Gbps for Dedicated) that never traverses the public internet.
- Network Connectivity Center (NCC) provides a managed hub-and-spoke model giving transitive connectivity between multiple VPCs and on-prem sites, avoiding full-mesh peering or transit-VPC complexity.
- VPC route priority uses a numeric value where a lower number wins; for firewall rules, priority ranges 0 (highest) to 65535 (lowest) and the first matching rule's action is applied immediately.
- A custom static route with a VM (or internal load balancer) as the next hop steers traffic through a network virtual appliance (NVA); create with gcloud compute routes create --destination-range and --next-hop-ilb or --next-hop-instance.
- Co-locating instances that communicate heavily in the same zone avoids inter-zone egress charges; cross-region and internet egress cost more than same-zone traffic.
- Premium Network Service Tier routes traffic over Google's global backbone for lowest latency, while Standard Tier routes over the public internet from the source region to reduce egress cost for regional workloads.
- PRIVATE_SERVICE_CONNECT and REGIONAL_MANAGED_PROXY are special subnet purposes; proxy-only subnets are required in a region before deploying regional/global Envoy-based (Application) load balancers.
- Custom-mode VPCs let you expand a subnet's primary range later (gcloud compute networks subnets expand-ip-range) without recreating it, but you can only grow, never shrink, the range.
- For cost-optimized regional web workloads, a regional external Application Load Balancer on Standard Tier is typically more economical than a global Premium-Tier deployment.
Domain 2: Implementing a VPC Network
- Private Google Access is a per-subnet flag that lets VMs without external IPs reach Google APIs and services (Cloud Storage, BigQuery, Pub/Sub) over internal IPs via Google's network.
- A new custom VPC has two implied rules that cannot be deleted: implied deny-all ingress and implied allow-all egress; you add higher-priority rules to override them.
- Private Service Connect lets a consumer reach a producer's published service through a private endpoint (forwarding rule) in the consumer VPC, exposing only that service and avoiding full VPC peering.
- Organization Policy constraints such as constraints/compute.vmExternalIpAccess restrict external IP assignment across projects, enforcing a no-public-IP posture centrally.
- Create a custom VPC with gcloud compute networks create prod-vpc --subnet-mode=custom, then add subnets with gcloud compute networks subnets create --network --region --range.
- Enable VPC Flow Logs at subnet creation/update with --enable-flow-logs (or --logging-flow-sampling), and tune --logging-aggregation-interval (e.g., INTERVAL_5_SEC) to balance detail against log volume and cost.
- To cut Flow Log cost while keeping value, lower the flow sampling rate, increase the aggregation interval, and filter to relevant traffic via metadata/filter expressions.
- VPC Network Peering connects two VPCs so their VMs reach each other on internal addresses with no gateway. It requires non-overlapping ranges, is not transitive (A-B and B-C does not give A-C), and each side must create its own peering for the connection to become active.
- Create a Shared VPC by designating a host project, then attaching service projects. Sharing can be for all subnets or specific ones, and a service-project user needs roles/compute.networkUser on the individual subnet - granting it at project level shares far more than intended.
- Private services access uses an allocated internal range in your VPC that Google peers a producer network into, which is how managed services such as Cloud SQL get private IPs. Private pools do the same for Cloud Build workers, so builds can reach private resources.
- A subnet’s primary IPv4 range can be expanded after creation but never shrunk, and the new range must not overlap anything already routed. Secondary ranges are added separately and are what alias IPs and GKE Pod and Service ranges draw from.
- VPC Service Controls draw a perimeter around managed services such as Cloud Storage and BigQuery so data cannot be read out to a project outside it, even by an identity whose IAM would otherwise allow it. It complements firewall rules, which control packets rather than API access.
- Static routes are configured by hand with a destination and next hop; dynamic routes are learned over BGP by a Cloud Router. Regional dynamic routing advertises and learns only within the router’s region, while global dynamic routing shares those routes across every region in the VPC - which is what makes a single interconnect serve the whole network.
- Route selection goes by longest prefix match first, then by priority where a lower number wins, and static routes can be scoped to specific instances by network tag. Ties between equal routes result in equal-cost multi-path forwarding rather than one being ignored.
- An internal passthrough load balancer can be the next hop of a static route, which is the supported way to send traffic through a highly available pool of appliances: the route stays valid while the load balancer picks a healthy backend, so a failed appliance does not blackhole traffic.
- Peering exchanges subnet routes automatically but not static or dynamic ones. Turn on custom route import and export on both sides of a peering when a VPC must reach an on-premises network through its peer, and remember each side controls its own direction.
- Network Connectivity Center uses a hub with spokes: VPC spokes attach whole VPCs for any-to-any connectivity, hybrid spokes attach VPN tunnels or interconnect attachments, and producer spokes attach managed service producer networks. It is how a mesh replaces a full grid of peerings.
- Choose the Network Connectivity Center topology to match the requirement: a mesh where every spoke reaches every other, or a star with a central hub where spokes reach the hub and not each other, which is the pattern for keeping tenants isolated while all reaching shared services.
- Network Connectivity Center supports Private NAT for translating between spokes with overlapping ranges, and Private Service Connect propagation so a PSC endpoint published in one spoke is reachable from the others without republishing it.
- IP and CIDR range filters on a Network Connectivity Center spoke control which prefixes are exported into the hub, which is how you connect a VPC without advertising every subnet in it. Monitor and troubleshoot the hub with the route tables and Network Intelligence Center.
- A VPC-native GKE cluster assigns Pod and Service addresses from secondary ranges on the subnet using alias IPs, so Pod addresses are routable in the VPC and visible to firewall rules. Size the Pod range for the maximum nodes multiplied by Pods per node, because it cannot be resized later without rebuilding.
- A private GKE cluster gives nodes internal addresses only, reaching the internet through Cloud NAT. The control plane is reached through a private endpoint, restricted by authorized networks, or through the DNS-based endpoint, which resolves by IAM rather than by source address and so works from anywhere the caller is authorised.
- GKE Dataplane V2 replaces kube-proxy with eBPF, which is what provides network policy enforcement with logging and better observability. GKE network policies then control Pod-to-Pod traffic by label, which VPC firewall rules cannot do because they see the node, not the Pod.
- IP masquerade (SNAT) rewrites Pod source addresses to the node address for destinations outside the cluster. Configure the nonMasqueradeCIDRs list so traffic to your own VPC and on-premises ranges keeps the real Pod IP, and only traffic leaving to the internet is masqueraded.
- Cluster DNS has three options to distinguish: kube-dns as the in-cluster default, NodeLocal DNSCache as a per-node cache that cuts latency and load on kube-dns, and Cloud DNS for GKE, which moves resolution to the managed service and removes the in-cluster DNS Pods entirely.
Domain 3: Configuring Managed Network Services
- The global external Application Load Balancer (HTTP/S) operates at Layer 7, uses a single anycast IP advertised from Google's global edge PoPs, and routes by URL map (host/path) for globally distributed apps.
- The internal passthrough Network Load Balancer keeps TCP/UDP traffic private within a region at Layer 4, does not proxy, and preserves the client source IP.
- The external passthrough Network Load Balancer (Layer 4) preserves original client source IP and supports non-HTTP protocols, unlike the proxying Application Load Balancer.
- Cloud CDN integrates with the external Application Load Balancer and caches HTTP(S) responses at Google edge PoPs; subsequent hits are served from the nearest edge, reducing latency and origin egress.
- Cloud CDN cache modes: USE_ORIGIN_HEADERS respects Cache-Control, CACHE_ALL_STATIC caches static content by default, and FORCE_CACHE_ALL caches all responses regardless of origin headers (use carefully).
- Reduce CDN origin egress by enabling negative caching for error responses, setting longer TTLs for static content, using request coalescing, and excluding unnecessary cookies and query parameters from the cache key.
- Cloud DNS is Google's managed authoritative DNS (analogous to AWS Route 53); it supports public zones and private zones visible only to authorized VPCs for internal name resolution.
- Cloud DNS routing policies (geolocation, weighted round robin, failover) return different answers based on client origin or health, complementing the load balancer's anycast direction of clients to the nearest backend.
- Private Service Connect publishes a producer service behind a service attachment that consumers reach via a PSC endpoint, enabling private one-way service exposure without exposing the full network.
- A backend service's balancing mode (RATE, UTILIZATION, or CONNECTION) plus the capacity scaler, combined with MIG autoscaling, control how traffic distributes and how backends absorb bursty load.
- Premium Tier global backbone routing plus Cloud CDN improves performance for users far from the origin region by entering Google's network at the nearest edge.
- Cross-region backend services let a global load balancer overflow traffic to backends in other regions when the closest region is at capacity, improving resilience.
- Proxy-based load balancers (Application LB, proxy Network LB) replace the client IP with a Google proxy IP; preserve original client IP via the X-Forwarded-For header or use a passthrough LB instead.
Domain 4: Configuring and Implementing Hybrid and Multicloud Network Interconnectivity
- Cloud Router uses BGP as its only dynamic routing protocol to exchange routes with on-prem peers over HA VPN tunnels or Interconnect VLAN attachments, auto-advertising new VPC subnets and learning remote prefixes.
- HA VPN provides a 99.99% SLA using two gateway interfaces, each with its own external IP, establishing redundant IPsec tunnels; it requires a Cloud Router with a BGP session and does not support static routing.
- Dedicated Interconnect is a direct physical 10/100 Gbps connection at a Google peering facility with no public internet traversal; Partner Interconnect connects through a service provider for smaller (50 Mbps-50 Gbps) capacities.
- For resilience, deploy redundant connections across two separate metro edge availability domains with redundant Cloud Routers, and optionally use HA VPN as a backup path to Interconnect.
- Path preference between Interconnect and VPN is controlled with BGP attributes via Cloud Router: advertise the preferred (Interconnect) path with higher priority / lower MED so it wins over the VPN path.
- ECMP (equal-cost multipath) over BGP on Cloud Router across multiple Interconnect attachments with equal priorities load-balances traffic and increases aggregate throughput.
- Create a Cloud Router with gcloud compute routers create --network=prod-vpc --region=us-central1 --asn=65001, choosing a private ASN (64512-65534 or the 4-byte ranges).
- Add a BGP peer with gcloud compute routers add-bgp-peer using --interface, --peer-asn, and --peer-ip-address to establish the session over a tunnel or VLAN attachment.
- Control advertised routes with --advertisement-mode=CUSTOM plus --set-advertisement-groups=ALL_SUBNETS and --set-advertisement-ranges for specific custom prefixes; the default DEFAULT mode advertises subnets automatically.
- Create a Partner Interconnect VLAN attachment with gcloud compute interconnects attachments partner create using --router and --edge-availability-domain to select the redundancy zone.
- Cloud DNS hybrid resolution uses outbound forwarding zones (and outbound server policy) for cloud-to-on-prem queries and an inbound server policy (which creates a forwarder IP) for on-prem-to-cloud queries.
- Network Connectivity Center connects multiple on-prem sites (VPN/Interconnect spokes) and VPC spokes through a managed hub for transitive hybrid connectivity without a transit VPC.
- Interconnect generally offers lower egress pricing and higher, more predictable bandwidth than Cloud VPN; right-size Partner Interconnect VLAN attachment capacity to actual demand to control cost.
- HA VPN tunnels must connect to a peer gateway; for an on-prem device with two interfaces, use a two-interface peer gateway, and for cloud-to-cloud use HA VPN on both ends with BGP.
Domain 5: Managing, Monitoring, and Troubleshooting Network Operations
- VPC Flow Logs record sampled metadata (5-tuple source/destination IP and port, protocol, bytes, packets, and allowed/denied disposition) per VM, GKE node, and Cloud VPN tunnel network interface.
- Flow Logs export to Cloud Logging and can be sinked to BigQuery for SQL analysis to identify which subnets and VMs generate the most egress, or detect traffic anomalies.
- Network Intelligence Center's Connectivity Tests run a configuration-based simulated trace (analyzing routes, firewall rules, peering, and LB config) without sending real packets, ideal for pinpointing why connectivity fails.
- Network Intelligence Center centralizes Topology, Connectivity Tests, Performance Dashboard, Firewall Insights, and Network Analyzer for diagnostics and optimization.
- The Performance Dashboard in Network Intelligence Center surfaces packet loss and latency between Google Cloud zones/regions and between your VMs, helping isolate performance issues.
- Create a Connectivity Test with gcloud network-management connectivity-tests create specifying --source-instance, --destination-ip-address (or destination instance), --protocol, and ports.
- Update Flow Log sampling on an existing subnet with gcloud compute networks subnets update --logging-flow-sampling=0.5 (a value 0.0-1.0 controlling the fraction of flows captured).
- Combine Cloud Monitoring network-egress alerting policies with Cloud Billing budget alerts to catch unexpected egress spikes both technically and financially.
- Cloud Monitoring CDN metrics (cache hit ratio and origin request count) reveal CDN effectiveness; a low hit ratio signals cache-key or TTL tuning is needed.
- Firewall Insights and the Network Analyzer (in Network Intelligence Center) detect shadowed, overly permissive, or unused firewall rules and misconfigurations proactively.
- Proactive network operations pair the Performance Dashboard for live latency/packet-loss visibility with Cloud Monitoring alerting policies on key network metrics to detect degradation before users do.
Domain 6: Configuring, Implementing and Managing a Cloud Network Security Solution
- Cloud Armor security policies attach to a backend service on an external Application Load Balancer and are enforced at Google’s edge, before traffic reaches your backends. Edge security policies filter at the CDN and Cloud Storage layer; backend security policies protect the backend service itself, and a request can pass through both.
- Preconfigured WAF rules implement the OWASP ModSecurity Core Rule Set for SQL injection, cross-site scripting and remote file inclusion, tunable by sensitivity level. Start at a lower sensitivity in preview mode, review what would have been blocked, then enforce - turning the strictest level straight on in production reliably blocks legitimate traffic.
- Cloud Armor rules are evaluated by ascending priority and the first match wins, so put specific allow rules above broad denies and keep the default rule at priority 2147483647. Custom rules are written in the Common Expression Language against request attributes such as origin.ip, request.path and request.headers.
- Advanced network DDoS protection defends passthrough load balancers and protected endpoints against volumetric layer 3 and 4 attacks, while Adaptive Protection learns a baseline of normal traffic and proposes a targeted rule when it detects an anomaly - which you review rather than apply blindly.
- Rate limiting comes in two forms: throttle caps requests to a configured rate and lets the rest through slowly, while ban blocks an offending key outright for a set duration once it exceeds the threshold. Choose the key deliberately - IP, HTTP header, cookie or region.
- Bot management integrates Cloud Armor with reCAPTCHA so a rule can issue a challenge rather than a flat block, letting real users through while stopping automation. Google Threat Intelligence named IP lists let a rule match known malicious sources, Tor exit nodes or crawlers without you maintaining the list.
- Plan a firewall strategy before writing rules: hierarchical firewall policies at the organization and folder level for guardrails that projects cannot override, Cloud NGFW network and global policies for the estate, VPC firewall rules for per-network specifics, and third-party appliances where deep inspection is required.
- GCP has two firewall constructs: VPC firewall rules (per-network) and hierarchical firewall policies (applied at the organization or folder level for centralized governance).
- Effective policy in a hierarchical situation is evaluated from the top down: organization policies, then folder policies, then the network-level policy, then VPC firewall rules. A rule that matches with allow or deny ends evaluation, while goto_next hands the decision to the next level - which is how a parent delegates a decision instead of forcing it.
- VPC firewall rules can target by network tag or service account in addition to IP range; service-account-based rules follow the VM's identity even when its IP changes, making them robust in dynamic fleets.
- Micro-segmentation means writing rules against workload identity rather than topology. Secure tags are IAM-governed key/value tags bound to resources and usable in Cloud NGFW policies across the hierarchy; network tags are plain labels any instance editor can set. Use secure tags or service accounts where the rule matters.
- Create firewall rules with gcloud compute firewall-rules create using --source-ranges, --target-tags (or --target-service-accounts), --direction, --action, and --rules.
- Every rule is defined by the same criteria, and the exam tests them precisely: priority (0 highest to 65535 lowest), direction (ingress or egress), action (allow or deny), protocol and ports, and source and destination. Ingress rules match on source; egress rules match on destination.
- Consolidating many overlapping source ranges into summarized CIDR blocks in a single firewall rule reduces rule sprawl and stays within the per-network rule limits.
- Know the Cloud NGFW tiers: Essentials provides VPC firewall rules and network firewall policies at no extra cost; Standard adds regional policies with fully qualified domain name, geolocation and Threat Intelligence objects; Enterprise adds layer 7 inspection with an intrusion prevention service for traffic between workloads.
- Cloud NGFW policies support GKE and Cloud Load Balancing, so a policy can target Pod and Service traffic and the load balancer’s own health-check and proxy ranges. Forgetting to allow the health-check ranges (35.191.0.0/16 and 130.211.0.0/22) is the classic cause of backends that never become healthy.
- Migrate from VPC firewall rules to Cloud NGFW policies incrementally: create the policy and associate it with the network, mirror the existing rules, verify with the effective-policy view and firewall logs, then remove the legacy rules. Both coexist during the migration, evaluated in hierarchy order.
- Enable Firewall Rules Logging on the rules that matter to see which connections a rule actually allowed or denied, and pair it with VPC Flow Logs for the traffic view. Logging every rule is expensive and noisy, so enable it on the deny rules and the ones under investigation.
- When traffic is blocked, find the responsible rule rather than adding a broader allow: check rules applied to the target’s tags and service account and the hierarchical policies above the network, then fix the direction, protocol, ports, source or target - or give the correct rule a lower priority number so it matches first.
- Cloud NAT is a managed, distributed (non-instance-based) service that gives VMs without external IPs outbound internet access by translating internal IPs to a pool of NAT IPs; it allows no unsolicited inbound connections.
- Cloud NAT IP addresses can be allocated automatically, where Google adds and removes addresses as demand changes, or manually, where you reserve specific static addresses. Choose manual whenever an external party has to allow-list your egress addresses, because automatic allocation will change them.
- Cloud NAT port exhaustion is fixed by increasing minimum ports per VM and/or adding more NAT IP addresses; each NAT IP provides about 64,512 usable source ports per destination.
- Static port allocation reserves the same number of ports for every VM whether or not it needs them; dynamic port allocation lets a busy VM scale between a minimum and maximum, which uses the NAT IP pool far more efficiently on fleets with uneven traffic.
- Secure Web Proxy is a managed forward proxy for outbound web traffic that applies policy on URL, domain and TLS attributes with a workload identity attached, so egress is filtered by rule rather than merely translated. Cloud NAT gives connectivity; Secure Web Proxy gives control over where workloads may go.
- Centralized egress patterns place Cloud NAT (and optionally Secure Web Proxy or an NVA) in a hub VPC, with spoke custom routes directing internet-bound traffic through the hub for uniform egress control.
- Route and inspect inter-VPC traffic through a self-managed network virtual appliance on a multi-NIC VM with one interface in each VPC. For high availability, put several appliances behind an internal passthrough load balancer and use that load balancer as the next hop of a route, so failover does not depend on a single instance.
- Policy-based routes select a next hop by traffic attributes - protocol, ports, source and destination ranges - rather than by destination prefix alone, which is how you send only the traffic that needs inspection through an appliance while everything else takes the normal path.
- Packet Mirroring copies full packets from selected instances to a collector behind an internal load balancer for intrusion detection or forensic capture, and it mirrors both ingress and egress by default. It consumes the mirrored VM’s bandwidth, so filter by protocol, port or CIDR rather than mirroring everything. Out-of-band Network Security Integration is the managed alternative for inserting third-party inspection without a mirror of your own.
Google Cloud Network Engineer exam tips
- Read each scenario for the deciding constraint - cost, security, latency/performance, or resilience - because most answer choices are technically valid and only one optimizes the stated priority.
- Memorize the load balancer decision tree: global vs regional, external vs internal, Layer 7 proxy (Application LB) vs Layer 4 passthrough (Network LB), and which preserve the client source IP.
- Know the hybrid connectivity matrix cold: HA VPN (99.99% SLA, IPsec, BGP required) vs Dedicated vs Partner Interconnect, and how Cloud Router BGP priority/MED chooses the active path.
- For routing and firewall questions, remember the rule: lower priority number wins, the first match applies, and a custom VPC defaults to deny-all ingress and allow-all egress.
- When a question is about diagnosis, map the symptom to the right tool: Connectivity Tests for config/path failures, VPC Flow Logs for traffic volume and allowed/denied data, and Performance Dashboard for latency and packet loss.
- Network security is its own section worth ~13%, and it is the one most study material omits. Cover Cloud Armor end to end (edge and backend policies, preconfigured WAF rules, Adaptive Protection, rate limiting, bot management), the Cloud NGFW tiers, hierarchical policy evaluation, Cloud NAT and Secure Web Proxy, and Packet Mirroring.
- Firewall questions turn on evaluation order. Rules are matched by ascending priority with the first match winning, hierarchical policies are evaluated above network policies and VPC rules, and goto_next is what lets a parent delegate rather than decide. Ingress rules match on source, egress rules on destination.
- Prefer identity over addresses when a scenario asks for maintainable segmentation: secure tags and service accounts in rules follow the workload, while IP ranges break the moment something is rebuilt in a different subnet.
Study guide FAQ
What are the exam sections and how are they weighted?
Google publishes six: designing and planning a Google Cloud VPC network (~21%), implementing a VPC network (~20%), configuring managed network services (~16%), configuring and implementing hybrid and multicloud network interconnectivity (~16%), managing, monitoring and troubleshooting network operations (~14%), and configuring, implementing and managing a cloud network security solution (~13%). The security section is a full sixth of the blueprint and is frequently missing from older study material.
How is this exam structured and what score do I need to pass?
It is a 2-hour (120-minute) exam of roughly 50-60 multiple-choice and multiple-select questions. Google does not publish a fixed passing score, and the certification is valid for two years. Most questions are scenario-based design and troubleshooting problems rather than simple recall.
What is the difference between VPC Network Peering and Private Service Connect?
VPC Network Peering joins two entire VPCs so all their VMs can reach each other over internal IPs, but it is non-transitive and forbids overlapping CIDR ranges. Private Service Connect instead exposes only a single producer service through a private endpoint in the consumer VPC, which works even with overlapping address space and gives finer-grained, one-way access.
When should I choose Cloud Interconnect over Cloud VPN?
Choose Dedicated or Partner Interconnect when you need high, predictable bandwidth (10/100 Gbps), the lowest latency, traffic that stays off the public internet, and lower egress pricing. Choose HA VPN when you need quick setup, encryption over the public internet, lower bandwidth, or a cost-effective backup path to Interconnect. Both use Cloud Router with BGP for dynamic routing.
How do I troubleshoot why two resources cannot communicate?
Start with a Connectivity Test in Network Intelligence Center to simulate the path and reveal a blocking firewall rule, missing route, or peering/LB misconfiguration without sending packets. Then confirm with VPC Flow Logs, which show whether real traffic was allowed or denied. Fix it by adding or adjusting a VPC firewall rule (or hierarchical policy) with the correct direction, ports, and a higher-precedence (lower-number) priority.
Official exam sources
The domain names and weightings on this page follow the published exam blueprint. Each source below records what it confirmed and when it was read, so the split can be checked rather than taken on trust.
- Google Cloud - Professional Cloud Network Engineer exam guide (PDF)link and content verified 8 September 2026Google's web exam-guide URL for this exam now returns a 301 redirect to this PDF, which makes the PDF the current first-party guide rather than one of two competing versions.