CIDR notation looks intimidating the first time you see it, but the math behind it is short enough to do in your head once you have practiced it a few times. The Professional Data Engineer exam expects you to read a CIDR block, know roughly how many IP addresses it represents, and reason about whether a subnet is big enough for the workload a question describes. That workload is usually a Dataproc cluster or a Dataflow job, both of which consume IPs out of a subnet as they scale workers. If you cannot size the subnet correctly, the job will fail to launch or fail to autoscale, and that is exactly the kind of trap the exam likes to set.
This article walks through what CIDR notation means, how to compute the size of a block quickly, and how I think about subnet sizing for data jobs when I am studying for the Professional Data Engineer exam.
A CIDR block is written as X.X.X.X/Y. The four numbers before the slash are the starting IP address of the range. The number after the slash, called the prefix length, tells you how many bits of that 32 bit IPv4 address are locked in as the network portion. The remaining bits are free to vary, and every combination of those free bits is a possible address in the block.
The formula is short. To find the number of IP addresses in a CIDR block:
So a /24 block has 32 minus 24 equals 8 free bits, and 2 to the 8th is 256 possible addresses. A /16 has 16 free bits, which is 2 to the 16th or 65,536 addresses. A /8 has 24 free bits, which is 2 to the 24th or 16,777,216 addresses. The smaller the number after the slash, the bigger the block. That feels backwards at first, and it is the single most common point of confusion when reading these blocks on the exam.
When I see 10.0.0.0/24, I read it as: the network starts at 10.0.0.0, the first three octets are fixed at 10.0.0, and the last octet can be anything from 0 to 255. That is 256 possible addresses, though in Google Cloud a handful of those are reserved for the network address, the default gateway, the second-to-last address, and the broadcast address, so the usable count for workloads is closer to 252.
A few more I keep memorized:
Both Dataproc and Dataflow run on Compute Engine worker VMs, and every worker VM needs an internal IP address from the subnet the cluster or job is launched into. That sounds obvious, but it has real consequences. If you launch a Dataflow job with autoscaling enabled and a maximum of 1,000 workers into a /24 subnet that already has other resources in it, the job will hit the IP ceiling and fail to scale up. The same is true for Dataproc autoscaling policies and for Dataproc Serverless batch workloads, which also pull IPs from the subnet they run in.
The Professional Data Engineer exam will not always say CIDR outright. It will give you a scenario where a Dataflow pipeline cannot scale, or a Dataproc cluster fails to create, and the answer hinges on subnet size. If you can convert a /24 to 256 and a /22 to 1,024 without thinking, you can rule out the answer choices that do not give the job enough room.
When I am planning a subnet for Dataproc or Dataflow, I work backwards from the maximum worker count the job will ever need, plus a buffer for other resources in the same subnet. A few rough rules I use:
One more thing worth memorizing for the exam. Google Cloud lets you expand the primary IP range of a subnet after the fact, but you cannot shrink it, and you cannot change the secondary ranges in ways that conflict with existing usage. That makes the initial sizing decision matter more than it would in a system where you can resize freely.
Practice the conversion until it is automatic. Write down a /28, /24, /22, /20, /16, and /8, and rattle off the address counts without thinking. Then practice reading a CIDR block aloud as a range, like 10.0.0.0/22 covers 10.0.0.0 through 10.0.3.255. Once that math is fast, every networking question on the Professional Data Engineer exam becomes a question about whether the subnet is big enough for the workers the scenario needs.
My Professional Data Engineer course covers CIDR notation alongside the VPC, subnet, and networking patterns that show up in Dataproc, Dataflow, and BigQuery scenarios on the exam, so you can read these blocks at a glance and pick the right subnet size in any question that touches IP planning.
