NAT Gateway practice questions

Use an Azure Load Balancer and configure NSGs on each subnet.

Why wrong: Azure Load Balancer operates at Layer 4 (TCP/UDP) and only distributes traffic based on IP address and port rules. It cannot provide SSL termination, web application firewall (WAF) capabilities, or path-based routing, all of which are essential for protecting and properly routing HTTP(S) requests in a multi-tier web application. Configuring NSGs on each subnet adds basic network-level filtering, but NSGs alone cannot inspect or sanitize application-layer traffic, leaving the web tier vulnerable to SQL injection, XSS, and other OWASP threats. Therefore, this option is incorrect because it lacks the required Layer 7 features.

Use Azure Firewall to inspect all traffic and allow internet traffic to the web tier.

Why wrong: Azure Firewall is a stateful firewall that operates at layers 3-4 with some layer 7 capabilities, but it is not optimized for inbound web traffic with SSL offloading and URL routing like a WAF-enabled service.

Use Azure Front Door to expose the web tier and NSGs for internal isolation.

Why wrong: Azure Front Door is incorrect because it is a global service designed for distributing traffic across multiple regions or public endpoints, whereas this scenario describes a multi-tier application primarily within a single virtual network. While Front Door offers SSL termination, WAF, and URL-based routing, its global scope is not the primary requirement for exposing a web tier residing regionally within a VNet. It would be appropriate for a globally distributed application requiring cross-region traffic management and acceleration.

Azure Load Balancer

Why wrong: Azure Load Balancer operates at OSI layer 4 and only forwards TCP/UDP traffic based on IP address, port, and protocol, without inspecting the HTTP payload. It cannot offload SSL because it lacks the ability to decrypt application-layer traffic, and while it supports source IP affinity, this is not cookie-based session affinity—it relies on hashing client IPs and can break for users behind NAT or large proxy servers. Therefore, it fails to meet the web application's requirement for application-aware routing and sticky sessions.

Azure Traffic Manager

Why wrong: Azure Traffic Manager is a DNS-based routing service that resolves user requests to the appropriate endpoint based on domains, regions, or performance metrics, but it does not handle actual network traffic after DNS resolution. It cannot inspect HTTP content, so it cannot perform SSL offloading or maintain cookie-based session affinity at the application layer. Its purpose is global load balancing across multiple regions, not distributing traffic among VMs in a single regional deployment—so it is the wrong tool for this scenario.

Azure Front Door

Why wrong: Front Door is a global layer-7 load balancer with SSL offload and session affinity, but it is designed for global multi-region deployments and includes additional features like WAF. Application Gateway is the correct choice for a region-specific load balancer.

Azure Load Balancer

Why wrong: Azure Load Balancer is incorrect because it works at Layer 4 (TCP/UDP) and makes forwarding decisions based solely on IP address, port, and protocol. It cannot inspect HTTP request URLs or headers, so it is unable to perform path-based routing or SSL offload, both of which are necessary for the web application's requirements. A Load Balancer is better suited for low-latency L4 traffic, such as non-HTTP workloads or when you only need simple distribution of TCP/UDP connections.

Azure Traffic Manager

Why wrong: Azure Traffic Manager is incorrect because it is a DNS-based traffic controller that routes clients to different endpoints—such as VMs across regions—at the domain resolution level, not at the HTTP request layer. It cannot inspect URL paths, terminate TLS, or maintain session affinity, and it is designed for global load balancing across multiple Azure regions rather than distributing traffic among VMs within a single region. Since the deployment is single-region, Traffic Manager would not provide the required URL-based routing or SSL offload capabilities.

Azure Front Door

Why wrong: Azure Front Door is unsuitable here because the requirement specifies distributing traffic to multiple Azure VMs within a **single region**. Front Door is a global load balancing service designed for distributing traffic across *multiple regions* to provide optimal performance and high availability for geographically dispersed users. While it offers SSL termination and URL-based routing, making it tempting, its primary purpose is global traffic management. It would be the correct choice if the application needed a global entry point, WAF, or distribution across different Azure regions for a multi-regional architecture.

Use Azure Application Gateway with WAF

