Implement and manage virtual networking
VNet Addressing, Subnets, Peering, and Public IPs
CoreBuild address spaces, subnet boundaries, peerings, and public IP attachments with nonoverlapping topology.
Aligned to the current AZ-104 study guide, verified August 21, 2026.
Why this matters
Address planning and connectivity objects set the foundation for routing and security; overlapping ranges or a wrongly scoped public endpoint can block later administration.
Must Know
- A VNet defines private address space and subnets divide that space into deployable network boundaries.
- Subnet ranges cannot overlap inside a VNet, and peered VNets must use nonoverlapping address spaces.
- VNet peering provides private connectivity over the Azure backbone but is not transitive by default.
- Peering is configured for both directions and has separate settings for forwarded traffic, gateway transit, and remote gateways.
- A public IP is a separate Azure resource attached to a supported frontend or network interface according to SKU and configuration.
Compare and Distinguish
- VNet vs subnet: regional private network address space vs a segment used for resource placement and policy attachment.
- VNet peering vs subnet routing: connectivity between VNet address spaces vs next-hop selection for packets leaving a subnet.
- Public IP vs Azure Bastion: internet-reachable address on a resource path vs managed private VM administration without target VM public IPs.
Scenario examples
- Scenario: Two application VNets must peer but both use the same address range. Think: Renumber one side before peering because overlapping address spaces are invalid.
- Scenario: VNet A peers with B and B peers with C, but A cannot reach C. Think: Peering is not transitive; configure a direct or routed topology deliberately.
- Scenario: A public load balancer needs a stable internet frontend. Think: Attach a supported static public IP resource to the frontend configuration.
Exam traps
- Peering one side or having a connected state does not override NSGs, routes, DNS, or guest firewalls.
- A subnet reserves Azure addresses, so its entire CIDR is not available for workloads.
- A public IP assignment is not required for private administration through Azure Bastion.
Key takeaways
- Plan nonoverlapping address space with growth room before deploying dependent resources.
- Use peering for direct VNet connectivity and attach public IPs only where internet exposure is intended.
How it works
- Azure programs system routes for VNet, subnet, and peering prefixes, then combines them with applicable user-defined and propagated routes.
- A public frontend maps supported inbound or outbound connectivity to the private resource path without changing its private address.
Objects and administrative surfaces
- VNet — region, address spaces, DNS settings, peerings, and connected resources.
- Subnet — address prefix, delegations, service endpoints, NSG, route table, and resource attachments.
- Public IP — SKU, allocation, zone choice, DNS label where used, and attachment to a supported frontend.
When to use it
- Use peering for low-latency private connectivity between nonoverlapping VNets.
- Use public IPs for explicitly internet-facing frontends and private access patterns for administrative endpoints.
Security and governance implications
- Avoid casual public IP attachment and inventory every internet-facing endpoint.
- Reserve address space centrally and document peering plus forwarding intent to prevent accidental transit assumptions.
How to reason about this
- For VNet creation or peering failure, inspect CIDR validity, overlap, subscription permissions, and peering state.
- For reachability after peering, verify DNS, effective routes, both-direction peering settings, NSGs, appliances, and guest firewall.
More detail
- Create VNets and subnets with valid prefixes, configure peering on both sides, and choose public IP properties compatible with the attached resource.
- Understand that subnet associations for NSGs and route tables are independent from peering connectivity.
Ready for the quiz?
- Why must peered VNet address spaces not overlap?
- Which peering property matters when traffic arrives through another network appliance?
- What Azure resource supplies an internet-facing load balancer frontend address?
Related objectives
- D4.1.S1 — Create and configure virtual networks and subnets
- D4.1.S2 — Create and configure virtual network peering
- D4.1.S3 — Configure public IP addresses