VPCs and private IP addresses are foundational to almost everything else in Google Cloud networking. Before you can reason about firewalls, routes, peering, hybrid connectivity, or load balancing, you need a clear picture of what a VPC actually is and how the IP address space inside it works. I am going to walk through the model from the ground up, because the Professional Cloud Architect exam expects you to read a network diagram and immediately understand what is happening.
A Virtual Private Cloud is a logically isolated virtual network inside Google Cloud. The simplest way to think about it is as a software version of a physical network. A physical network uses tangible hardware to move data around: routers, switches, servers, and cables. A virtual network takes those same components and abstracts them into software. Instead of a physical firewall appliance, you have firewall rules. Instead of a hardware switch, you have software-defined segmentation.
A VPC is your own carved-out slice of Google's infrastructure. It behaves like a physical network, but every component is virtualized, which is what gives you the flexibility to define and redefine your topology without ever touching hardware.
VPCs live inside projects. At the top is Google Cloud itself. Inside Google Cloud, you organize resources into projects. Inside a project, you can create one or more VPCs. Each VPC is its own isolated network.
The next layer down is the subnet. A VPC can span multiple regions, and inside each region you carve out subnets. A single VPC might have two subnets in us-central1 and another subnet in us-east1. Subnets are how you segment the network and control where workloads actually live. This matters for the Professional Cloud Architect exam because subnets are regional resources, not global, and that regionality drives a lot of design decisions later.
Every device on a network needs a unique numerical identifier so it can send and receive data. That is what an IP address is. There are two main versions, IPv4 and IPv6. IPv4 looks like 192.168.1.1. IPv6 is much longer and looks like 2001:0db8:85a3:0000:0000:8a2e:0370:7334. IPv4 is still the format you will see most often, and it is what the exam focuses on.
Inside a VPC, your resources use private IP addresses. Private IP addresses are specific ranges reserved for use inside private networks, whether that is a home network, an office network, or your VPC. The whole point of a VPC and its subnets is to establish a private IP space where your resources can communicate with each other directly, without going out to the public internet.
The basic flow is straightforward. Public traffic comes in over the internet and hits a router with a public IP address. The router then forwards that traffic to devices on the local network, each of which has a private IP. The outside world talks to the public IP, and the private IPs talk to each other internally.
There are three IPv4 ranges reserved for private networks, and you should be able to recognize all three on sight.
10.0.0.0/8 is the largest. It contains roughly 16.8 million IP addresses and is typically used in large private networks and corporate environments where you need to accommodate a huge number of devices.
172.16.0.0/12 is the middle range, with around one million addresses. It fits medium-sized networks, the kind you see at small to medium enterprises.
192.168.0.0/16 is the smallest of the three, with about 65,000 addresses. This is the range you have almost certainly seen before. It is the default for most home routers and small office networks.
On the exam, when you see one of these ranges in a question, you should immediately recognize it as a private range and start thinking about subnet sizing within it.
Subnets are defined at the region level. When you create one, you specify its IP range using CIDR notation. There are two rules that govern what is allowed.
First, a subnet's IP range must fall inside the VPC's overall range. If your VPC is 10.0.0.0/16, every subnet you create inside it has to use a range that fits within 10.0.0.0/16. That might be 10.0.1.0/24 or 10.0.2.0/24, but it cannot wander outside the parent range.
Second, subnet ranges cannot overlap with each other inside the same VPC. Overlap creates IP address conflicts and breaks routing, so Google Cloud simply will not let you do it.
A useful operational detail: if you run out of IP addresses in a subnet, you do not have to delete and recreate it. You can expand the subnet's IP range in place. That is worth remembering for the Professional Cloud Architect exam, because questions sometimes ask how to handle a subnet that is running out of room, and the answer is almost never to tear it down.
One last thing to remember: 0.0.0.0/0 is not valid as a subnet range. That CIDR represents the default route, meaning all possible IP addresses, and it has a specific meaning in routing tables. It cannot be used to define a private subnet.
Almost every networking question on the Professional Cloud Architect exam assumes you already know this material. When a scenario tells you that a workload in us-central1 needs to talk to a workload in us-east1, you should immediately be thinking about whether they are in the same VPC, what subnets they live in, and whether the IP ranges are compatible. When a question gives you a VPC of 10.0.0.0/16 and asks you to add a subnet, you should know that 10.0.5.0/24 fits and 11.0.0.0/24 does not. This baseline is what lets you focus on the harder parts of the question instead of getting tripped up on the setup.
My Professional Cloud Architect course covers VPCs and private IP addresses alongside the rest of the networking material.