Why wrong: Application Gateway is for L7, not for encrypting VM-to-VM traffic.

Use Azure Front Door

Why wrong: Azure Front Door is for global web delivery.

Use VNet peering to connect the tiers

Why wrong: VNet peering does not provide encryption.

Azure Load Balancer (Standard)

Why wrong: Azure Load Balancer (Standard) operates at layer 4 of the OSI model, forwarding TCP and UDP traffic to backend pool members without inspecting HTTP payloads. It cannot offload SSL/TLS termination, so encrypted traffic reaches the VMs unchanged, and it does not inject X-Forwarded-For headers or support URL-path-based routing. Health probes are limited to port availability and simple TCP/HTTP checks, not application-level status, making it inadequate for a modern web application that needs centralized certificate management and session affinity.

Azure Traffic Manager

Why wrong: Azure Traffic Manager is a DNS-based global traffic router, not a proxy; it resolves client requests to an endpoint IP but does not sit in the data path, so it cannot inspect or forward HTTP requests. Because it never handles the actual connection, it cannot perform SSL termination, insert X-Forwarded-For headers, or make routing decisions based on URL paths. It relies on DNS polling and health probes to choose among endpoints, but even an HTTP probe only verifies an endpoint is reachable from Azure's perspective, not the application's health—making it unsuitable for a migration where the gateway must manage HTTPS.

Azure Front Door

Why wrong: Azure Front Door is a global layer-7 load balancer and CDN that does offer SSL termination and a WAF, but it is architected for scenarios requiring edge acceleration across multiple Azure regions via anycast. For a single-region deployment, it introduces unnecessary latency and additional cost because traffic is routed through its global edge network even when all back-ends reside in one region. Front Door also has a different feature set and session-affinity model compared to Application Gateway, so choosing it over a regional gateway complicates troubleshooting and increases operational overhead without corresponding benefit.

B

Why wrong: This design is incorrect because site-to-site VPNs traverse the public internet and offer only best-effort throughput, which is unlikely to meet the high-bandwidth and low-latency requirements of enterprise workloads; conversely, using ExpressRoute as a backup is financially impractical because you would be paying for dedicated circuits that remain idle most of the time. While VPN can be a backup, it should not be the primary for critical workloads that need consistent performance and a private network path. Therefore, Option B places the higher-performing, more reliable service as the backup rather than the primary, inverting the correct architecture.

C

Why wrong: This option is flawed because a single Azure VPN Gateway, even in active-passive mode, is primarily a VPN endpoint and does not provide the dedicated private connectivity, consistent throughput, or lower latency of ExpressRoute. Additionally, relying on one gateway instance to serve connections from both data centers introduces a single point of failure for the entire hybrid network—if that gateway fails or is patched, both sites lose connectivity. This would not satisfy a requirement for high reliability from two independent data centers, and the active-passive configuration only protects against certain gateway-level failures, not the lack of a dedicated WAN link.

D

Why wrong: This option is technically impractical because a single ExpressRoute circuit with a single VPN connection shared across two data centers creates a single point of failure and cannot provide independent path redundancy for each location. Each data center needs its own dedicated primary and backup circuit to launch a true site-to-site-to-Azure redundancy; sharing one circuit would require a complex and fragile network topology, likely with insufficient bandwidth for aggregated traffic, and any outage or maintenance on the shared circuit would simultaneously affect both data centers. This design does not meet the core objectives of high availability, fault isolation, and predictable performance across geographically separate sites.

Azure Front Door

Why wrong: Azure Front Door operates at the global edge and is intended for multi-region, internet-facing applications; it routes HTTP(S) requests to backends that must be publicly reachable or attached via Private Link. Front Door cannot directly forward traffic to a VM that only has a private IP without Private Link because the global edge needs a routable endpoint. While Front Door also offers WAF and TLS offload, its global anycast model and backend reachability constraints make it unsuitable as a regional perimeter for a single web tier using private-only VMs.

Azure Load Balancer

Why wrong: Azure Load Balancer works at Layer 4 and only forwards TCP/UDP packets based on hashing of source IP and port, without inspecting HTTP payloads. As a result, it cannot terminate SSL, filter on URL paths, or host a WAF, which are required capabilities for an internet-facing web application with application-level protection. It simply passes encrypted traffic unchanged to the VM, leaving TLS and path routing to the application itself and offering no web-specific security features.

