Overview
Section 1 is about design decisions made on paper. You choose between a standalone VPC and Shared VPC, decide how many networks an organization needs and how they connect (VPC Network Peering, Network Connectivity Center or Private Service Connect), and lay out subnets, IPv6, bring your own IP and privately used public IP ranges. Load balancer selection, network tiers, quotas and IAM roles such as Compute Network User also sit here.
The hybrid and multicloud part asks you to pick Dedicated or Partner Interconnect, Cross-Cloud Interconnect, HA VPN or SD-WAN, to plan regional or global dynamic routing for failover, and to give on-premises hosts private reach to Google APIs and managed services. GKE design closes the section: private nodes and control plane endpoints, Pod and Service ranges, IPv6 and Gateway-based load balancing. The exam guide is current and no retirement has been announced.
How it's tested
Design questions describe an organization, its constraints and growth plans, then ask which architecture fits. Constraints such as overlapping on-premises ranges, a central network team, a 99.99% availability target or a ban on public IPs usually decide the answer. Read every adjective in the stem before comparing options.
-
Pick the VPC model
You choose standalone VPC, Shared VPC, peering or Network Connectivity Center based on team ownership, scale and transitivity needs.
-
Size the address plan
You calculate subnet, Pod and Service ranges and choose RFC 1918, non-RFC 1918 or privately used public space when addresses run short.
-
Select the hybrid path
You match bandwidth, encryption, SLA and multicloud requirements to Interconnect, Cross-Cloud Interconnect, HA VPN or a peering option.
A company with twelve application teams wants one networking group to own firewalls, routes and hybrid links while teams keep their own billing and VMs. Shared VPC fits: the host project holds the network, service projects attach to it, and teams receive Compute Network User on specific subnets. Peering twelve separate VPCs would scatter control and hit peering limits.
Objectives 4
Official objectives from the Google Cloud outline, in outline order.
1.1 Designing an overall network architectureTiers, availability, DNS topology, load balancer choice, GKE planning, IAM, managed service access and quotas.
- What it means
- This objective covers the top-level shape of a Google Cloud network: Premium or Standard Tier, availability and disaster recovery, where DNS is authoritative, which load balancer serves an application, how GKE fits, which IAM roles each team needs, how workloads reach managed services and which quotas could block growth.
- What to understand
- Premium Tier carries traffic on Google's backbone and is required for global external load balancing, while Standard Tier hands traffic to the internet closer to the source and works only with regional load balancers. Application Load Balancers proxy HTTP(S), while Network Load Balancers handle TCP, UDP and other protocols in proxy or passthrough form. Managed services are reached through private services access (VPC peering), Private Service Connect endpoints, or Serverless VPC Access and Direct VPC egress for Cloud Run. Check quotas such as peerings per network and routes per network during design.
- How it shows up
- Expect a list of business requirements where you pick the tier, load balancer family or service access method that satisfies all of them.
- Common confusion
- Standard Tier is cheaper, but it cannot front a global external Application Load Balancer.
1.2 Designing VPC networksVPC type and count, interconnection method, IP management, global or regional scope, MTU and appliance insertion.
- What it means
- This objective covers how many VPC networks to build and of what type, how they connect, how address space is allocated, whether resources are global or regional, which MTU to use, and how third-party virtual appliances are inserted with custom routes.
- What to understand
- A VPC network is global and its subnets are regional, so one VPC can span every region without peering. VPC Network Peering is not transitive and refuses overlapping subnet ranges. Network Connectivity Center VPC spokes give transitive connectivity among many VPCs, and Private Service Connect exposes a single service without merging address spaces. Plan IPv6, bring your own IP and privately used public IP (PUPI) ranges early. The default VPC MTU is 1460 bytes, and jumbo frames up to 8896 bytes help high-throughput workloads when every hop supports them.
- How it shows up
- Look for growth numbers, overlap warnings and appliance requirements that rule out simple peering.
- Common confusion
- Peering three VPCs in a chain does not let the first reach the third.
1.3 Designing a resilient and performant hybrid and multi-cloud networkInterconnect, VPN, peering options, multi-region HA, multi-VPC access, private API access, IP overlap, DNS, MTU and encryption.
- What it means
- This objective covers how on-premises sites and other clouds connect to Google Cloud with the right bandwidth, resilience and security, including routing mode, private access to Google APIs, managed services reached from on-premises, non-overlapping IP space, hybrid DNS, link MTU and link encryption.
- What to understand
- Dedicated Interconnect gives physical 10 or 100 Gbps circuits; Partner Interconnect uses a provider when you cannot reach a colocation facility; Cross-Cloud Interconnect links directly to another cloud provider. HA VPN suits lower bandwidth and encryption over the internet. Direct Peering and Verified Peering Providers reach Google public services such as Google Workspace, not VPC resources. Global dynamic routing lets one region's Cloud Router serve all regions for failover. On-premises hosts reach Google APIs privately through Private Service Connect endpoints or the private and restricted VIP ranges. MACsec or HA VPN over Cloud Interconnect adds encryption to Interconnect links.
- How it shows up
- Scenarios combine bandwidth, encryption, SLA and overlap clues; one detail usually eliminates three options.
- Common confusion
- Direct Peering does not give private access to VPC resources; Interconnect does.
1.4 Designing for Google Kubernetes Engine (GKE)Private nodes and endpoints, subnet ranges, IP sources, IPv6, load balancing and node pools.
- What it means
- This objective covers GKE network design: whether nodes and control plane endpoints are public or private, how primary and secondary ranges are sized, which address space Pods use, IPv6 support, how traffic enters the cluster and how node pools are configured.
- What to understand
- VPC-native clusters take node IPs from the subnet primary range and Pod and Service IPs from secondary ranges. By default GKE reserves a /24 of Pod addresses per node for up to 110 Pods, so lowering maximum Pods per node saves space. Non-RFC 1918 or PUPI ranges can supply Pod addresses when private space is exhausted. Private nodes have only internal IPs and reach the internet through Cloud NAT. The GKE Gateway controller and Ingress controller provision Google Cloud load balancers, using NEGs for container-native load balancing.
- How it shows up
- You will size Pod ranges from node counts or choose address sources when RFC 1918 space is tight.
- Common confusion
- Pod range size depends on maximum Pods per node, not on the number of Pods actually running.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Shared VPC
A host project owns the network; service projects use its subnets.
- Remember
- Grant Compute Network User per subnet for least privilege.
- Tested as
- Central network team scenarios.
- Trap
- Using peering when central control is the goal.
-
VPC Network Peering
Private connectivity between two VPC networks.
- Remember
- Non-transitive and no overlapping subnets.
- Tested as
- Multi-VPC designs.
- Trap
- Expecting transit through a middle VPC.
-
Network Connectivity Center
Hub-and-spoke service for VPC and hybrid connectivity.
- Remember
- VPC spokes provide transitive reach among many VPCs.
- Tested as
- Large multi-VPC designs.
- Trap
- Assuming it needs peering underneath.
-
Private Service Connect
Consumer endpoint that reaches a published service or Google APIs.
- Remember
- Works with overlapping IP ranges.
- Tested as
- Service exposure across organizations.
- Trap
- Confusing it with private services access.
-
Private services access
Peering connection to a Google-managed producer network.
- Remember
- Requires an allocated IP range.
- Tested as
- Cloud SQL and Memorystore private IP.
- Trap
- Forgetting custom route export for on-premises reach.
-
Network Service Tiers
Premium uses Google's backbone; Standard exits to the internet early.
- Remember
- Global load balancing needs Premium.
- Tested as
- Cost versus performance design.
- Trap
- Choosing Standard for a global anycast IP.
-
Dynamic routing mode
Regional or global scope for routes learned by Cloud Router.
- Remember
- Global mode enables cross-region failover.
- Tested as
- Multi-region hybrid designs.
- Trap
- Leaving regional mode in a failover design.
-
MTU
Largest packet size on the network path.
- Remember
- VPC default 1460; jumbo frames up to 8896.
- Tested as
- Performance and hybrid link design.
- Trap
- Mismatched MTU causing fragmentation or drops.
-
PUPI and non-RFC 1918
Extra address space for private use.
- Remember
- Helps when RFC 1918 space is exhausted.
- Tested as
- GKE Pod range planning.
- Trap
- Assuming PUPI ranges are reachable from the internet.
-
Cross-Cloud Interconnect
Dedicated physical link from Google Cloud to another cloud provider.
- Remember
- 10 or 100 Gbps ports with Google managing the cross-connect.
- Tested as
- Multicloud design.
- Trap
- Using HA VPN for very high bandwidth needs.
-
MACsec for Cloud Interconnect
Layer 2 encryption between your router and Google's edge.
- Remember
- Protects the physical link.
- Tested as
- Encryption requirement on Interconnect.
- Trap
- Thinking Interconnect is encrypted by default.
-
Maximum Pods per node
GKE setting that controls the Pod CIDR block given to each node.
- Remember
- 110 Pods uses a /24 per node.
- Tested as
- IP exhaustion questions.
- Trap
- Sizing by running Pods instead of the setting.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Ways to connect VPC networks
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| VPC Network Peering | Direct private link between two VPCs. | Simple and fast but non-transitive. | Full mesh becomes unmanageable at scale. |
| Network Connectivity Center VPC spokes | VPCs attach to a central hub. | Transitive connectivity among spokes. | Overlapping ranges still need filters or Private NAT. |
| Shared VPC | One network shared by many projects. | Single network, central administration. | It does not connect separate VPCs together. |
| Private Service Connect | Endpoint to one published service. | Exposes a service, not a whole network. | Expecting it to route between full subnets. |
Hybrid and multicloud connection options
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Dedicated Interconnect | Physical circuits in a colocation facility. | Highest bandwidth, private addressing. | Requires presence in a supported facility. |
| Partner Interconnect | Connectivity through a service provider. | Flexible capacity without colocation. | Layer 2 partners still need you to run BGP. |
| HA VPN | IPsec tunnels over the internet. | Encrypted, quick to deploy, lower throughput per tunnel. | Assuming it matches Interconnect bandwidth. |
| Direct Peering or Verified Peering Provider | Peering with Google's edge for public services. | Reaches Google Workspace and public APIs. | It does not reach VPC internal addresses. |
Private access to Google APIs
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Private Google Access | Subnet setting for VMs without external IPs. | Applies to VMs inside the VPC. | It does not cover on-premises hosts by itself. |
| private.googleapis.com and restricted.googleapis.com | Special VIP ranges reached over hybrid links. | Restricted works with VPC Service Controls. | Needs DNS changes and advertised routes. |
| Private Service Connect for Google APIs | Internal endpoint IP you choose. | Address sits inside your own range. | Picking an address that overlaps on-premises. |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Peering for central control
- What candidates pick
- Peer each team's VPC with a central VPC.
- Why it looks right
- Peering is familiar and quick to set up.
- Why it's wrong
- Teams would still own their own firewalls and routes; Shared VPC gives one team control of a single network.
Clue to watch for A central networking team must administer everything.
-
Standard Tier for global users
- What candidates pick
- Save money with Standard Tier on a worldwide web app.
- Why it looks right
- Standard Tier lowers egress cost.
- Why it's wrong
- Global external Application Load Balancers and their single anycast IP need Premium Tier.
Clue to watch for Users on several continents behind one IP address.
-
Single Interconnect for 99.99%
- What candidates pick
- Order one Dedicated Interconnect connection with two VLAN attachments.
- Why it looks right
- Two attachments look redundant.
- Why it's wrong
- A 99.99% design needs four connections across two metros and two regions with global routing.
Clue to watch for The stem quotes the 99.99% SLA.
-
Reuse RFC 1918 for Pods
- What candidates pick
- Carve more 10.0.0.0/8 space for a new cluster.
- Why it looks right
- It is the usual private range.
- Why it's wrong
- If 10.0.0.0/8 is already used on-premises, overlaps break hybrid routing; non-RFC 1918 or PUPI ranges avoid conflict.
Clue to watch for Corporate address space is exhausted.
-
Jumbo frames everywhere
- What candidates pick
- Set 8896 MTU on every network including VPN paths.
- Why it looks right
- Bigger packets sound faster.
- Why it's wrong
- VPN encapsulation and some peers cannot carry jumbo frames, causing fragmentation or drops.
Clue to watch for Traffic crosses Cloud VPN or the internet.
-
Private services access for third-party SaaS
- What candidates pick
- Peer with a partner's producer VPC.
- Why it looks right
- Peering already works for Cloud SQL.
- Why it's wrong
- Private Service Connect publishes a service without exposing or merging networks and tolerates overlap.
Clue to watch for A producer in another organization with overlapping ranges.
Answer framework
Use these steps when a scenario asks you to design or plan a Google Cloud network.
- List the hard constraints first: ownership model, availability target, encryption, regulatory limits and any address ranges already used on-premises.
- Choose the VPC model, standalone or Shared VPC, and how many networks, then pick peering, Network Connectivity Center or Private Service Connect for links between them.
- Draw the IP plan for subnets, GKE Pod and Service ranges and hybrid sites, checking for overlap and leaving room for growth.
- Select hybrid and multicloud connectivity by bandwidth, SLA and encryption, then set the dynamic routing mode that supports failover.
- Finish with service access paths, DNS topology, MTU and quotas, and confirm each choice still meets the original constraints.
Practice question
Want more like this? The GCP PCNE practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Give this section the most study time, since it carries about 21% of the exam and supports later sections. Start with a design notebook: one page each for VPC models, interconnection methods, hybrid options and GKE addressing. For every option write the requirement that makes it the right choice and the requirement that rules it out. Add the key numbers, such as 1460 default MTU, 8896 maximum, a /24 per node at 110 Pods, and the four-connection layout for 99.99% Interconnect.
Next, practice on paper. Take an imaginary company with three business units, a data center using 10.0.0.0/8 and a plan for GKE, then draw the projects, VPCs, subnets, secondary ranges and hybrid links. Check your plan for overlap and transitivity problems. In a lab, build a small Shared VPC with one service project and a peered VPC to see the non-transitive behavior yourself. Finish with practice questions, and for each wrong answer note which constraint you missed in the stem.
FAQ
How much of the GCP PCNE exam is Designing and planning a Google Cloud VPC network?
Google weights Section 1 at about 21%, the largest share of the six sections. On a 50 to 60 question exam that suggests 11 or 12 questions, as an editorial estimate.
Did the exam guide change recently?
Yes. The current guide linked from Google's certification page uses six sections and moves Cloud Armor, NAT and firewall topics into a separate security section. Older study material may follow the previous five-section layout.
Do I need to memorize the 99.99% Interconnect topology?
You should know its shape: four connections, two in each of two metropolitan areas, Cloud Routers in two regions and global dynamic routing. The 99.9% design uses two connections in one metro.
When is Shared VPC a better choice than peering?
Choose Shared VPC when one team should control the network while other projects deploy resources into it. Peering fits independently managed networks that need limited connectivity.
What is PUPI?
Privately used public IP space means public ranges that you use internally and do not advertise to the internet. It adds address capacity, often for GKE Pods, when RFC 1918 space is exhausted.
How detailed are the GKE questions in this section?
They focus on design: private or public nodes and endpoints, range sizing, address sources, IPv6 and how Gateway or Ingress create load balancers. Hands-on cluster configuration is covered in Section 2.
Is there a passing score for this exam?
Google does not publish one. Results are reported as pass or fail.
Other Networking certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 1 knowledge
Check that you can choose the right VPC model, hybrid path and IP plan for a scenario before moving on to implementation.
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