The AZ-700 exam tests your ability to make design decisions in VNet, Subnet, and NAT Gateway scenarios. If CIDR address spaces overlap, VNet Peering becomes impossible. Miscalculating Reserved IPs shrinks your subnet faster than expected. Knowing how NAT Gateway solves SNAT port exhaustion in high-volume outbound connections is another core exam point.
VNet Boundaries: Region and Isolation Unit
When a company opens a new office, the entire building's wiring layout is designed before a single desk is moved in. In Azure, a Virtual Network (VNet) must be created before almost any resource is deployed. A VNet exists within a single Azure region, and resources within the same VNet communicate without additional configuration.
Traffic crossing region boundaries requires VNet Peering, a VPN Gateway, or ExpressRoute. VNet names only need to be unique within their resource group. If a VNet has an active Peering connection, moving it to another resource group is blocked until that Peering is removed.
A VNet can have multiple CIDR blocks as its Address Space. You can add more later, but if an existing Peering is in place, adding an overlapping CIDR will be rejected. Getting the address space right from the start avoids painful redesigns.
Subnet Partitioning and Reserved IPs
Think of subnets like floors in an office building — each floor houses a different department with its own access controls. In Azure, subnets are the primary unit for traffic isolation and policy application. Azure reserves 5 IP addresses in every subnet: the first 4 and the last 1.
For a /27 subnet (32 total addresses), only 27 IPs are available. For 15 VMs, /27 works, but /26 (59 usable IPs) gives comfortable headroom.
Certain Azure services require a dedicated subnet:
: Azure Firewall only, minimum /26 recommended : VPN Gateway and ExpressRoute Gateway only : Azure Bastion only, minimum /26 required
Subnet Delegation allows specific Azure PaaS services — such as Azure Container Instances or App Service Environment — to inject NICs directly into that subnet. Only one Delegation can be active per subnet at a time.
Public IP SKUs: Basic vs Standard
Just as a company's main phone number must stay the same for clients to trust it, some workloads need a stable, predictable public IP. Azure Public IP comes in two SKUs: Basic and Standard.
Basic SKU supports Static or Dynamic assignment and leaves inbound open by default. Standard SKU supports Static assignment only, and inbound is denied unless an NSG explicitly allows it. Zone-Redundant and Zonal deployments are available only with Standard SKU. Basic works only with Basic Load Balancer; Standard works only with Standard Load Balancer.
Standard Public IP is Zone-Redundant by default, surviving an Availability Zone failure without changing the IP address. To pin to a specific zone, choose Zonal explicitly. Basic SKU is scheduled for retirement on September 30, 2025.
IPv6 and Dual-Stack are also within AZ-700 scope. Assigning both IPv4 and IPv6 address spaces to a VNet creates a Dual-Stack configuration. For Peering to carry IPv6 traffic, both sides must have an IPv6 address space defined.
!Public IP SKU: Basic versus Standard
NAT Gateway: Expanding the Outbound SNAT Pool
Imagine a corporate mailroom where dozens of employees send letters using the same company address. When traffic scales, the shared address runs out of distinguishable port combinations — that is SNAT port exhaustion. NAT Gateway solves exactly this problem.
A single NAT Gateway can be associated with up to 16 Public IPs or a Public IP Prefix. Each IP provides 64,512 SNAT ports, so 16 IPs theoretically support roughly one million simultaneous outbound connections.
NAT Gateway is associated at the subnet level. All outbound traffic from that subnet flows through the NAT Gateway; inbound connections are not handled by it. Public IPs attached to a NAT Gateway are dedicated to outbound use only.
Choosing an Outbound Method: NAT Gateway vs Load Balancer Outbound Rules vs Instance-level Public IP
Consider three ways a restaurant handles payments: a customer walks to the kitchen, pays at the cashier, or uses a third-party card terminal. Outbound routing in Azure works the same way — three distinct paths.
Here is how the three methods compare:
NAT Gateway: 64,512 ports per IP, outbound only, applied at subnet level, dynamic port allocation so exhaustion is nearly impossible Load Balancer Outbound Rules: up to 64,512 ports per IP pre-allocated across backend VMs, fewer ports per VM as the pool grows, inbound LB rules configured separately Instance-level Public IP: 64,512 ports per VM independently, supports both inbound and outbound, configured per VM NIC
When a NAT Gateway is attached to a subnet, it takes precedence over Load Balancer Outbound Rules for that subnet's traffic.
Preventing IP Overlap and Peering Design Pitfalls
Two departments using the same mailing address will cause every letter to be misrouted. Two VNets with overlapping CIDR blocks cannot be peered — the most common address space design mistake.
If your on-premises network uses 10.0.0.0/8 and your Azure VNet also falls within that range, hybrid connectivity via ExpressRoute or VPN will fail. Always reconcile your Azure address plan with your corporate IPAM system before creating VNets.
Peering is non-transitive. If VNet A peers with VNet B and VNet B peers with VNet C, traffic between A and C does not automatically flow. You must create a direct Peering between A and C, or configure a hub VNet with 'Allow Gateway Transit' on the hub side and 'Use Remote Gateways' on the spoke side.
In a Dual-Stack Peering setup, both VNets must have an IPv6 address space assigned. If only one side has IPv6, IPv6 packets will not traverse the Peering.
Real-World Scenarios: Subnet Mistakes and Outbound Exhaustion
A team tried to place 30 VMs into a single /27 subnet. With 5 Reserved IPs subtracted from 32, only 27 addresses are available, leaving 3 VMs without an IP. The fix requires recreating the subnet as /26 (59 usable IPs) from scratch — there is no in-place resize once resources are deployed.
Hundreds of VMs sharing a single public IP started hitting SNAT port exhaustion because Load Balancer Outbound Rules pre-allocate a fixed number of ports per VM. Adding a NAT Gateway to the subnet resolves this immediately — it allocates ports dynamically, making exhaustion practically impossible even under burst traffic.
When an exam question mentions 'SNAT exhaustion', 'outbound port limit reached', or 'large number of VMs connecting to the internet', the correct answer is NAT Gateway.
Exam Key Takeaways
"Reserved IPs are 5 per subnet — calculate usable addresses" -- Subtract 5 from total addresses (/27 = 32 - 5 = 27 usable) "Dedicated subnet name for Azure Firewall" -- AzureFirewallSubnet (minimum /26) "Dedicated subnet for VPN and ExpressRoute gateways" -- GatewaySubnet "Allow a PaaS service to inject its NIC into a subnet" -- Subnet Delegation "Prevent SNAT port exhaustion for large-scale outbound" -- NAT Gateway "SNAT ports per IP on a NAT Gateway" -- 64,512 per IP, up to 16 IPs attachable "NAT Gateway vs Load Balancer Outbound Rules — which wins when both apply?" -- NAT Gateway takes precedence "Standard Public IP default inbound behavior" -- Denied by default, NSG must explicitly allow "Which SKU supports Zone-Redundant Public IP?" -- Standard SKU only "Overlapping CIDR blocks between two VNets cause what?" -- VNet Peering is blocked "Non-transitive Peering — how to solve A-C without direct peering?" -- Hub VNet with Gateway Transit + Use Remote Gateways "Dual-Stack Peering requirement" -- Both VNets must have IPv6 address space assigned
VNet = regional isolation boundary, NAT Gateway = scalable outbound SNAT pool, Subnet Delegation = PaaS NIC injection permission