Azure Traffic Manager

Why wrong: Azure Traffic Manager is a DNS-based traffic director that returns a client-friendly IP from a set of endpoints in its DNS responses; it does not proxy or rewrite any traffic. Since it operates purely at the DNS level, it cannot terminate SSL, apply WAF policies, or route based on a URL path — the client connects directly to the VM IP that the DNS A record resolves to. Missing these Layer 7 capabilities means Traffic Manager cannot satisfy the requirement to securely route and filter internet-facing HTTP traffic to private backend VMs.

Azure Load Balancer (Standard).

Why wrong: Azure Load Balancer (Standard) is incorrect because it operates at Layer 4, handling only TCP/UDP packets without inspecting HTTP payloads. It cannot perform TLS termination or maintain session affinity based on application cookies, relying instead on source IP (5-tuple) affinity. While it does support HTTP health probes, it lacks the layer-7 awareness needed for this web application scenario.

Azure Traffic Manager.

Why wrong: Azure Traffic Manager is a DNS-level traffic-routing service that operates globally, not in the data path; it simply resolves domain names to endpoints based on routing methods like performance or priority. Because it doesn't see the actual HTTP requests, it cannot terminate SSL, provide cookie-based session persistence, or run HTTP health checks to the application path. It is designed for failover and load balancing across regions, making it inappropriate for a single-region application spread across availability zones.

Azure Front Door.

Why wrong: Azure Front Door offers many of the same layer-7 capabilities as Application Gateway, including SSL termination, cookie-based session affinity, and global routing, but it is a global service that routes traffic through Microsoft's edge network. Deploying Front Door for a web application confined to one region adds unnecessary latency and operational complexity because clients are directed to a global entry point before reaching the regional VM set. Application Gateway v2 provides these same features with a regional footprint, aligning with the deployment's scope and performance needs.

Azure VPN Gateway

Why wrong: Azure VPN Gateway is incorrect for this requirement because it is a single-connection termination point, not a mesh. To interconnect multiple on-premises sites and VNet regions, you would have to create a separate Site-to-Site IPsec tunnel for each pair, configure each Local Network Gateway, and manually manage route tables and propagation. This approach does not scale across a large multi-region, multi-site topology and lacks the automatic transit routing and hub-based connectivity that Virtual WAN offers.

Azure ExpressRoute

Why wrong: Azure ExpressRoute does not solve the mesh requirement because it provides a dedicated, private Layer-3 link between a single on-premises edge and Azure, not between multiple on-premises sites or between VNets across regions. While it can give reliable connectivity to a specific VNet or Virtual WAN, it is just one data path; inter-site and inter-region traffic still requires additional routing, virtual network peering, or a transit service to be meshed. Without an overlay like Virtual WAN, ExpressRoute leaves the topology management manual and does not automatically interconnect all sites.

Azure Peering Service

Why wrong: Azure Peering Service is not a networking architecture but a performance-enhancement add-on that works with an existing internet or ExpressRoute connection, using provider ISP peering to improve latency and reliability to Microsoft cloud services. It does not create any type of network path between on-premises sites or Azure VNets, nor does it provide routing, mesh connectivity, or transit capabilities. Selecting it would fail the core requirement of interconnecting multiple locations because it only optimizes an already-established connection to Microsoft.

Azure Front Door with WAF, Azure SQL Database point-in-time restore, Azure Key Vault Managed HSM, Azure App Service with private endpoint, AKS with HPA, Azure Log Analytics agent, Microsoft Entra ID

Why wrong: Point-in-time restore does not guarantee an RPO of 5 minutes or an RTO of 1 hour; it is a backup restore solution, not a high-availability failover. Although it uses private endpoint and HPA, the database requirement is not met.

Azure Front Door with WAF, Azure SQL Database geo-replication, Azure Key Vault (Standard), Azure App Service with private endpoint, AKS with HPA, Azure Diagnostics extension, Microsoft Entra ID

