Last reviewed: May 2026
A scannable reference of architectural patterns the AZ-700 exam tests. Read top-to-bottom, or jump to a section.
Connect resources across VNets in different subscriptions or regions privately.
Configure VNet peering between the virtual networks.
Why: Keeps traffic on the Microsoft backbone. VNet peering is non-transitive; direct peering is required for communication (A->B, B->C != A->C).
Design VNet address spaces for future connectivity.
Assign unique, non-overlapping CIDR blocks to each VNet.
Why: VNet peering requires non-overlapping address spaces. Plan for growth to avoid re-architecting.
Calculate the required subnet size for a specific number of hosts.
Use CIDR notation that provides the required hosts + 5 reserved IP addresses for Azure.
Why: Azure reserves the first four and the last IP address in every subnet. A /24 (256 IPs) provides only 251 usable IPs.
Deploy services like Azure Firewall, Gateway, or Bastion.
Create dedicated subnets with specific names (e.g., AzureFirewallSubnet, GatewaySubnet, AzureBastionSubnet) and minimum sizes (/26, /27, /26 respectively).
Why: These services require dedicated, specifically named subnets to inject their resources. Sizing is critical for functionality and future scaling.
Enable name resolution between on-premises networks and Azure Private DNS zones.
Deploy Azure DNS Private Resolver. Use an inbound endpoint for on-prem to Azure queries and an outbound endpoint with forwarding rules for Azure to on-prem queries.
Why: Provides a managed PaaS solution for hybrid DNS without requiring custom DNS VMs. On-prem DNS forwards to the inbound endpoint IP.
A peered VNet cannot resolve records in a Private DNS zone.
Create a virtual network link from the Private DNS zone to the peered VNet.
Why: Private DNS zone access is not transitive through peering. Each VNet requiring resolution must have an explicit link.
Provide a static, predictable outbound public IP for VMs in a subnet for allow-listing.
Associate an Azure NAT Gateway with a Public IP or Public IP Prefix to the subnet.
Why: NAT Gateway overrides all other outbound connectivity methods for a subnet, ensuring all traffic uses its static public IP(s).
Ensure a public IP for a resource like a Load Balancer remains constant.
Use a Standard SKU Public IP address with Static allocation.
Why: Standard SKU static IPs are zone-redundant by default and persist even when the associated resource is stopped or deleted.
Design a subnet for an AKS cluster using Azure CNI networking.
Calculate IP needs as (number of nodes * max pods per node) + number of nodes. Allocate a subnet that can accommodate this count.
Why: With Azure CNI, every pod gets an IP directly from the subnet, requiring significant IP address allocation.
Route all internet-bound traffic from a spoke VNet through an Azure Firewall in the hub VNet.
Create a User Defined Route (UDR) table with a route for 0.0.0.0/0, next hop type "Virtual appliance", and the private IP of the Azure Firewall.
Why: This overrides the default system route to the internet, forcing all traffic through the firewall for inspection.
Inspect traffic between two spoke VNets using an Azure Firewall in the hub.
In each spoke, create UDRs for other spoke address spaces pointing to the firewall. In the firewall, create network rules to allow the traffic.
Why: Routing must be configured on both spokes to send traffic to the firewall, which by default denies inter-VNet traffic.
Deploy a resilient NVA cluster for traffic inspection or routing.
Use Azure Route Server. The NVAs peer with Route Server via BGP and advertise routes. Route Server uses ECMP for load distribution.
Why: Route Server simplifies dynamic routing with NVAs, eliminating complex UDR management and providing automated failover.
An NVA is dropping traffic it should be routing.
Enable "IP forwarding" on the NVA's network interface (NIC).
Why: This Azure-level setting is required to allow the NIC to receive and forward traffic not destined for its own IP address.
Distribute HTTP/S traffic globally to the lowest latency backend with WAF and SSL offloading.
Use Azure Front Door.
Why: Front Door uses anycast routing for optimal performance and integrates WAF, URL routing, and SSL offloading at the edge.
Distribute traffic to global endpoints based on DNS with health-probe driven failover.
Use Azure Traffic Manager.
Why: Traffic Manager is a DNS-based load balancer. Use "Performance" routing for lowest latency or "Priority" for active/passive failover.
Provide regional HTTP/S load balancing with WAF, SSL termination, and URL/host-based routing.
Deploy Azure Application Gateway v2.
Why: Application Gateway is a regional L7 load balancer. Use path-based rules for URL routing and multi-site listeners for host-based routing.
Load balance non-HTTP/S (TCP/UDP) traffic within a region.
Use Azure Load Balancer (Standard SKU).
Why: Azure Load Balancer is a regional L4 load balancer. It preserves the client source IP and is suitable for all TCP/UDP protocols.
Terminate SSL at Application Gateway but re-encrypt traffic to the backend.
Configure an HTTPS listener. In the backend HTTP settings, set the protocol to HTTPS and upload the backend servers' trusted root certificate.
Why: Ensures traffic is encrypted in transit all the way to the backend, even with self-signed certificates on backend servers.
Load balance traffic to a SQL Server Always On Availability Group listener.
Use an internal Standard Load Balancer with the "Floating IP (Direct Server Return)" setting enabled on the load balancing rule.
Why: Floating IP is required for the SQL AG listener to function correctly, as it allows the secondary node to respond directly to clients after a failover.
Load balance traffic to a cluster of NVAs that must process all protocols and ports.
Use an internal Standard Load Balancer with an "HA Ports" load balancing rule.
Why: HA Ports rule forwards all TCP and UDP traffic on all ports, simplifying configuration for NVAs that need to inspect all traffic flows.
Configure automatic failover between a primary and secondary web application origin.
Place both origins in the same Front Door origin group. Assign the primary origin a priority of 1 and the secondary a lower priority (e.g., 2).
Why: Front Door always sends traffic to the highest-priority healthy origin. When the primary fails health probes, traffic automatically shifts to the next priority.
Provide secure RDP/SSH access to Azure VMs without exposing management ports to the internet.
Deploy Azure Bastion (Standard SKU for advanced features).
Why: Bastion acts as a managed jump box, providing access via the Azure portal over TLS. It eliminates the need for public IPs on VMs for management.
Access an Azure PaaS service (e.g., SQL, Storage) using a private IP address from within your VNet.
Create a Private Endpoint for the PaaS resource. Integrate with a Private DNS Zone for automatic name resolution.
Why: Private Endpoint projects the PaaS service into your VNet with a private IP, enabling truly private connectivity. Disabling public network access on the PaaS service enforces this.
Access Azure PaaS services from a VNet over the Azure backbone without using public IPs, but without managing a dedicated private IP.
Enable a Service Endpoint for the specific service (e.g., Microsoft.Storage) on the source subnet.
Why: Service Endpoints provide a direct route to PaaS services from a VNet, but don't use a private IP in the VNet. It is simpler but less flexible than Private Endpoints.
Expose a service running in your VNet to consumers in other VNets (potentially other tenants) privately.
Place the service behind a Standard Load Balancer and create a Private Link Service pointing to it.
Why: Private Link Service is the provider-side component. Consumers create Private Endpoints in their VNets to connect to your service privately.
Simplify NSG rules for a multi-tier application where VMs may scale or change IPs.
Create Application Security Groups (ASGs) for each tier (e.g., Web, App, DB). Define NSG rules using ASGs as source/destination.
Why: ASGs act as network object tags for VMs, allowing you to create rules based on application structure rather than brittle IP addresses.
Traffic is unexpectedly blocked when NSGs are applied to both a NIC and its subnet.
Recall the NSG rule evaluation order. Inbound: NIC rules first, then Subnet rules. Outbound: Subnet rules first, then NIC rules.
Why: A deny at any level will block the traffic. Both NSGs must permit the traffic flow for it to succeed.
Automatically block traffic to/from known malicious IP addresses and domains.
Enable Azure Firewall Threat intelligence-based filtering in "Alert and deny" mode.
Why: This uses Microsoft's threat intelligence feed to provide managed, up-to-date protection against known threats with zero configuration.
Inspect encrypted HTTPS traffic for threats like malware.
Use Azure Firewall Premium. Enable TLS Inspection in the policy and deploy an intermediate CA certificate that clients must trust.
Why: This is a premium feature that performs a man-in-the-middle decryption to inspect traffic, which is critical for a zero-trust security posture.
Allow outbound access to complex Microsoft services like Windows Update without maintaining IP lists.
In Azure Firewall, create an Application Rule using FQDN Tags (e.g., "WindowsUpdate", "AzureBackup").
Why: Microsoft manages the FQDNs associated with these tags, simplifying firewall rule management for dynamic services.
Protect public-facing applications from volumetric DDoS attacks and get access to rapid response support.
Enable DDoS Network Protection (formerly Standard) on the VNet.
Why: Provides adaptive tuning, attack telemetry, mitigation reports, and access to the DDoS Rapid Response team, which the free Basic protection lacks.
Diagnose a connectivity failure and identify the exact hop where traffic is being dropped.
Use Network Watcher > Connection Troubleshoot.
Why: It performs an end-to-end check, showing the full hop-by-hop path and pinpointing failures due to NSGs, UDRs, or other network issues.
Quickly verify if an NSG rule is allowing or denying traffic to/from a VM.
Use Network Watcher > IP Flow Verify.
Why: This is the most direct tool to test a specific 5-tuple against NSG rules and see which rule is responsible for the outcome.
Log all allowed and denied network traffic for compliance and analysis.
Enable NSG Flow Logs and ingest them into Traffic Analytics (via a Log Analytics Workspace).
Why: NSG Flow Logs provide raw traffic data. Traffic Analytics enriches and visualizes this data to identify traffic patterns, top talkers, and security threats.
Connect an on-premises network to Azure with a private, dedicated connection offering predictable latency and high bandwidth.
Provision an Azure ExpressRoute circuit.
Why: ExpressRoute bypasses the public internet entirely, providing a more reliable, faster, and lower latency connection than a Site-to-Site VPN.
Choose the correct ExpressRoute peering to access Azure resources.
Use Azure private peering to connect to VNets. Use Microsoft peering to access public PaaS services and Microsoft 365.
Why: The two peering types provide access to different sets of resources. Microsoft peering requires public IPs, NAT, and route filters.
Allow spoke VNets to access on-premises networks via a central VPN or ExpressRoute gateway in the hub VNet.
On the hub-to-spoke peering, enable "Allow gateway transit". On the spoke-to-hub peering, enable "Use remote gateways".
Why: This two-part configuration allows spokes to use the hub's gateway, centralizing hybrid connectivity.
Configure a Site-to-Site VPN as a backup for an ExpressRoute connection.
Deploy both an ExpressRoute and a VPN gateway. By default, ExpressRoute paths are preferred over VPN paths for the same prefixes.
Why: Azure automatically prefers ExpressRoute due to a higher default route weight. If the ExpressRoute circuit fails, BGP will withdraw the routes and traffic will fail over to the VPN.
Influence traffic to prefer one ExpressRoute circuit over another for active/passive redundancy.
Use BGP AS Path prepending. Add your own ASN multiple times to the route advertisements on the backup circuit to make its path appear longer.
Why: BGP prefers the shortest AS Path. This makes the primary circuit the preferred path, with automatic failover to the backup if the primary path is withdrawn.
Connect two on-premises sites through the Microsoft backbone network using their existing ExpressRoute circuits.
Enable ExpressRoute Global Reach.
Why: Global Reach links two ExpressRoute circuits together, enabling a private WAN over the Microsoft network without traffic having to hairpin in an Azure VNet.
Simplify the management of a global network connecting many branch offices and VNets.
Deploy Azure Virtual WAN.
Why: Virtual WAN provides a managed hub-and-spoke service with automated any-to-any transitive connectivity, routing, and integration with security services (secured hub).
In Virtual WAN, inspect all inter-VNet, inter-branch, and internet-bound traffic centrally.
Deploy a secured virtual hub (with Azure Firewall). Configure routing intent to send private and internet traffic through the firewall.
Why: Routing intent simplifies traffic engineering in vWAN, automatically programming routes to force traffic through the security provider without manual UDRs.
Provide a resilient VPN connection to Azure.
Deploy a VPN Gateway in an active-active configuration. This requires two public IPs and an on-prem device capable of establishing two tunnels.
Why: Provides instance-level redundancy within the Azure region. For cross-zone redundancy, use zone-redundant (AZ) SKUs.
Choose a Point-to-Site VPN protocol for broad client compatibility without extra software.
Use IKEv2. For maximum compatibility including older devices, use OpenVPN.
Why: IKEv2 is natively supported on modern Windows, macOS, and iOS. SSTP is Windows-only. OpenVPN requires a client but is widely supported.
Redirect all internet-bound traffic from Azure VMs to an on-premises security appliance.
From on-premises, advertise a default route (0.0.0.0/0) via BGP over the ExpressRoute or VPN connection.
Why: This BGP advertisement overrides Azure's default internet route, forcing traffic back to the on-premises network for inspection.