Exam Objectives Covered
- Plan and implement network segmentation and address spaces.
- Create VNets, subnets, public IP addresses, and public IP prefixes.
- Plan subnetting for gateways, private endpoints, service endpoints, firewalls, application gateways, VNet-integrated services, and Azure Bastion.
- Plan subnet delegation and shared or dedicated subnet models.
- Design public DNS zones, private DNS zones, DNS settings, VNet links, and Azure DNS Private Resolver.
Address Planning
Start with address space. Azure does not allow peering between VNets with overlapping address ranges. Hybrid designs also fail when Azure and on-premises networks overlap. Leave growth space in hub, spoke, firewall, gateway, and private endpoint subnets.
| Subnet | Purpose | Exam note |
|---|---|---|
| GatewaySubnet | VPN and ExpressRoute gateways | Must be named exactly GatewaySubnet. |
| AzureFirewallSubnet | Azure Firewall | Must be named exactly AzureFirewallSubnet. |
| AzureBastionSubnet | Azure Bastion | Must be named exactly AzureBastionSubnet. |
| Application Gateway subnet | Application Gateway instances | Use a dedicated subnet. |
| Private endpoint subnet | Private endpoint NICs | Often dedicated for governance and DNS clarity. |
| Delegated subnet | PaaS VNet integration | Delegation allows a specific service to manage resources in the subnet. |
Public IPs and Prefixes
Know individual public IP resources, public IP prefixes, and custom public IP prefixes. A public IP prefix gives you a contiguous range from Microsoft. A custom public IP prefix is bring-your-own-IP and is used when an organization must preserve known public ranges.
Azure DNS
- Azure public DNS zones host internet-resolvable records for a domain.
- Azure Private DNS zones host records resolvable inside linked VNets.
- Private DNS zone links connect a private zone to a VNet.
- Auto-registration can register VM records in a linked private zone, but only for one zone per VNet.
DNS Private Resolver
Azure DNS Private Resolver is the managed way to forward DNS between Azure and on-premises without deploying DNS servers on VMs. Inbound endpoints receive queries from on-premises or other networks. Outbound endpoints forward queries using forwarding rulesets.
Design Choices
| Requirement | Use |
|---|---|
| Resolve public internet names | Azure-provided DNS or custom DNS. |
| Resolve private endpoint names in Azure | Private DNS zone linked to the VNet. |
| Resolve Azure private endpoint names from on-premises | On-premises DNS forwards to DNS Private Resolver inbound endpoint or custom DNS in Azure. |
| Resolve on-premises names from Azure | DNS Private Resolver outbound endpoint and forwarding ruleset, or custom DNS. |
Lab
- Create a VNet with hub and workload subnets.
- Create a private DNS zone and link it to the VNet.
- Create an Azure DNS Private Resolver with inbound and outbound endpoints.
- Create a forwarding ruleset and link it to a spoke VNet.
- Test name resolution from a VM using nslookup.
Feature Deep Dive
Virtual Networks
A VNet is the isolation and routing boundary for Azure IaaS networking. Resources in the same VNet can communicate through Azure system routes unless an NSG, UDR, firewall, or host firewall blocks the flow. VNets are regional resources, but VNet peering can connect VNets in the same or different regions.
Subnet Design
Subnets are more than address slices. Many Azure services require a dedicated subnet or a delegated subnet. When a question mentions Azure Firewall, Bastion, Application Gateway, private endpoints, VNet-integrated App Service, or gateways, ask whether the subnet must be dedicated, delegated, named in a specific way, or sized for future scale.
Public IP Addressing
Public IPs can be associated with resources such as load balancers, gateways, firewalls, Bastion, and NICs. Public IP prefixes reserve a contiguous range so you can control outbound and inbound address predictability. Custom public IP prefixes are bring-your-own-IP and are more about enterprise address ownership than normal exam lab work.
Private DNS for Private Endpoints
Private endpoint DNS is one of the most common AZ-700 failure points. The client still usually uses the public FQDN of the service, but that FQDN must resolve to the private endpoint IP from private networks. If it resolves to the public address, the traffic path is wrong even if the private endpoint exists.
Common Mistakes
- Creating overlapping VNet ranges and discovering later that peering or hybrid routing cannot work.
- Putting platform services into undersized subnets.
- Creating a private endpoint but forgetting the private DNS zone link.
- Assuming Private DNS zone links cross peering automatically. They do not; design the DNS links or forwarding path.
- Using custom DNS without forwarding Azure private zones correctly.
Exam Tip
If a scenario says a private endpoint works from one VNet but not another, check DNS zone links, custom DNS forwarding, and peering before blaming the endpoint itself.
Scenario Workshop: Private Endpoint DNS Failure
Scenario: A storage account has a private endpoint in the hub VNet. A VM in the hub resolves the storage account to a private IP and connects successfully. A VM in a spoke resolves the same name to the public storage endpoint and fails because public network access is disabled.
| Observation | Meaning | Fix |
|---|---|---|
| Hub VM resolves private IP | The private endpoint and private DNS record exist. | Do not recreate the endpoint. |
| Spoke VM resolves public IP | The spoke is not using the private zone resolution path. | Link the Private DNS zone to the spoke VNet or forward through central DNS. |
| Spoke can ping hub VM | Peering works for basic network reachability. | Focus on DNS, not peering. |
The exam pattern here is important: private endpoint access is a three-part design. You need the private endpoint, a route to the private IP, and correct name resolution. Two out of three still fails.
Configuration Checklist
- Confirm VNet address spaces do not overlap with each other or on-premises networks.
- Reserve dedicated subnets for gateway, firewall, Bastion, Application Gateway, and private endpoints where appropriate.
- Document which VNets use Azure-provided DNS and which use custom DNS.
- For each private endpoint, identify the required Private DNS zone and subresource.
- For hybrid access, document the forwarding path from on-premises DNS to Azure private DNS resolution.
- Use DNS Private Resolver instead of DNS VMs when you want a managed forwarding service.
Memory Hooks
- VNet: address and isolation boundary.
- Subnet: placement and service integration boundary.
- Private DNS zone: private name-to-IP mapping.
- DNS Private Resolver: hybrid DNS forwarding without DNS servers.
- Public IP prefix: predictable public address range.
Previous | Next: Part 3 - Routing, NAT, Monitoring, and DDoS