Why wrong: This design fails the requirement for customer-managed keys stored in a managed HSM because Azure Key Vault (Standard) only supports software-protected keys, not the FIPS 140-2 Level 3 validated hardware security modules provided by Azure Key Vault Managed HSM. While the option correctly uses AKS with HPA for CPU-based scaling and SQL Database geo-replication, the key vault type is the critical compliance blocker for a financial services workload. Azure Front Door with WAF and private endpoint are acceptable, but the key management deficiency cannot be mitigated by the other components.

Azure Application Gateway with WAF, Azure SQL Database active geo-replication, Azure Key Vault Managed HSM, Azure App Service with VNet integration, AKS with cluster autoscaler, Azure Monitor Agent, Microsoft Entra ID

Why wrong: Cluster autoscaler scales the number of node VMs, not pod replicas, and does not respond to CPU utilization of pods, failing the requirement for automatic scaling based on CPU utilization. Although it meets other requirements, the scaling requirement is critical.

Use VNet peering with user-defined routes (UDRs) in each spoke and Azure Route Server.

Why wrong: VNet peering is non-transitive, so a hub-and-spoke design with peerings alone cannot route between spokes or from a spoke to on-premises. UDRs must be manually added to every spoke subnet to force traffic to an NVA, and Azure Route Server only advertises routes learned from its BGP peer (the NVA) to the hub — it does not automatically propagate connectivity to all spokes. As the number of spokes and regions grows, maintaining these UDRs and BGP peering for each NVA becomes a significant administrative burden and is prone to route misconfiguration.

Create a single large VNet and use network security groups (NSGs) to isolate traffic.

Why wrong: A single Azure VNet is scoped to one region and cannot span multiple regions, so it cannot directly interconnect spoke networks in different regions as the scenario requires. While NSGs can filter East-West traffic within a VNet, they do not route traffic, integrate with NVAs, or provide connectivity to on-premises sites; you would still need additional VPN/ExpressRoute tunnels and peering to extend outside the VNet. This approach also hits subscription and address space limits and is a poor architectural pattern for regional isolation, redundancy, or management separation.

Use Azure Firewall in the hub VNet and configure forced tunneling via custom routes.

Why wrong: Placing Azure Firewall in a conventional hub VNet only works if you manually create UDRs on every spoke subnet to send traffic to the firewall's private IP, and forced tunneling specifically influences internet-bound traffic, not transitive spoke-to-spoke or branch-to-spoke routing. The hub VNet still relies on non-transitive VNet peering and separate VPN/ExpressRoute gateways, so you must continually manage custom routes and ensure the firewall receives traffic from all regions and on-prem sites. Azure Firewall does not automatically exchange routing information between spokes or branches, and this configuration lacks the simplified routing tables and dynamic propagation that a secured Virtual WAN hub provides.

Azure Load Balancer

Why wrong: Azure Load Balancer operates at layer 4 (TCP/UDP) and simply forwards packets to backend VMs without inspecting HTTP payloads, so it cannot offload SSL/TLS or perform path-based routing. It can only enforce source IP affinity or five-tuple-based distribution, never cookie-based session persistence, and every backend VM must independently terminate TLS, which contradicts the stated requirement for SSL offloading. Therefore, a standard Load Balancer is unsuitable for an HTTP application that needs centralized TLS management and application-layer routing in a single region.

Azure Traffic Manager

Why wrong: Azure Traffic Manager is a DNS-based traffic load balancer that directs clients to endpoints based on traffic-routing methods. It does not proxy traffic, so it cannot offload SSL or provide a fixed public IP for the application.

Azure Front Door

Why wrong: Azure Front Door operates at the application layer (HTTP/HTTPS) and is designed for global load balancing across multiple regions, not for distributing traffic evenly across VMs within a single region. It lacks a single fixed public IP address for client-facing traffic, instead using anycast-based front-end hosts. This option is tempting because Front Door does offload SSL and provides HTTP routing, but it would be correct only for multi-region, latency-sensitive web applications requiring global entry points and path-based routing.

Azure Load Balancer Standard with source IP affinity

