Microsoft AZ-700: Azure Virtual Network Design — Study Guide

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Part of the Microsoft Azure Network Engineer AZ-700 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Address space and subnet planning

A disciplined IP addressing plan prevents future rework and avoids collisions with on-premises networks or other VNets. Use hierarchical CIDR blocks (for example, one /16 per major business unit, /24 per VNet, /26–/22 per subnet depending on role) and reserve contiguous ranges for expansion, peering, and VPN/S2S site mappings. Azure enforces name and subnet requirements for several platform services: GatewaySubnet must exist (and be sized to include the VPN gateway and its scale units), AzureFirewallSubnet must be dedicated and named AzureFirewallSubnet, and AzureBastionSubnet must be a dedicated /27 or larger. Application Gateway and many network virtual appliances also require dedicated subnets (no other resources). Plan for address non-overlap between peered VNets and on-premises ranges; overlapping address spaces break peering, VPN, and routing. Consider subnet delegation when deploying platform services (AKS, Azure Database managed instances) and avoid placing NSGs or UDRs that conflict with required platform routes for those services. A common trap is under-sizing the GatewaySubnet or AzureFirewallSubnet; these services can scale and require extra IPs over time. Trade-offs: smaller CIDRs save address space but increase future reconfiguration risk; larger CIDRs cost nothing but increase management surface. Document all assignments and reserve blocks for PaaS private endpoints, jump hosts, monitoring agents, and egress NAT capacity.

VNet peering, gateway transit, and route precedence

VNet peering provides low-latency, high-bandwidth connectivity but is not transitive: traffic from a peered spoke does not automatically route through a second peered VNet to reach on-premises. To centralize on-prem connectivity you must deploy a hub VNet with a VPN Gateway or ExpressRoute gateway. Configure the hub peering with allowGatewayTransit enabled and configure the spoke peering with useRemoteGateways enabled; the VPN Gateway must exist only in the hub. Remember peering requires non-overlapping address spaces and supports both regional and global peering (global peering incurs data transfer costs and slightly higher latency). Route precedence matters: user-defined routes (UDRs) take precedence over BGP-learned and system routes; BGP routes take precedence over system routes. If you need forced-tunneling for egress inspection, create UDRs that point to a VirtualAppliance (NVAs) or Azure Firewall, then advertise appropriate routes back to on-prem via BGP if required. Common traps include forgetting to set allowGatewayTransit on the hub or useRemoteGateways on spokes, failing to re-download P2S client configs after adding spokes (P2S clients need updated routes), and assuming peering is transitive. Choose VPN Gateway SKUs by throughput and P2S features: consider VpnGw1/2/3 for production P2S and BGP; Basic lacks many features.

VPN Gateway SKUs: VpnGw1 — moderate throughput, supports OpenVPN/IKEv2/P2S; VpnGw2 — higher throughput and TLS scaling; VpnGw3 — highest throughput and largest scale. Basic — limited features and not recommended for hub scenarios.

Service endpoints vs private endpoints and DNS implications

Service endpoints extend your VNet identity to Azure PaaS services (Storage, SQL, Cosmos DB) so traffic uses Microsoft’s backbone while the service’s public endpoint is secure to selected subnets. Private Endpoints place a network interface in your subnet that maps to the PaaS resource private IP, providing true private connectivity. Choose service endpoints when you want simple subnet-level access control without DNS changes; choose private endpoints when you require per-resource access, VNet-level isolation, or to completely disable public network access. Private endpoints create an ENI and must be associated with a private DNS zone (privatelink.<service>.azure.com) or require manual DNS A records — a frequent trap is neglecting DNS, which causes clients to resolve the public IP instead of the private endpoint. Also be aware private endpoints consume an IP from the target subnet; plan IP capacity. Service endpoints don’t eliminate the public endpoint — to fully lock down a storage account you must disable public network access after enabling private endpoint. Cost and operational trade-offs: private endpoints increase management (per-resource DNS and approvals) and slight operational complexity but offer stronger isolation; service endpoints are simpler and lower cost but less granular.

NAT gateway, Azure Firewall, and route-design trade-offs

For predictable outbound SNAT and simplified egress management, deploy Azure Virtual Network NAT (Standard NAT Gateway) on subnets or NICs and attach Standard public IPs or prefixes (standard SKU only). NAT Gateway offloads ephemeral port management; if you anticipate heavy outbound connections, attach multiple Public IP prefixes to increase available SNAT ports and avoid port exhaustion—common with many VMs or container hosts. Azure Firewall provides centralized, fully managed stateful inspection, threat intelligence, and application/FQDN filtering; choose Azure Firewall Standard for fundamental filtering and the Premium SKU for TLS inspection, IDPS, and enhanced threat capabilities. Network virtual appliances (third-party NVAs) offer feature richness or cost alternatives but require management, HA configuration, and scale planning. UDRs pointing to VirtualAppliance or Internet/NAT must be evaluated against Azure’s system routes because incorrect UDRs can break platform service traffic (for example, blocking service endpoint traffic or platform-managed health probes). For high availability and performance, consider zone-redundant SKUs (Application Gateway v2, Firewall in Availability Zones) and autoscaling capabilities versus fixed-cost appliances. Common pitfalls: attaching NAT to both subnet and NIC leads to unexpected precedence; forgetting that NAT requires Standard Public IP(s); naming and sizing AzureFirewallSubnet incorrectly; and assuming UDRs will be ignored — they override system routes.

Practical Problem: Use-Case Scenario

Scenario: Contoso Enterprises operates a hub-and-spoke Azure network. The hub in West US hosts an ExpressRoute gateway and a VpnGw2 (GatewaySubnet). Several spokes contain application subnets and private endpoints for PaaS services. Remote employees connect via Point-to-Site (P2S) VPN into the hub.

Challenge: Remote users can access resources in the hub but cannot reach VNet resources in the spokes after recent spoke additions, and some P2S clients show stale route sets.

Recommended Approach:

In the hub VNet, ensure the VPN gateway is a VpnGw2 deployed into a properly sized GatewaySubnet (at least /27); validate it is the only gateway in the peered topology and that ExpressRoute coexists via route exchange.
On the hub-to-spoke peering, set allowGatewayTransit = true on the hub-side peering. On each spoke peering, set useRemoteGateways = true and ensure address spaces are non-overlapping.
Re-generate and distribute the updated P2S VPN client configuration from the hub VPN gateway (include IKEv2/OpenVPN) and require remote users to reinstall the client so their route tables include the new spoke prefixes.
If spokes must route outbound via the hub for inspection, add UDRs in spoke route tables directing 0.0.0.0/0 to the hub virtual appliance or to Azure Firewall (deployed in AzureFirewallSubnet) and advertise necessary routes back via BGP on ExpressRoute/VPN.

Rationale: Enabling gateway transit with useRemoteGateways centralizes on-prem and P2S routing through the hub gateway without creating additional gateways, while reissuing P2S client configs updates client route tables so new spoke prefixes are reachable; UDRs and BGP ensure controlled egress and visibility for inspection.

← ExpressRoute · All domains · Hybrid Networking →

Practice these questions → · Timed practice on ExamRoll.io →