Subnets within a VNet in Azure - Time & Space Complexity
When creating subnets inside a virtual network, it is important to understand how the time to set up grows as you add more subnets.
We want to know how the number of subnets affects the total time and operations needed.
Analyze the time complexity of the following operation sequence.
# Create a virtual network
az network vnet create --name MyVNet --resource-group MyResourceGroup --address-prefix 10.0.0.0/16
# Create multiple subnets inside the VNet
for i in $(seq 1 5); do
az network vnet subnet create --resource-group MyResourceGroup --vnet-name MyVNet --name Subnet$i --address-prefix 10.0.$i.0/24
done
This sequence creates one virtual network and then adds several subnets inside it, each with its own address range.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Creating each subnet inside the virtual network.
- How many times: Once for the virtual network, then once per subnet (e.g., 5 times in the example).
Each subnet creation requires a separate API call, so the total operations grow as you add more subnets.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 | 1 (VNet) + 10 (subnets) = 11 |
| 100 | 1 + 100 = 101 |
| 1000 | 1 + 1000 = 1001 |
Pattern observation: The total operations increase linearly as the number of subnets increases.
Time Complexity: O(n)
This means the time to create subnets grows directly in proportion to how many subnets you add.
[X] Wrong: "Creating multiple subnets happens all at once, so time stays the same no matter how many subnets."
[OK] Correct: Each subnet creation is a separate call and takes time, so adding more subnets adds more work.
Understanding how resource creation scales helps you design efficient cloud setups and explain your reasoning clearly in interviews.
"What if we created subnets in parallel instead of one after another? How would the time complexity change?"
Practice
Solution
Step 1: Understand the role of subnets in a VNet
Subnets split a VNet into smaller parts, each with its own IP range.Step 2: Identify the purpose of subnetting
Subnetting helps organize resources and apply security rules within the VNet.Final Answer:
To divide the VNet into smaller IP address ranges for better organization and security -> Option BQuick Check:
Subnet purpose = divide and organize IP ranges [OK]
- Thinking subnets increase total IP space
- Confusing subnets with VNet peering
- Believing subnets create VMs automatically
Solution
Step 1: Review valid CIDR notation for subnets
CIDR notation uses an IP address and a prefix length between 0 and 32 for IPv4.Step 2: Check each option for validity
10.0.0.0/16is a VNet range, not a subnet.10.0.1.0/24is a valid subnet inside 10.0.0.0/16.10.0.0.256/24has an invalid IP (256 is out of range).10.0.0.0/33has an invalid prefix length (33 is too large).Final Answer:
10.0.1.0/24 -> Option AQuick Check:
Valid subnet CIDR = 10.0.1.0/24 [OK]
- Using IP octets above 255
- Using prefix length greater than 32
- Confusing VNet and subnet CIDR sizes
192.168.0.0/16, which subnet CIDR block is valid and fits inside this VNet?Solution
Step 1: Understand the VNet address space
The VNet covers IPs from 192.168.0.0 to 192.168.255.255 (a /16 block).Step 2: Check which subnet fits inside the VNet
192.168.1.0/24(192.168.1.0/24) fits inside the VNet range.192.169.0.0/24is outside the 192.168.x.x range.192.168.0.0/15has a /15 prefix which is larger than the VNet's /16, so it extends outside.10.0.0.0/24is a different private IP range.Final Answer:
192.168.1.0/24 -> Option AQuick Check:
Subnet inside VNet range = 192.168.1.0/24 [OK]
- Choosing subnet outside VNet range
- Using larger prefix than VNet
- Confusing private IP ranges
10.1.0.0/16 inside a VNet with address space 10.0.0.0/24. What is the problem?Solution
Step 1: Compare subnet and VNet address spaces
The VNet covers 10.0.0.0 to 10.0.0.255 (/24). The subnet 10.1.0.0/16 covers 10.1.0.0 to 10.1.255.255, which is outside the VNet range.Step 2: Identify the error
The subnet CIDR must be fully inside the VNet's address space. Here, it is larger and outside the VNet.Final Answer:
The subnet CIDR is larger than the VNet address space and does not fit inside -> Option DQuick Check:
Subnet must fit inside VNet range [OK]
- Ignoring subnet size vs VNet size
- Thinking private IP ranges are invalid
- Assuming overlap without checking
172.16.0.0/16. You want to create three subnets: 172.16.0.0/18, 172.16.64.0/18, and 172.16.128.0/17. Which statement is true about these subnets?Solution
Step 1: Analyze the VNet and subnet ranges
The VNet covers 172.16.0.0 to 172.16.255.255 (/16). The first subnet covers 172.16.0.0 to 172.16.63.255 (/18). The second covers 172.16.64.0 to 172.16.127.255 (/18). The third covers 172.16.128.0 to 172.16.255.255 (/17).Step 2: Check for overlaps
The subnets cover distinct ranges: first 172.16.0.0-172.16.63.255, second 172.16.64.0-172.16.127.255, third 172.16.128.0-172.16.255.255. No overlaps, all fit within the VNet.Final Answer:
All three subnets fit inside the VNet without overlapping -> Option CQuick Check:
All three subnets fit without overlapping [OK]
- Miscalculating subnet ranges and thinking they overlap
- Confusing prefix lengths and their sizes
- Ignoring subnet boundaries
Ready to prove it?
Pass the test and this pattern moves unknown
