GCP Network Engineer common mistakes
GCP Network Engineer · Understand the traps and how to avoid them.
When asked to connect two VPCs, the candidate reaches for VPC Network Peering by default and then asserts that transitive routing works (A peers with B, B peers with C, therefore A reaches C), and further claims that peering propagates custom routes learned from Cloud VPN or Cloud Interconnect.
Peering is the first interconnect concept most people learn, and in traditional routing domains route propagation through a routing peer feels obvious. Candidates carry over the mental model of BGP route reflection or of a hub router, and they do not internalize that peering is strictly non-transitive and that by default only subnet routes are exchanged, not dynamic routes from hybrid attachments.
What to do instead
Memorize the two peering properties as hard constraints: non-transitive (no edge between A and C unless explicitly peered) and non-propagating for dynamic routes. For full mesh requirements, compute the number of peering links needed (n(n-1)/2) and note the per-VPC peering limit. For hub-and-spoke with shared hybrid reachability, design around a Shared VPC or Network Connectivity Center hub rather than chained peering, and state explicitly that custom route import/export must be enabled when you do want dynamic routes exchanged.
The candidate designs a subnet with a /24 primary range, then separately plans a second subnet in the same region with an overlapping range, or sizes a subnet so small that GKE nodes, Pods, and Services cannot fit, and only discovers the problem when describing the implementation.
Candidates plan address space per subnet in isolation instead of per VPC and per region, and they forget that a subnet's primary range is reserved for VM NICs while GKE secondary ranges (Pods and Services) are separate, sized allocations. They also forget Google reserves four addresses in every subnet range, so a /29 does not yield eight usable VM addresses.
What to do instead
Always design an RFC 1918 supernet per VPC and carve non-overlapping regional blocks from it before writing any subnet. Size subnets from the workload, not the other way round: for GKE, plan a node range plus distinct Pod and Service secondary ranges, remembering that the default Pod range per node is large and that the cluster Pod CIDR must accommodate max Pods per node times max nodes. Reserve room for future regions and for peering or hybrid ranges, and explicitly subtract the four reserved addresses when validating usable capacity.
The candidate treats firewall rules as ordered and stateful in the wrong direction: they write a lower-priority deny and expect it to override a higher-priority allow, or they assume that allowing ingress automatically permits the return path for a connection initiated from outside, or they forget that the implied deny-all ingress and allow-all egress exist.
Ordered-ACL intuition comes from on-premises firewalls, where rule order matters and a deny above an allow wins. Google Cloud VPC firewall rules are evaluated by priority with the lowest number winning and are stateful for established connections, and there is no ordering by list position. Candidates also forget the implied rules, so they misdiagnose connectivity failures that are actually the default deny.
What to do instead
State the evaluation model explicitly in every answer: rules are prioritized (0 is highest, 65535 is lowest), the first matching rule by priority decides, and return traffic for an established session is allowed regardless of ingress rules. When troubleshooting, enumerate the implied deny-ingress and allow-egress rules and check whether a higher-priority rule (including a hierarchical firewall policy or a VPC firewall policy) is shadowing the intended allow. Use firewall rule logging or Connectivity Tests rather than guessing.
The candidate plans a hybrid connection with Cloud VPN and then asserts that a single VPN tunnel provides an SLA-backed, highly available path, or configures a Cloud Router with a single interface and a single tunnel and calls the design highly available.
The exam's hybrid domain rewards knowing the availability topologies, and candidates who have only labbed a single tunnel assume it is production-grade. They do not distinguish the 99.9 percent and 99.99 percent SLA tiers, do not know that Cloud VPN requires redundancy across two tunnels on distinct Google edge locations and ideally distinct customer gateways, and do not account for the fact that a Cloud Router needs BGP sessions on each tunnel.
What to do instead
Design to a named topology: for 99.99 percent, use two tunnels terminating on two different Google edge availability domains with redundant customer-side gateways and separate Cloud Router interfaces (or a second router), and confirm BGP advertises the same prefixes over both. For 99.9 percent, a single tunnel pair with redundant Google edge is the minimum. Always state that Cloud Router runs BGP, that you must configure the peer ASN and the advertised and learned ranges, and that dynamic routes must be imported into the VPC to be usable.
When asked for private connectivity to Google APIs, the candidate selects Private Service Connect or Private Google Access without distinguishing them, or claims that Private Google Access gives on-premises hosts access to Google APIs over the VPN or Interconnect.
The names are similar and the scoping rules are subtle. Private Google Access is a subnet-level flag that lets VM instances with only internal IPs reach Google APIs and services through Google's network; it does not extend to on-premises clients, which need a route and either Private Google Access on the target subnet or Private Service Connect endpoints. Candidates conflate the two and misattribute the scope.
What to do instead
Write the decision rule plainly: Private Google Access is enabled per subnet and affects only resources in that VPC (including on-premises traffic that is routed into that VPC and arrives at a subnet with the flag on, subject to routing). Private Service Connect creates a private endpoint (a forwarding rule with an internal IP) that consumers in a VPC or over hybrid links can target, and it can also expose a producer service. For on-premises to Google APIs, route the traffic over the Interconnect or VPN into the VPC and ensure the relevant subnet has Private Google Access, or publish a PSC endpoint reachable over the hybrid path.
The candidate configures Cloud NAT and then asserts that it allows inbound connections from the internet to internal VMs, or that Cloud NAT is required for egress from VMs that have external IPs, or that a single NAT gateway is regional and therefore highly available without any configuration.
NAT semantics differ from a traditional appliance. Cloud NAT is a managed, regional, egress-only translation service that does not accept inbound connections and does not require external IPs on the VMs. Candidates also do not know that Cloud NAT is automatically redundant within a region when configured with the default (or with multiple NAT IPs) but that it depends on Cloud Router and on the subnet having no conflicting route.
What to do instead
State Cloud NAT's contract: egress-only, regional, no inbound initiation, used by VMs without external IPs, and reliant on a Cloud Router in the same region. For inbound, use an external load balancer or a bastion with an external IP. When sizing, specify the number of NAT IP addresses and ports per VM to avoid port exhaustion, and remember that Cloud NAT cannot be used with a subnet that has a custom route sending 0.0.0.0/0 elsewhere unless the NAT is configured to override.
The candidate describes an external Application Load Balancer as if it were a regional passthrough Network Load Balancer, or places a global external Application Load Balancer backend in a single region and claims it provides global anycast failover without a global backend service and health checks.
Load balancer families look interchangeable on a feature list, and candidates memorize names without the traffic path. They miss that the global external Application Load Balancer uses a single global anycast VIP with URL-map routing and Google Front End termination, while a passthrough Network Load Balancer preserves the client IP and is regional, and that a proxy Network Load Balancer is the regional TCP proxy option.
What to do instead
Build a selection table keyed on protocol, scope, and proxy behavior: global external Application Load Balancer for HTTP(S) with a global VIP, regional external Application Load Balancer for regional HTTP(S), external proxy Network Load Balancer for regional TCP with proxy semantics, external passthrough Network Load Balancer for regional TCP/UDP preserving client IP, and internal variants for private traffic. Then verify the backend service is global for a global LB and that health checks target the correct port and protocol, since a mismatched health check silently removes backends.
The candidate proposes Cloud Interconnect and then treats a Dedicated Interconnect and a Partner Interconnect as interchangeable, or assumes that a single Interconnect attachment is redundant, or forgets that VLAN attachments and Cloud Router BGP sessions are what actually carry routes.
The product family is one name with two very different delivery models. Dedicated Interconnect requires colocation in a Google peering facility and a 10 Gbps or 100 Gbps circuit; Partner Interconnect goes through a supported provider and supports lower bandwidths. Candidates also skip the attachment and BGP layer and assume the physical circuit alone provides routing and redundancy.
What to do instead
State the delivery model and redundancy explicitly: Dedicated Interconnect needs a cross-connect in a Google facility and is ordered in 10 Gbps or 100 Gbps increments, while Partner Interconnect is provisioned through a provider at 50 Mbps to 50 Gbps. For production, use two Interconnect connections in different metros (or a topology with two attachments on distinct edge availability domains) and confirm each VLAN attachment has a Cloud Router BGP session. Remember that the Interconnect itself is not a route source until BGP advertises prefixes into the VPC.
The candidate designs a Shared VPC but places the host project and service projects incorrectly, or grants network admin roles at the wrong level, or assumes that a service project can create its own subnets in the shared network.
Shared VPC inverts the usual ownership model, and candidates mix up which project owns the network and which owns the resources. They also miss the IAM split: the host project owns subnets and firewall rules, while service project admins can use subnets but not create or delete them, and the Shared VPC Admin role is granted at the organization or folder level, not per project.
What to do instead
Write the ownership matrix: host project contains the VPC, subnets, and firewall rules; service projects contain the workloads that attach to host subnets. Grant Shared VPC Admin at the organization or folder level, grant Network User on specific subnets to service project principals, and note that subnet creation stays with the host project's network admins. If a service project needs its own address space, use a separate VPC with peering rather than trying to carve subnets from the shared network.
The candidate debugs a connectivity failure by guessing at firewall rules and routes, and never uses VPC Flow Logs, Firewall Rules Logging, Connectivity Tests, or Network Intelligence Center, and does not know that flow logs are configured per subnet and sampled.
Troubleshooting questions reward a methodical evidence path, but candidates answer from intuition because they have not used the observability tooling. They also do not know the configuration surface: VPC Flow Logs are enabled per subnet with an aggregation interval and sampling rate, firewall rules logging is per rule, and Connectivity Tests can trace a path between endpoints including configuration analysis.
What to do instead
Adopt a fixed diagnostic order: confirm the VM has the expected IP and route (check the VPC routes and the effective route for the destination), confirm the firewall rule and its priority with rules logging, confirm the NAT or hybrid path with flow logs, then run a Connectivity Test between source and destination to get configuration-level analysis. State the tool and its scope in the answer, and remember that flow logs record metadata, not payload, and that logging must be enabled before the incident.