Why wrong: Azure Load Balancer Standard is a Layer 4 load balancer that only forwards TCP or UDP packets; it cannot offload SSL/TLS, so each VM must handle encryption itself, adding CPU overhead. Source IP affinity, also called sticky sessions at Layer 4, hashes the client IP address, which can still map many users to one unhealthy VM if clients share a NAT or proxy. More importantly, it does not use HTTP cookies, so if a client's IP changes mid-session, the session is lost, making it unsuitable for the described web application.

Azure Traffic Manager with performance routing

Why wrong: Azure Traffic Manager is a DNS-level traffic router rather than a load balancer; it returns one endpoint IP in response to DNS queries and depends on TTL and health checks to redirect traffic, so it cannot distribute individual HTTP requests across the multiple named VMs. It also provides no SSL offloading or session persistence, meaning each VM would need its own SSL certificate and no cookie or source-IP stickiness exists. For a single-region deployment across availability zones, Traffic Manager adds an unnecessary DNS hop and fails to meet the web application's session-affinity requirement.

Azure Front Door with session affinity

Why wrong: Azure Front Door is a powerful global Layer 7 load balancer with cookie-based session affinity and SSL offload, but its architecture is built around edge nodes and global HTTP routing, which is overkill for a single-region, multi-VM web application. Because traffic must traverse Microsoft's edge network and be routed regionally, it introduces additional network hops and latency compared with a regional Application Gateway directly in the same region. Front Door also incurs higher cost and administrative complexity; for a single-region deployment, Application Gateway v2 provides all the required features with a lower latency path.

Azure Load Balancer

Why wrong: Azure Load Balancer is a Layer 4 (transport-level) service that distributes incoming TCP and UDP traffic based on IP addresses, ports, and distribution rules using health probes. It does not inspect the HTTP payload, so it cannot perform SSL/TLS termination, cannot read or persist application cookies for session affinity, and has no integrated web application firewall. Its role is high-throughput, low-latency network load balancing, which doesn't satisfy the application-layer requirements of the scenario.

Azure Traffic Manager

Why wrong: Azure Traffic Manager operates purely at the DNS level, responding to client queries with the IP address of an appropriate endpoint based on routing methods such as performance, weighted, or priority, but it never sits in the actual data path between clients and the application. Because it only resolves DNS and does not proxy connections, it cannot terminate SSL, rewrite HTTP headers, maintain cookie-based session affinity, or inspect requests for web attacks. Its purpose is global traffic routing across regions, not regional Layer 7 protection and offload, making it unsuitable for the stated requirements.

Azure Front Door

Why wrong: Azure Front Door is a global load balancer for multi-region scenarios; while it supports SSL offloading and WAF, it is designed for global traffic management, not regional load balancing across availability zones within a single region.

Azure Load Balancer

Why wrong: Azure Load Balancer is a Layer-4 (TCP/UDP) service that cannot decrypt HTTPS traffic, so it cannot perform SSL termination or inspect application-layer cookies for cookie-based session affinity. Its session persistence is limited to source-IP or 5-tuple hashing, which can misdirect users behind a common NAT gateway and is not the application-layer stickiness required by an HTTPS web application. While it does support availability-zone-aware distribution and high throughput, it lacks URL-based routing and HTTP-level health probes, making it unsuitable for this scenario.

Azure Traffic Manager

Why wrong: Azure Traffic Manager functions at the DNS level and simply resolves a domain name to an IP address chosen from a set of regional endpoints, routing traffic across separate Azure regions rather than balancing within one region's availability zones. It never sees the HTTP/HTTPS payload, so it cannot perform SSL termination, inspect paths, or set session cookies—its health checks are basic endpoint probes, not application-layer validations. For a single-region web app on VMs that needs cookie-based affinity and zone-level distribution, Traffic Manager offers no relevant capability and would be an architectural mismatch.

Azure Front Door

Why wrong: Azure Front Door operates at the application layer (HTTP/S) and can perform SSL offloading and session affinity via cookie-based persistence, but it is a global, multi-region load balancer designed for distributing traffic across regional endpoints, not for balancing traffic across VMs within a single Azure region. The scenario requires intra-region load balancing across availability zones, which Front Door does not natively support—Azure Load Balancer or Application Gateway would handle that. It is tempting because Front Door offers SSL termination and session persistence, making it a correct choice for global web applications needing accelerated delivery and cross-region failover, such as a multi-region deployment with users distributed worldwide.

