Why does deciding where to put servers matter for the Google Professional Cloud Network Engineer exam? VPC Planning and Design is the foundation of every cloud network you will build. Without a solid plan, your cloud applications can become slow, insecure, or impossible to scale — costing time and money. This chapter gives you the core ideas so you can design VPCs that work for real business needs.
Jump to a section
A simple way to picture VPC Planning and Design Fundamentals
How do you design a new neighbourhood so that homes are secure, traffic flows smoothly, and the whole area can grow without knocking down buildings every few years?
When you plan a city district, you start by deciding its boundaries and purpose. An industrial zone needs wide roads for trucks, while a residential zone needs quiet streets and playgrounds. You build main highways (like a VPC's internet gateway) to connect the district to the wider world, and smaller local streets (subnets) for internal traffic. You also set rules: which vehicles can enter, where they can park, and how much noise is allowed (firewall rules and access controls). You design the district with expansion in mind — leaving empty lots for future buildings and ensuring water and electricity lines can handle extra capacity. Without this planning, you end up with traffic jams, security problems, and costly retrofits. In the same way, a Virtual Private Cloud (VPC) is your own private district inside Google Cloud, with its own IP address ranges, subnets, gateways, and security rules. By planning it right from the start, you avoid rework and keep your cloud network secure, scalable, and easy to manage.
A Virtual Private Cloud (VPC) is your own private network inside Google Cloud. Think of it as a fenced-off area in the cloud where you can run virtual machines, databases, and other services. Your VPC is logically isolated from every other customer's VPC, even though they share the same physical hardware.
To understand VPC planning, you need to know the key parts.
First is the VPC itself. It is a global resource. That means a single VPC can span multiple regions (geographic locations like us-central1 or europe-west1) without you having to create separate networks. This is different from other cloud providers where VPCs are regional. In Google Cloud, one VPC can cover the whole world.
Inside a VPC, you create subnets. A subnet is a smaller range of IP addresses within a VPC. For example, your VPC might have the IP range 10.0.0.0/16, and you carve out 10.0.1.0/24 for one subnet and 10.0.2.0/24 for another. Each subnet lives in a single region. You cannot have a subnet that spans regions. Subnets are where your actual resources, like Compute Engine virtual machines (VMs), get their IP addresses. When you create a VM, you choose which subnet it belongs to.
IP addresses are numbers that identify devices on a network. They come in two flavours: internal (private) IP addresses, which are only reachable inside your VPC, and external (public) IP addresses, which are reachable from the internet. Planning which subnets you need and what IP ranges they will use is a core part of VPC design.
Next are VPC firewall rules. These are like bouncers at a club — they decide what traffic is allowed in and out of your VPC. You can create rules to allow or deny traffic based on source IP, destination IP, port, and protocol. For example, you might allow traffic only from your office IP address to your database servers, or block all incoming traffic except to your web server's port 443 (HTTPS). Firewall rules are applied to VMs, not to subnets directly. This gives you fine-grained control.
Routes are another critical component. Routes tell network traffic where to go. Every VPC has a default route that directs traffic to the internet. You can also create custom routes to send traffic through a specific VM (a NAT gateway or a VPN gateway, for example). Without proper routes, packets can get lost or take inefficient paths.
Google Cloud also provides shared VPC. This lets you connect multiple projects (like separate teams or environments) to a single host VPC. The host project owns the network, and service projects can use its subnets. This is useful in large organisations where the network team manages the VPC centrally, and other teams just deploy their resources.
VPC Network Peering is another important concept. It allows two VPCs (even in different projects) to communicate directly using private IP addresses, without going over the public internet. This is useful when you want to connect networks from different business units or partners, and it is free in terms of data transfer costs.
Why does all this exist? Before VPCs, you had to manage physical hardware — routers, switches, cables — and that was expensive and slow. VPCs give you a virtual network that you can create, modify, and delete with a few clicks or API calls. You get the isolation of a physical network without the hardware.
For the PCNE exam, you need to understand how to plan IP address space, subnet design, firewall rules, and connectivity options. A common scenario is designing a VPC that hosts a multi-tier application: web servers in one subnet, application servers in a second, and databases in a third. Each subnet has different firewall rules. The web server subnet might be the only one with a public IP address. The database subnet only accepts traffic from the application subnet. This kind of layered design is what the exam expects you to be able to plan and justify.
Define Business Requirements
Start by understanding what the network needs to support: how many applications, what regions, security needs, and growth plans. This drives every subsequent decision.
Choose VPC Mode
Decide between auto mode and custom mode. For production, always pick custom mode so you control IP ranges and avoid conflicts with on-premises networks.
Plan IP Address Space
Select a private IP range (like 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) that does not overlap with any existing network you will connect to. Leave room for future subnets.
Create Subnets Per Region and Tier
Design subnets for each region where you will deploy resources, and separate tiers (web, app, database) into different subnets for security and manageability.
Configure Firewall Rules
Define firewall rules to allow only necessary traffic between subnets and from the internet. Use network tags to apply rules to specific VMs and remember rules are stateful.
Set Up Connectivity
Add an internet gateway for public-facing subnets, Cloud NAT for private VMs, and configure VPC Network Peering or Cloud VPN/Interconnect for hybrid connectivity.
Enable Monitoring and Logging
Turn on VPC Flow Logs to capture traffic metadata, and configure Cloud Monitoring to track network metrics. This helps with troubleshooting and security auditing.
Imagine you are the network engineer for a growing e-commerce company called ShopFast. ShopFast runs its website on Google Cloud. The current setup is a single VPC with one subnet containing everything: web servers, application servers, and the database. This worked when the company was small, but now they have thousands of customers, and the database is getting slow because web traffic is competing with internal traffic. Also, a security audit just flagged that the database should not be accessible from the internet — but right now it is.
Your job is to redesign the VPC.
Step by step, here is what you do.
First, you create a new VPC with a planned IP range. You choose 10.0.0.0/16. This gives you 65,536 possible IP addresses, which is plenty for future growth.
Next, you create three subnets within that VPC. - A public subnet for web servers: 10.0.1.0/24 (256 addresses, in us-central1) - A private subnet for application servers: 10.0.2.0/24 (in us-central1) - A private subnet for databases: 10.0.3.0/24 (in us-central1)
You configure firewall rules. - For the web subnet, you allow incoming traffic on port 80 (HTTP) and port 443 (HTTPS) from any source (0.0.0.0/0). You allow outgoing traffic to anywhere. - For the application subnet, you allow incoming traffic only from the web subnet (source 10.0.1.0/24) on port 8080 (the port your application listens on). You allow outgoing traffic to the database subnet on port 3306 (MySQL). - For the database subnet, you allow incoming traffic only from the application subnet (source 10.0.2.0/24) on port 3306. All other incoming traffic is denied.
Notice that none of the subnets except the web subnet have external IP addresses on their VMs. For the application and database VMs to reach the internet (for software updates, for example), you set up a Cloud NAT (Network Address Translation) gateway. This lets them make outbound connections to the internet without exposing them to incoming internet traffic.
You also set up VPC Network Peering to connect ShopFast's VPC with the VPC of their payment provider, PayPro. This allows the application servers to securely send payment data to PayPro over private IP, not over the public internet.
Finally, you configure monitoring using VPC Flow Logs. These logs record network traffic metadata, which helps you troubleshoot latency and security issues. You send the logs to Cloud Logging for analysis.
The result is a secure, organised network. The database is no longer exposed. Traffic flows predictably. And when ShopFast expands to a second region (say, europe-west1), you just add new subnets in that region to the same VPC, and the global VPC handles routing automatically. This is exactly the kind of design the PCNE exam expects you to be able to plan.
The PCNE exam tests VPC Planning and Design in several specific ways. Here is what you need to focus on.
First, know the difference between auto mode and custom mode VPCs. Auto mode VPCs are created with a default subnet in each region, using a predefined IP range. Custom mode VPCs let you define your own subnets and ranges. The exam loves to ask: which mode should you choose for a production environment? The answer is always custom mode, because you have full control and can avoid IP address conflicts when you later connect to on-premises networks via VPN or Cloud Interconnect. The trap is that auto mode seems easier, but it creates unpredictable IP ranges that can cause problems.
Second, understand subnet design. The exam tests whether you can plan IP ranges that do not overlap. For example, if you need to connect your VPC to an on-premises network that uses 10.0.0.0/8, you must choose a different range, like 172.16.0.0/12. The exam will give you a scenario with an on-premises CIDR block and ask you to select the correct VPC IP range. Remember that the ranges must not overlap, and you want to leave room for future growth.
Third, know firewall rules inside out. Firewall rules are stateful in Google Cloud. That means if you allow incoming traffic, the corresponding outgoing reply traffic is automatically allowed, and vice versa. The exam tests this by giving you a scenario where a rule seems to block traffic, but because of statefulness, it actually does not. Another common question: what is the default rule configuration? There are two implied rules: allow outgoing traffic and deny incoming traffic. You can override these with your own rules.
Fourth, understand shared VPC. The exam will ask when to use shared VPC versus VPC Network Peering. Shared VPC is for when you want a central network team to manage the VPC, and other teams (service projects) just use subnets. VPC Peering is for connecting two independently managed VPCs. The trap is to use peering when you need centralised control.
Fifth, know about VPC Flow Logs. The exam tests why you would enable them: for network monitoring, forensics, and optimisation. They are not for real-time packet inspection — they sample traffic metadata. You pay extra for them.
Types of questions to expect. - Scenario-based multiple choice: You are given a business requirement and must choose the correct VPC design. For example, 'A company needs to run a multi-tier application with strict isolation between tiers. Which subnet design and firewall rules achieve this?' - True/false or select-all-that-apply: 'Which of the following are valid considerations when planning a VPC?' The answer set includes non-overlapping IP ranges, choosing custom mode, and planning for growth. - Drag-and-drop: Matching components (subnet, route, firewall rule) to their descriptions.
Key definitions to memorise. - VPC: private virtual network within Google Cloud - Subnet: regional IP address range within a VPC - Firewall rule: stateful rule controlling traffic to/from VMs - Route: rule that defines the path for outbound traffic - Shared VPC: multiple projects using a common VPC - VPC Network Peering: direct private connection between two VPCs - Cloud NAT: outbound internet access without public IPs - VPC Flow Logs: sampled metadata records of network traffic
Common trap patterns. - Confusing subnets as global (they are regional). - Thinking firewall rules are applied to subnets (they are applied to VMs, using tags or service accounts). - Assuming that by default all traffic is denied (only incoming traffic is denied; outgoing is allowed). - Forgetting that VPCs are global in Google Cloud (unlike AWS where VPCs are regional). - Overlapping IP ranges when connecting VPCs or on-premises networks.
A VPC in Google Cloud is a global resource, but subnets within it are always regional.
Custom mode VPCs give you full control over IP ranges and are the right choice for production environments.
Firewall rules in Google Cloud are stateful and applied to VMs via tags or service accounts, not to subnets.
IP address ranges for VPC subnets must not overlap with connected on-premises networks to avoid routing conflicts.
Shared VPC is used for centralised network management across multiple projects; VPC Network Peering connects separate VPCs.
Cloud NAT provides outbound internet access for VMs without public IPs, keeping them secure from inbound threats.
VPC Flow Logs capture network traffic metadata for monitoring and troubleshooting, but they are not real-time or packet-level.
Plan for growth by choosing IP ranges with enough capacity for future subnets and regions.
These come up on the exam all the time. Here's how to tell them apart.
Auto Mode VPC
Creates subnet in every region automatically
Uses predefined IP ranges (10.128.0.0/9)
Good for quick testing but not production
Custom Mode VPC
You create subnets manually
You choose your own IP ranges
Recommended for production due to full control
Firewall Rule (Allow)
Permits matching traffic
Lower priority than deny rules by default
Most common for opening specific ports
Firewall Rule (Deny)
Blocks matching traffic
Higher priority than allow by default
Used to explicitly block malicious sources
Shared VPC
Central network management in a host project
Service projects use subnets from host
Requires IAM permissions to manage
VPC Network Peering
Connects two independently managed VPCs
No central management; each side controls its own
Good for joining networks across organisations
Regional Subnet
Lives in one specific region
Defined by a CIDR range
Contains VMs and other resources
Global VPC
Spans all regions
Contains multiple subnets
Provides routing between subnets globally
Cloud NAT
Provides outbound internet access only
No public IP on the VM
Automatically translates private IPs
External IP Address
Gives VM a public IP
Allows inbound and outbound internet access
Less secure because VM is directly reachable
Mistake
A VPC is a physical network with dedicated hardware.
Correct
A VPC is a logically isolated software-defined network running on shared Google Cloud infrastructure.
The term 'virtual' is often overlooked, and beginners assume 'private' means physically separate.
Mistake
Subnets can span multiple regions.
Correct
Each subnet exists in exactly one region. A VPC is global, but subnets are regional.
People confuse the global nature of the VPC with the regional nature of subnets.
Mistake
Firewall rules are applied to subnets.
Correct
Firewall rules are applied to individual VMs using network tags or service accounts.
In many other networking contexts, firewalls are placed at the network boundary, so beginners assume the same for VPCs.
Mistake
You must create a separate VPC for each region.
Correct
A single VPC can span all regions. You create subnets in each region within the same VPC.
This misconception comes from AWS, where VPCs are regional. Google Cloud works differently.
Mistake
Auto mode VPCs are better because they automatically set up subnets and routes.
Correct
Auto mode is convenient for testing but risky for production because it uses unpredictable IP ranges that can conflict with on-premises networks.
Beginners see automation as always beneficial and do not consider compatibility with existing infrastructure.
Mistake
VPC Network Peering and Shared VPC are interchangeable.
Correct
Shared VPC centralises network management in a host project, while Peering connects two independently managed VPCs.
Both allow communication between VPCs, so the distinction seems subtle. But the management model is fundamentally different.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, a VPC in Google Cloud is a global resource. It can contain subnets in many regions. Each subnet, however, lives in exactly one region.
Auto mode creates a subnet in every region with a predefined IP range, while custom mode lets you define your own subnets and ranges. Custom mode is recommended for production.
Assign it an external IP address and create a firewall rule that allows incoming traffic on the necessary port (e.g., port 443 for HTTPS) from the source 0.0.0.0/0.
Cloud NAT lets private VMs (without external IPs) make outbound connections to the internet, for example to download updates, without exposing them to incoming traffic.
Firewall rules are applied to VMs using network tags or service accounts. They are not applied directly to subnets, even though it may seem that way.
Yes, using Cloud VPN (site-to-site VPN) or Cloud Interconnect (dedicated physical connection) to extend your network into the VPC.
You've finished VPC Planning and Design Fundamentals. Continue through the PCNE study guide to build a complete picture of the exam.
Done with this chapter?