Azure AZ-700 common mistakes
Azure AZ-700 · Understand the traps and how to avoid them.
Designing a hub-and-spoke topology where spokes are peered only to the hub and then assuming spoke-to-spoke traffic will flow through the peering without any transit configuration.
VNet peering is non-transitive by design, and the portal lets you create both peerings successfully, so the design looks complete. Candidates carry over an assumption from routed networks that a peered hub will forward traffic automatically.
What to do instead
Add an explicit transit path: deploy Azure Firewall or an NVA in the hub, create user-defined routes in each spoke subnet pointing 0.0.0.0/0 or the remote spoke address space to the firewall/NVA private IP, and enable IP forwarding. For on-premises reachability also set UseRemoteGateways on spokes and AllowGatewayTransit on the hub.
Sizing or naming infrastructure subnets incorrectly, for example creating a /29 GatewaySubnet, naming it 'GatewaySubnet1', or placing the Azure Firewall in a /27 AzureFirewallSubnet.
The subnet name is a hard platform requirement that is easy to overlook when subnets are created up front as part of a general address plan, and candidates remember 'a /29 is the minimum' without remembering the recommended sizes or the per-service minimums.
What to do instead
Use the exact reserved names: GatewaySubnet (/27 or larger recommended, /29 absolute minimum for most SKUs), AzureFirewallSubnet (/26), AzureBastionSubnet (/26), and AzureFirewallManagementSubnet (/26) for forced tunneling. Reserve these blocks in the address plan before deploying any workloads.
Building a site-to-site VPN and expecting active-active tunnels, higher aggregate throughput, or IKEv2 custom crypto by selecting the Basic VPN Gateway SKU.
The SKU selection screen shows a long list of gateway SKUs and Basic is the cheapest and most familiar-looking, so it gets chosen first; the feature limits are documented separately and the deployment succeeds, hiding the constraint until testing.
What to do instead
Choose VpnGw1 or higher (VpnGw1AZ-VpnGw5AZ for zone redundancy) for active-active, BGP, custom IPsec/IKE policy, and higher aggregate throughput. Configure a matching custom IPsec/IKE policy on both the Azure gateway and the on-premises device when the default proposal set does not intersect.
Planning ExpressRoute FastPath, or encrypted ExpressRoute traffic, on a gateway SKU that does not support it, such as ErGw1AZ.
FastPath and VPN-over-ExpressRoute are presented as ExpressRoute circuit features, so candidates assume they are independent of the virtual network gateway SKU. The circuit provisions fine and only the data-path feature silently fails to enable.
What to do instead
Use ErGw3AZ for FastPath and for gateway-based IPsec over ExpressRoute private peering; use UltraPerformance/ErGw3AZ for the highest scale. Where ExpressRoute and VPN coexist, control path preference with AS path prepending or BGP local preference rather than assuming ExpressRoute always wins.
Deploying a Standard SKU public load balancer and then assuming backend VMs still have outbound internet access the way they did with a Basic load balancer.
Standard SKU is secure by default: there is no implicit outbound access and no implicit inbound access from the internet. This behaviour change from Basic SKU is not visible in the portal, and the symptom (intermittent package/update failures or no internet) appears only at runtime.
What to do instead
Attach an explicit outbound rule to the load balancer's backend pool, or associate a NAT Gateway with the subnet, or assign instance-level public IPs. Also confirm the NSG and the load balancer health probe allow the traffic you expect.
Selecting Traffic Manager to provide fast regional failover or to terminate TLS, expecting it to proxy client requests.
All three of Front Door, Application Gateway, and Traffic Manager are described as 'load balancers', so candidates pick Traffic Manager for global distribution without accounting for its DNS-based, non-proxying nature and its dependence on client DNS TTL caching.
What to do instead
Use Front Door (or Application Gateway for regional L7) when you need TLS termination, WAF, path-based routing, or near-instant failover. Use Traffic Manager only for DNS-level distribution, and remember that failover latency is bounded below by the record's TTL and resolver caching.
Creating a private endpoint for a PaaS service and then testing from a client that still resolves the service's public FQDN to its public IP address.
The private endpoint and its NIC are created successfully and show a private IP, so the deployment looks correct. What is missing is the DNS layer: the public zone still answers, and without a linked privatelink zone the client never learns the private IP.
What to do instead
Create the correct privatelink zone (for example privatelink.blob.core.windows.net), link it to every VNet that must resolve the name, and rely on the auto-registered A record or create it. For on-premises clients, configure conditional forwarders to the Azure DNS private resolver or to DNS servers that can forward the privatelink zones.
Using a service endpoint where the requirement is that traffic use a private IP address or originate from on-premises, or assuming a service endpoint encrypts or privately routes the traffic.
Service endpoints and private endpoints are both presented as 'securing access to PaaS', and both appear on the service firewall blade. Service endpoints only change the source identity seen by the service; the destination remains the public IP and the feature does not extend beyond the VNet.
What to do instead
Choose by requirement: use private endpoints when traffic must use a private IP, when access is needed from on-premises or peered networks, or when the PaaS service must be fully removed from public exposure. Use service endpoints only to restrict a service's firewall to a VNet while traffic still flows to the public endpoint.
Deploying Azure Firewall and routing subnets to it, but omitting the user-defined route for the egress path (or creating an asymmetric route) so that traffic bypasses the firewall or return traffic is dropped.
Azure Firewall is inserted only by routing; there is no automatic insertion. In addition, the AzureFirewallSubnet itself must not have a 0.0.0.0/0 route to the firewall, and mixing a default route to the firewall with a gateway-learned default route from on-premises produces asymmetry.
What to do instead
Add a UDR on each workload subnet with 0.0.0.0/0 (or the specific prefixes) next hop Virtual appliance = the firewall private IP, and enable IP forwarding on any NVA. Keep AzureFirewallSubnet free of a self-referential default route, and when forced tunneling is required use the AzureFirewallManagementSubnet pattern so the firewall's own management traffic is not routed through on-premises.
Assuming Azure DDoS Network Protection is active on every VNet, or expecting Azure Firewall Premium capabilities such as TLS inspection and IDPS on the Standard SKU.
Azure applies always-on infrastructure-level DDoS protection to the platform, and candidates conflate that baseline with the per-VNet DDoS protection plan. Similarly, Firewall policy features are listed together in documentation, and the SKU constraint is easy to miss at deployment time.
What to do instead
Create an Azure DDoS protection plan and explicitly associate each VNet, and confirm the protected public IP resources. For TLS inspection, IDPS, and URL filtering, deploy Azure Firewall Premium and attach a Premium firewall policy; Standard supports only the base DNAT, network, and application rule capabilities.