When people first look at AZ-700, it’s easy to think it’s a “light” networking exam.
The content itself isn’t huge, but the exam isn’t testing how many CIDR ranges you can memorise, it’s testing whether you can design Azure networks properly.
Subnet design is a perfect example of this.
In real environments, most networking issues don’t come from “wrong IP ranges”.
They come from poor subnet design decisions made early, which later break security, routing, scalability, or hybrid connectivity.
This post explains how to think about subnet design from an Azure landing zone and AZ-700 perspective, the same way Microsoft expects you to reason in the exam and in real-world architecture discussions.
Subnets Are More Than IP Containers
A common beginner mistake is treating subnets as nothing more than places to put IP addresses.
From an architect’s point of view, subnets are boundaries:
- Security boundaries
- Routing boundaries
- Operational boundaries
- Blast-radius boundaries
If two resources have different security requirements, routing behaviour, scaling needs, or lifecycle expectations, they should not share a subnet.
This single idea explains a large percentage of AZ-700 questions.
Purpose Driven Subnet Design
In a well-designed landing zone, every subnet exists for a specific purpose.
Typical examples include:
- Application workload subnets (web, app, data tiers)
- Shared services (Active Directory, DNS, jump hosts)
- Security services (Azure Firewall, NVAs)
- Platform services (Application Gateway, Bastion, VPN/ExpressRoute)
The key rule is simple:
One subnet = one responsibility
If you can’t clearly explain what a subnet is for, it’s probably doing too much.
Address Space Planning (Design for Growth)
Azure VNets must use RFC1918 private address ranges:
- 10.0.0.0/8 (most common in enterprises)
- 172.16.0.0/12
- 192.168.0.0/16
From a landing zone perspective, subnet design should always assume:
- Hybrid connectivity
- Future growth
- New platform services being added later
Best practice is to:
- Allocate large address spaces to VNets
- Carve out right-sized subnets
- Leave 25–40% unused space for growth
A VNet that is “perfectly sized” on day one is almost guaranteed to cause problems later.
Platform-Reserved Subnets (Do Not Break These). Some Azure services require dedicated subnets and cannot share space with workloads.
Examples include:
- Azure Firewall (AzureFirewallSubnet)
- VPN Gateway / ExpressRoute (GatewaySubnet)
- Azure Bastion (AzureBastionSubnet)
- Application Gateway
- AKS node pools (recommended)
These subnets exist to support the platform, not applications.
Placing workloads into platform subnets is a design flaw, and something AZ-700 will test explicitly.
Subnet Sizing and IP Consumption
Azure automatically reserves five IP addresses per subnet, which makes overly small subnets a common mistake.
General guidance:
- Application tiers: /24
- Shared services: /24
- Gateways and Bastion: /27–/26
- AKS: larger than expected (node scaling consumes IPs quickly)
Small subnets may work initially but become blockers as soon as scale or new services are introduced.
Security Boundaries and NSGs
In Azure, subnets are security zones.
Best practice is to:
- Apply Network Security Groups (NSGs) at the subnet level
- Use NIC-level NSGs only for exceptional cases
Each subnet should have:
- Explicit inbound rules
- Explicit outbound rules
- No reliance on default “allow” behaviour
In AZ-700 scenarios, when asked where to apply an NSG, the correct answer is almost always the subnet, not individual virtual machines.
Routing and Traffic Flow Design
Subnet design directly controls routing behaviour.
Each subnet should answer questions such as:
- Does traffic require inspection?
- Should outbound traffic go via Azure Firewall or directly to the internet?
- Is forced tunnelling required?
- Does east–west traffic need to be controlled?
If routing behaviour differs, the subnets should be separate.
User Defined Routes (UDRs) should be applied per subnet, not globally, to maintain clarity and control.
Hybrid Connectivity and DNS Awareness
AZ-700 assumes hybrid connectivity by default.
Subnet design must account for:
- On-prem IP overlap avoidance
- Private Endpoint traffic flows
- DNS resolution paths
Azure’s internal DNS (168.63.129.16) plays a key role in name resolution, and many hybrid issues trace back to subnet design decisions rather than DNS configuration itself.
Planning Private Endpoint subnets early avoids painful rework later.
Isolation and Blast Radius Control
Subnets are one of your main tools for limiting impact.
Good design helps:
- Prevent lateral movement
- Contain failures
- Apply least-privilege networking
Common patterns include:
- Separate VNets for production and non-production
- Isolated subnets for internet-facing workloads
- Dedicated subnets for sensitive services
This isn’t over-engineering, it’s risk management.
Naming, Governance, and Automation
Subnet naming should be:
- Predictable
- Role-based
- Environment-aware
For example:
snet-app-prod-uks-01
snet-shared-prod-uks-01
snet-fw-prod-uks-01
Good naming enables:
- Policy enforcement
- Terraform automation
- Operational clarity at scale
Subnet design should always be infrastructure-as-code first, not portal-driven.