CIDR notation is one of those topics that sounds intimidating but is genuinely simple once you see it. The Associate Cloud Engineer exam tests it in the context of sizing GCP subnets. This article covers what CIDR notation means, how to calculate the number of usable IPs in a range, the typical patterns you see in GCP, and the question patterns to watch for on the ACE exam.
It does not cover IPv6 CIDR or every theoretical edge case in subnet math. The goal is the version of CIDR that shows up in GCP work and on the exam.
CIDR notation looks like this. 10.0.0.0/24. It is two parts. An IP address before the slash, and a number after the slash. The number after the slash is called the prefix length and it tells you how many IP addresses are in the range.
That is the whole concept. The IP before the slash is the starting address of the range. The prefix length determines how big the range is.
An IPv4 address has 32 bits. The prefix length tells you how many of those bits are fixed (the network part), and how many are variable (the host part, where individual IPs can vary).
To count the number of IPs in a range, take the prefix length, subtract it from 32, and raise 2 to that power. Examples.
10.0.0.0/24. 32 minus 24 equals 8. 2 to the 8 equals 256. So /24 gives you 256 IP addresses.
10.0.0.0/16. 32 minus 16 equals 16. 2 to the 16 equals 65,536 IP addresses.
10.0.0.0/8. 32 minus 8 equals 24. 2 to the 24 equals roughly 16.8 million IP addresses.
The smaller the number after the slash, the bigger the range. /24 is small, /8 is huge. That feels backwards at first but makes sense once you remember the prefix length is how many bits are fixed. Fewer fixed bits means more variable bits means more addresses.
This is what the practical version of CIDR knowledge looks like in GCP. You know roughly how many VMs you expect to run in a subnet, and you pick a prefix length that fits.
A /24 (256 IPs) is the most common starting point for a small to medium subnet. After GCP reserves a few addresses (network, broadcast, gateway, a couple for future use), you have around 250 usable. That is plenty for most environments.
A /20 (4,096 IPs) gives you headroom for larger workloads. A /16 (65,536 IPs) is for serious scale. A GKE cluster with secondary ranges for pods and services might want a /14 or /12 for those secondary ranges to avoid running out of pod IPs.
Two rules to remember from the GCP docs. The subnet's IP range must fit inside the VPC's overall range. If the VPC is 10.0.0.0/16, every subnet has to be a sub-range of that. And subnet IP ranges cannot overlap with each other inside the same VPC.
You will almost always pick subnet ranges from one of three reserved private IP blocks. 10.0.0.0/8 (16.8 million addresses, common for large enterprise networks). 172.16.0.0/12 (1 million addresses, common for medium-sized environments). 192.168.0.0/16 (65,536 addresses, common in home networks and small offices).
In GCP work, 10.x.x.x ranges are by far the most common because they give you the most room and the fewest conflicts with other private networks.
The Associate Cloud Engineer exam mentions this directly. 0.0.0.0/0 is not a valid subnet range. It represents "every IP address everywhere", which is the default route, not a real subnet. If you see 0.0.0.0/0 as an option for a subnet IP range on the exam, it is wrong.
0.0.0.0/0 does show up legitimately in firewall rules and routes (where it means "from any source" or "to any destination"). But not as a subnet definition.
Worth knowing. If you outgrow a subnet's IP range, you can expand it without deleting and recreating the subnet. You change the CIDR prefix to a larger range. The existing VMs keep their IPs and the subnet just has more space.
gcloud compute networks subnets expand-ip-range my-subnet \
--region=us-central1 \
--prefix-length=20Note that prefix-length here is the new (larger) prefix, like 20 instead of 24. You cannot shrink a subnet, only expand it.
The Associate Cloud Engineer exam tests CIDR in two patterns.
First, sizing. A scenario describes an expected number of VMs and asks what CIDR range to use. The answer is the smallest prefix (largest range) that fits the workload with reasonable headroom.
Second, valid versus invalid ranges. A scenario asks which CIDR is valid for a private subnet. The answer is one of the private ranges (10.x, 172.16-31.x, 192.168.x). Wrong answers include 0.0.0.0/0, public IP ranges, or ranges that overlap with another subnet.
If you see "expected number of VMs" and CIDR options in an exam question, count addresses with the 32-minus-prefix-length rule. If you see 0.0.0.0/0 as an option for a private subnet, that is the wrong answer.
CIDR notation is just an IP address followed by a prefix length. The prefix length controls how many IPs are in the range. To count: subtract the prefix from 32 and raise 2 to that power. /24 is 256 IPs, /16 is 65,536, /8 is 16.8 million. In GCP, you almost always pick a sub-range of 10.0.0.0/8 for your VPC, and your subnet ranges have to fit inside that.
My Associate Cloud Engineer course covers CIDR in the VPC section alongside subnet creation rules and the patterns the exam tests for sizing networks for expected workloads.
