Overview
This section is hands-on configuration of the network core. You create custom mode VPCs, subnets and firewall policies, set up VPC Network Peering, attach service projects to a Shared VPC host, grant subnet-level IAM, enable Private Google Access, expand subnet ranges and build VPC Service Controls perimeters. Routing work covers static routes, Cloud Router dynamic routes, route priority and tags, internal load balancers as next hops, custom route exchange and policy-based routes.
Network Connectivity Center appears with VPC, hybrid and producer spokes, mesh and star topologies, Private NAT, Private Service Connect propagation and range filters. The GKE subsection is detailed: VPC-native and Shared VPC clusters, private endpoints, authorized networks, the DNS-based endpoint, Dataplane V2, IP masquerading, network policies, additional Pod ranges and cluster DNS options.
How it's tested
Implementation questions describe a partly built environment and a symptom or a new requirement. You choose the configuration change that works with the least disruption. Watch for settings that are fixed at creation, such as cluster type, and for options that would require rebuilding.
-
Fix the route
You decide why traffic follows the wrong path by applying longest prefix match, priority, tags and policy-based route order.
-
Grant the right access
You give service projects, GKE service accounts or peers the minimum roles and route exchange needed to use shared networking.
-
Recover IP space
You expand a subnet, add secondary or additional Pod ranges, or adjust maximum Pods per node without rebuilding.
A GKE cluster cannot add nodes because its Pod secondary range is full, while the subnet primary range has space. Recreating the cluster would cause downtime. The better fix is to add an additional Pod range to the subnet and create a new node pool that uses it, possibly with a lower maximum Pods per node. Existing node pools keep their current range.
Objectives 4
Official objectives from the Google Cloud outline, in outline order.
2.1 Configuring VPCsNetworks, subnets, firewall policies, peering, Shared VPC, Private Google Access, subnet expansion and VPC Service Controls.
- What it means
- This objective covers creating and adjusting the core VPC resources: networks, subnets and firewall policies, private pools, peering connections, Shared VPC host and service projects with subnet permissions, Private Google Access, expansion of subnet ranges, and VPC Service Controls perimeters.
- What to understand
- Custom mode VPCs let you define every subnet; auto mode creates one subnet per region from 10.128.0.0/9 and suits only simple setups. A subnet primary range can be expanded but never shrunk. Shared VPC needs a Shared VPC Admin to enable the host project and attach service projects, then Compute Network User on the host project or on individual subnets. Private Google Access is enabled per subnet. VPC Service Controls perimeters restrict access to Google APIs such as Cloud Storage and BigQuery to protected projects, and dry run mode shows violations before enforcement.
- How it shows up
- Expect questions on which role or subnet setting is missing, or how to block data exfiltration through Google APIs.
- Common confusion
- Firewall rules control packets to VMs; VPC Service Controls control API access to Google services.
2.2 Configuring VPC routingStatic and dynamic routes, routing mode, tags and priority, ILB next hops, custom route exchange and policy-based routes.
- What it means
- This objective covers how VPC routes are created and selected: static routes, Cloud Router dynamic routes, regional or global dynamic routing, route priority with network tags, an internal load balancer as next hop, importing and exporting custom routes over peering or Network Connectivity Center, and policy-based routing.
- What to understand
- Google Cloud chooses the most specific destination first, then the lowest priority number among equal prefixes. Routes with network tags apply only to instances that carry the tag. Subnet routes cannot be overridden by less specific custom routes. Over peering, custom static and dynamic routes are exchanged only when export and import are enabled on both sides. Policy-based routes match on source, destination and protocol and send traffic to an internal passthrough Network Load Balancer, typically for appliance inspection. With global routing, routes learned in another region receive an added cost penalty.
- How it shows up
- Scenarios show a route table and a misrouted flow; you identify which route wins and why.
- Common confusion
- Lower priority numbers win; a priority 100 route beats a priority 1000 route.
2.3 Configuring Network Connectivity CenterSpoke types, mesh and star topologies, Private NAT, PSC propagation, range filters and troubleshooting.
- What it means
- This objective covers configuring a Network Connectivity Center hub for VPC connectivity: choosing VPC, hybrid or producer spokes, applying mesh or star topology, using Private NAT and Private Service Connect propagation, filtering exported ranges, and monitoring and troubleshooting the hub.
- What to understand
- VPC spokes attached to one hub exchange subnet routes transitively, which replaces large peering meshes. In a mesh topology every spoke reaches every other; in a star topology edge spokes reach only center spokes, which isolates environments. Producer VPC spokes bring in managed service producer networks reached through private services access. Include and exclude export filters stop overlapping or sensitive ranges from propagating. Private NAT translates traffic between spokes whose ranges overlap. PSC connection propagation makes Private Service Connect endpoints in one spoke reachable from other spokes.
- How it shows up
- Look for many VPCs needing transitive reach, isolation between environments, or overlapping ranges.
- Common confusion
- A hub does not make peering transitive; VPC spokes replace peering for those networks.
2.4 Configuring and maintaining GKE clustersVPC-native and Shared VPC clusters, private endpoints, authorized networks, DNS endpoint, Dataplane V2, masquerade, policies, ranges and DNS.
- What it means
- This objective covers the networking settings of running GKE clusters: VPC-native clusters with alias IPs, clusters in Shared VPC, private nodes and endpoints, authorized networks and DNS-based control plane access, Dataplane V2, SNAT and IP masquerade rules, network policies, Pod, Service and additional Pod ranges, and cluster DNS with kube-dns, Cloud DNS or NodeLocal DNSCache.
- What to understand
- In a Shared VPC cluster, the service project's GKE service account needs Compute Network User and Host Service Agent User on the host project, and the host defines the secondary ranges. Authorized networks limit which CIDRs reach the control plane. The DNS-based endpoint gives IAM-checked control plane access without exposing an IP address. Dataplane V2 uses eBPF and enforces network policies natively with logging. The ip-masq-agent decides which destinations see Pod IPs and which see the node IP. NodeLocal DNSCache reduces lookup latency and load on cluster DNS.
- How it shows up
- Expect symptoms such as Pods reaching on-premises with the wrong source IP or kubectl access being blocked.
- Common confusion
- Network policies filter Pod traffic inside the cluster; VPC firewall rules filter at the node level.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Custom mode VPC
VPC where you create every subnet yourself.
- Remember
- Preferred for production and hybrid.
- Tested as
- Initial build questions.
- Trap
- Using auto mode with ranges that overlap on-premises.
-
Subnet expansion
Enlarging a subnet primary range in place.
- Remember
- Expansion only; ranges cannot shrink.
- Tested as
- IP exhaustion fixes.
- Trap
- Recreating a subnet unnecessarily.
-
Compute Network User
Role that lets a project use a shared subnet.
- Remember
- Grant at subnet level for least privilege.
- Tested as
- Shared VPC access errors.
- Trap
- Granting Network Admin instead.
-
Route selection
Most specific prefix, then lowest priority number.
- Remember
- Tags restrict which instances use a route.
- Tested as
- Path questions.
- Trap
- Thinking priority beats prefix length.
-
Policy-based routes
Routes matched on source, destination and protocol.
- Remember
- Next hop is an internal passthrough Network Load Balancer.
- Tested as
- Appliance inspection.
- Trap
- Expecting them to point to any VM IP.
-
Custom route import and export
Peering settings that share static and dynamic routes.
- Remember
- Both sides must enable them.
- Tested as
- On-premises reach across peering.
- Trap
- Enabling export on only one side.
-
NCC star topology
Center and edge spoke groups.
- Remember
- Edge spokes cannot reach each other.
- Tested as
- Environment isolation.
- Trap
- Using mesh where isolation is required.
-
VPC Service Controls
Perimeter around projects for Google API access.
- Remember
- Use dry run before enforcing.
- Tested as
- Data exfiltration questions.
- Trap
- Expecting firewall rules to block API copying.
-
Additional Pod ranges
Extra secondary ranges assigned to new node pools.
- Remember
- Avoids rebuilding a cluster.
- Tested as
- Pod IP exhaustion.
- Trap
- Thinking the original Pod range can be resized.
-
GKE Dataplane V2
eBPF-based datapath for GKE.
- Remember
- Built-in network policy enforcement and logging.
- Tested as
- Policy and visibility questions.
- Trap
- Installing a separate policy add-on.
-
ip-masq-agent
Controls SNAT of Pod traffic to the node IP.
- Remember
- nonMasqueradeCIDRs keep Pod IPs visible.
- Tested as
- On-premises allowlisting.
- Trap
- Assuming Pods always appear with their own IP.
-
DNS-based control plane endpoint
IAM-protected FQDN for reaching the GKE API server.
- Remember
- No authorized network list needed.
- Tested as
- Secure kubectl access.
- Trap
- Opening a public endpoint to all IPs.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Route types in a VPC
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Subnet routes | Created automatically for every subnet range. | Cannot be overridden by broader custom routes. | Trying to steer subnet traffic with a 0.0.0.0/0 route. |
| Static routes | Manually created with a fixed next hop. | Support tags and priority. | They do not react to link failures by themselves. |
| Dynamic routes | Learned by Cloud Router over BGP. | Scope depends on routing mode. | Regional mode limits them to one region. |
| Policy-based routes | Match on more than destination. | Evaluated before most other routes. | Next hop must be an internal passthrough load balancer. |
GKE control plane access
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Public endpoint with authorized networks | External IP limited to listed CIDRs. | Simple but exposes an address. | Leaving the list empty allows wide access. |
| Private endpoint | Internal IP reachable from the VPC and connected networks. | No external exposure. | Clients on-premises need routes to the endpoint. |
| DNS-based endpoint | FQDN that checks IAM on each request. | Works from anywhere with permission. | Confusing it with cluster-internal DNS. |
GKE cluster DNS options
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| kube-dns | Default in-cluster DNS deployment. | Runs as Pods in the cluster. | Scaling issues under heavy lookup load. |
| Cloud DNS for GKE | Managed DNS that replaces kube-dns. | No DNS Pods to manage. | Forgetting scope choice of cluster or VPC. |
| NodeLocal DNSCache | Caching agent on each node. | Cuts latency and upstream queries. | Thinking it replaces the cluster DNS provider. |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Shrink the subnet
- What candidates pick
- Reduce a subnet range to free addresses for another subnet.
- Why it looks right
- Expansion exists, so shrinking seems possible.
- Why it's wrong
- Subnet ranges can only grow; reclaiming space requires a new subnet and migration.
Clue to watch for A request to reuse part of an existing range.
-
Default route override
- What candidates pick
- Add a 0.0.0.0/0 route to inspect traffic between subnets.
- Why it looks right
- Default routes catch everything else.
- Why it's wrong
- Subnet routes are more specific and win; policy-based routes or appliance designs are needed for east-west inspection.
Clue to watch for Traffic between subnets of the same VPC must pass an appliance.
-
Peering for many VPCs
- What candidates pick
- Create a full mesh of peering connections among 20 VPCs.
- Why it looks right
- Each link is simple.
- Why it's wrong
- A mesh is hard to manage and hits quotas; Network Connectivity Center VPC spokes give transitive reach.
Clue to watch for Dozens of VPCs that all need to communicate.
-
Firewall rule for exfiltration
- What candidates pick
- Block egress to Cloud Storage IP ranges.
- Why it looks right
- Firewalls feel like the security control.
- Why it's wrong
- Google API access cannot be scoped by firewall; VPC Service Controls perimeters restrict data movement.
Clue to watch for Copying data to buckets outside the organization.
-
Mesh topology for isolation
- What candidates pick
- Put dev, test and prod spokes on one mesh hub.
- Why it looks right
- Mesh is the default.
- Why it's wrong
- Mesh lets all spokes talk; a star topology keeps edge spokes isolated while reaching shared services.
Clue to watch for Environments must not reach each other.
-
Masquerade everything
- What candidates pick
- Keep default SNAT so Pods use node IPs to reach on-premises.
- Why it looks right
- It hides Pod ranges.
- Why it's wrong
- When on-premises firewalls allow Pod CIDRs, add them to nonMasqueradeCIDRs so the source IP is preserved.
Clue to watch for On-premises systems must see the original Pod address.
Answer framework
Work through implementation questions in this order to find the smallest correct change.
- Identify the resource that owns the behavior, whether network, subnet, route, peering, hub, cluster or node pool, before reading the answer options.
- Check whether the needed setting can be changed in place or only at creation, and prefer in-place changes that avoid rebuilding clusters or networks.
- For routing problems, apply prefix length, then priority, then tags, and remember that policy-based routes are evaluated before ordinary static and dynamic routes.
- For access problems in Shared VPC or GKE, list every identity involved, including service agents, and grant the narrowest role.
- Verify the result with Connectivity Tests or route listings, and confirm that peers or spokes received the expected ranges.
Practice question
Want more like this? The GCP PCNE practice test has questions for every domain.
Checklist
0 of 14
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Plan most of your hours here for lab work, because this section rewards knowing how settings behave. Build a custom mode VPC, add subnets with secondary ranges, then expand one range. Create a Shared VPC host with one service project and try to deploy a VM before and after granting Compute Network User on a single subnet.
Then focus on routing. Create competing static routes with different priorities and prefixes, add a tag-scoped route, and check results with Connectivity Tests. Peer two VPCs and watch which routes appear with and without custom route exchange. If budget allows, create a Network Connectivity Center hub with three VPC spokes and compare mesh and star behavior.
Finish with a VPC-native GKE cluster using private nodes, the DNS-based endpoint and Dataplane V2. Write a network policy, then add an additional Pod range through a new node pool. Review each lab against the Section 2 objective list.
FAQ
How much of the GCP PCNE exam is Implementing a VPC network?
Section 2, Implementing a VPC network, is weighted at about 20%. That is roughly 10 to 12 questions on a 50 to 60 item exam, as an editorial estimate.
Do I need to know gcloud commands?
You should recognize which resource and flag a setting belongs to, such as subnet secondary ranges or peering route exchange. Exact syntax memorization matters less than knowing what can be changed and where.
Why is Network Connectivity Center in both Section 2 and Section 4?
Section 2 covers VPC spokes, topologies, Private NAT and Private Service Connect propagation. Section 4 covers hybrid spokes, router appliances and site-to-site data transfer.
Can I change a GKE cluster from routes-based to VPC-native?
No. Cluster networking mode is chosen at creation, so moving requires a new cluster. VPC-native is the default and recommended mode.
What does a policy-based route do that a static route cannot?
It matches traffic on source range, destination range and protocol, not just destination, and sends it to an internal passthrough Network Load Balancer, which is useful for steering flows through inspection appliances.
What is the difference between Private Google Access and VPC Service Controls?
Private Google Access lets VMs without external IPs reach Google APIs. VPC Service Controls limits which projects and networks may access protected APIs and data, reducing exfiltration risk.
Other Networking certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 2 knowledge
See whether you can predict route selection, fix Shared VPC access and recover GKE IP space under exam conditions.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the GCP PCNE AI tutor Get any concept explained your way