Azure Virtual Network

Why wrong: Azure Virtual Network (VNet) is a foundational networking component that provides isolation and segmentation for Azure resources, but it does not include any built-in managed connectivity for branch offices. Connecting on-premises sites to a VNet requires deploying separate VPN Gateways or ExpressRoute circuits and then manually configuring peering and user-defined routes for every branch. Because VNets lack an integrated hub or automatic routing logic, they are a building block, not a complete multi-site connectivity solution.

Azure ExpressRoute

Why wrong: ExpressRoute provides a private, high-bandwidth, low-latency dedicated connection from a single on-premises location to Azure, bypassing the public internet, but it does not provision any connectivity between branch offices or between branches and Azure beyond that one circuit. Each branch would need its own ExpressRoute circuit or an aggregation router, and branch-to-branch traffic still requires a routing infrastructure such as Virtual WAN to forward packets. ExpressRoute alone cannot serve as a hub for automatic multi-site routing because it only offers point-to-point connectivity to the Microsoft edge.

Azure VPN Gateway

Why wrong: VPN Gateway establishes an IPsec Site-to-Site (S2S) VPN tunnel between one on-premises network and a specific Azure VNet, but it is not designed to aggregate multiple branch offices into an automated topology. To interconnect several branches, you must deploy multiple VPN gateway connections or configure complicated IPsec tunnels between branch devices, and you still need manual routing or a VPN concentrator to enable branch-to-branch communication. Since VPN Gateway lacks the managed hub with automatic routing and propagation that Virtual WAN provides, it is insufficient for a multi-branch environment.

Azure Load Balancer

Why wrong: Azure Load Balancer operates at Layer 4 (TCP/UDP) and simply forwards packets to backend VMs based on rules and health probes. It does not terminate SSL/TLS, inspect HTTP headers, or perform URL path-based routing, so it cannot distribute requests based on application paths such as /api or /images. For this web application scenario that requires Layer 7 traffic management, Azure Load Balancer is fundamentally inadequate.

Azure Traffic Manager

Why wrong: Azure Traffic Manager is a DNS-based traffic routing service that operates at the domain name resolution level, directing clients to an eligible regional endpoint based on routing methods like performance, priority, or geography. It cannot inspect HTTP requests, parse URL paths, or terminate TLS connections because it never sits in the data path between clients and servers. While it can provide global failover and latency-based routing, it does not meet the Layer 7 requirements of URL path routing and SSL termination.

Azure Front Door

Why wrong: Azure Front Door is incorrect because it is a global, edge-based service primarily designed for distributing traffic across multiple Azure regions or hybrid environments. While it provides URL-path-based routing and SSL/TLS termination, which are required, its global nature is not specified as a requirement for this regional Azure VM deployment. It is tempting because it performs these Layer 7 functions, and would be the correct choice for globally distributed web applications needing optimal performance, high availability, and security at the edge.

Azure Load Balancer

Why wrong: Azure Load Balancer is a layer-4 (TCP/UDP) service that forwards traffic without inspecting HTTP payloads. It cannot perform SSL termination, URL path-based routing, or cookie-based session affinity, and its only persistence mechanism is source IP (5-tuple) hashing, which breaks if clients change IPs. For a web application requiring these L7 features, it is fundamentally misaligned, even though it provides high availability and scale at the network layer.

Azure Front Door

Why wrong: Front Door is a global layer-7 load balancer and CDN. While it supports SSL offload and session affinity, it is designed for multi-region distribution and may introduce unnecessary latency for single-region use. It is not the optimized choice for a single-region scenario.

Azure Traffic Manager

Why wrong: Azure Traffic Manager operates at the DNS level, routing clients to endpoints based on DNS resolution policies (e.g., priority, geographic, round-robin) and endpoint health checks. It does not inspect HTTP packets, so it cannot terminate SSL, route by URL path, or maintain application session affinity. Traffic Manager is only a global traffic distribution service, not a substitute for an in-front-of-the-application load balancer, and it is incorrect for these specific application-layer needs.