Subnets are one of the foundational pieces of GCP networking, and the Associate Cloud Engineer exam tests them in a few distinct patterns. This article covers what a subnet is, the regional-vs-global scope of subnets versus VPCs, primary and secondary IP ranges, and the GKE pattern where secondary ranges come up most.
It does not cover every networking corner case, deep IP routing details, or BGP. The goal is the practical version of subnets that shows up on the ACE exam.
This is the most important distinction and the one that catches people. In GCP, a VPC is a global resource. One VPC can span every region Google has. Subnets are regional. Each subnet exists in exactly one region.
So a typical setup looks like one VPC for your project, with one or more subnets per region you operate in. A VPC with subnets in us-central1 and europe-west1 lets you have VMs in both regions on the same logical network, without needing VPC peering or any other cross-region setup.
This is the opposite of how AWS does it (where VPCs are regional). If you have AWS muscle memory, the GCP model takes a moment to get used to.
A subnet has a name, a region, and an IP range in CIDR notation. That is the basic structure. The IP range has to fit inside the VPC's overall range and cannot overlap with other subnets in the same VPC.
VMs in a subnet get private IPs from that subnet's range. By default, they can talk to VMs in other subnets in the same VPC over private IPs, even across regions. That is the global-VPC story in action.
This is where the exam tests something specific. Every subnet has a primary IP range. That is the range VMs get their IPs from. Most subnets only have a primary range, and that is fine.
A subnet can also have one or more secondary IP ranges. These are additional CIDR blocks attached to the same subnet, used by specific GCP services that need their own IP space.
The big use case for secondary ranges is GKE. A GKE cluster needs IPs for three things. The nodes (which use the primary range), the pods (which use a secondary range), and the services (which use another secondary range). When you create a GKE cluster on a subnet, you tell it which secondary ranges to use for pods and services.
This is why GKE clusters often need surprisingly large IP allocations. Pods get their own IPs from a secondary range, and a single node can run many pods. A GKE cluster with 100 nodes might need thousands of pod IPs, which is why the secondary range for pods is often a /20 or larger.
Two rules to remember. First, the subnet's IP range must be within the VPC's overall range. If the VPC is 10.0.0.0/16, the subnet has to be a sub-range like 10.0.1.0/24 or 10.0.2.0/24.
Second, subnet IP ranges cannot overlap with each other inside the same VPC. Two subnets cannot both claim 10.0.1.0/24. That would create routing ambiguity.
If you outgrow a subnet, you can expand its IP range without deleting and recreating it. You cannot shrink a subnet, only grow it.
One thing worth knowing. A VPC can be created in auto mode, which automatically creates one subnet per region with predefined IP ranges. Or in custom mode, which creates an empty VPC with no subnets and lets you define them yourself.
Auto mode is fine for testing and quick setups. Custom mode is what you want for any real production environment, because it gives you full control over IP ranges and avoids surprises.
gcloud compute networks subnets create my-subnet \
--network=my-vpc \
--region=us-central1 \
--range=10.0.1.0/24 \
--secondary-range=pods=10.4.0.0/14,services=10.8.0.0/20The secondary-range flag is where you define the additional ranges for GKE pods and services if this subnet will host a GKE cluster.
The Associate Cloud Engineer exam tests subnets in a few patterns.
First, the regional scope. A question describes a VM that needs to communicate with another VM in a different region. The answer is to put both subnets in the same VPC (since the VPC is global) and they can communicate by private IP without any peering. The wrong answer is usually setting up VPC peering, which is for connecting two separate VPCs, not subnets within one VPC.
Second, secondary ranges for GKE. A question describes setting up a GKE cluster and asks how to configure the network. The answer involves creating a subnet with primary range for nodes and secondary ranges for pods and services.
Third, sizing. A question gives you an expected workload and asks for the right subnet CIDR. The answer is the smallest prefix length (largest range) that fits the workload with headroom.
If you see "different regions, same VPC" in a question, think one global VPC with two regional subnets. If you see "GKE cluster" plus "subnet configuration", think primary range plus secondary ranges. If you see "two separate VPCs need to talk", that is VPC peering, not a subnet question.
VPCs in Google Cloud are global, subnets are regional. Subnets have a primary IP range that VMs use, plus optional secondary ranges that services like GKE use for their own IP allocations (pods and services). The Associate Cloud Engineer exam tests the regional-vs-global scope, the GKE secondary range pattern, and the rules around subnet IP ranges fitting inside the VPC and not overlapping each other.
My Associate Cloud Engineer course covers VPC subnets in the networking section alongside Shared VPC, VPC peering, firewall rules, and the patterns the exam tests for cross-region and GKE networking.
