NAT Gateway practice questions

A company is deploying a multi-tier web application on Azure VMs. The web tier must be accessible from the internet, while the application and database tiers must be isolated within the virtual network. The solution must provide SSL termination, web application firewall (WAF) capabilities, and URL-based routing. Which Azure service should they use to expose the web tier?

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

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.

Trap 2: Use Azure Firewall to inspect all traffic and allow internet…

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.

Trap 3: Use Azure Front Door to expose the web tier and NSGs for internal…

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.

A
Use an Azure Load Balancer and configure NSGs on each subnet.
Why it fails: 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.
B
Use Azure Firewall to inspect all traffic and allow internet traffic to the web tier.
Why it fails: 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.
C
Use Azure Application Gateway with WAF, and configure NSGs to restrict traffic between tiers.
Azure Application Gateway is a Layer 7 regional load balancer that provides SSL termination, WAF, URL-based routing, and cookie-based session affinity, making it the appropriate entry point for the web tier. By enabling WAF, it actively blocks common web vulnerabilities such as SQL injection and cross-site scripting before they reach the backend. Complementing this with NSGs on each subnet enforces network-level isolation, ensuring that only the web tier can communicate with the app tier on specific ports (e.g., 8080/tcp) and that the app tier cannot initiate outbound connections to the internet. This combination of application-layer protection and subnet-level access control exactly matches the requirement to restrict traffic between tiers while securely exposing the web tier.
D
Use Azure Front Door to expose the web tier and NSGs for internal isolation.
Why it fails: 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.

Question 2easymultiple choice

A company deploys a web application on multiple Azure VMs. They need to distribute incoming HTTP traffic across the VMs, offload SSL/TLS termination, and maintain session persistence (sticky sessions) so that all requests from a user session go to the same backend VM. Which Azure load balancing solution should they use?

Trap 1: Azure Load Balancer

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.

Trap 2: Azure Traffic Manager

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.

Trap 3: Azure Front Door

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.

A
Azure Application Gateway
Azure Application Gateway is a dedicated layer-7 (HTTP/HTTPS) load balancer that offers SSL offloading by terminating client SSL connections and re-encrypting traffic to backends if needed. It provides cookie-based session affinity, which ensures a user's requests are consistently routed to the same backend VM—a critical requirement for stateful web applications. Additionally, it supports URL path-based routing and an integrated Web Application Firewall, making it the correct choice for a web application deployed on multiple VMs within a single Azure region.
B
Azure Load Balancer
Why it fails: 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.
C
Azure Traffic Manager
Why it fails: 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.
D
Azure Front Door
Why it fails: 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.

Question 3mediummultiple choice

A company deploys a web application across multiple Azure VMs in a single region. They need to distribute incoming HTTP traffic, offload SSL termination, and perform URL-based routing to different backend pools (e.g., /images to one pool, /api to another). Which Azure load balancing solution should they use?

Trap 1: Azure Load Balancer

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.

Trap 2: Azure Traffic Manager

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.

Trap 3: Azure Front Door

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.

A
Azure Application Gateway
Azure Application Gateway is the correct choice because it operates at Layer 7 (HTTP/HTTPS), enabling URL path-based routing to distribute traffic to backend Azure VM pools based on request paths. It also provides SSL termination at the gateway, reducing the backend VMs' TLS processing overhead, and supports features like cookie-based session affinity, Web Application Firewall (WAF), and autoscaling—all within a single Azure region, which directly matches the deployment architecture.
B
Azure Load Balancer
Why it fails: 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.
C
Azure Traffic Manager
Why it fails: 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.
D
Azure Front Door
Why it fails: 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.

Question 4easymultiple choice

A company plans to migrate a legacy web application to Azure. The application runs on multiple Windows virtual machines (VMs) in an availability set. The VMs must be exposed to the internet via a single endpoint that performs SSL termination and health checks. The load-balancing solution must preserve the original client IP address for logging purposes. Which Azure service should the company use?

Trap 1: Azure Load Balancer (Standard)

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.

Trap 2: Azure Traffic Manager

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.

Trap 3: Azure Front Door

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.

A
Azure Load Balancer (Standard)
Why it fails: 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.
B
Azure Application Gateway v2
Azure Application Gateway v2 is the appropriate choice because it is a regional layer-7 reverse proxy that terminates SSL/TLS at the gateway, offloading certificate management from the web servers. It supports cookie-based session affinity, URL-based routing, and a built-in web application firewall (WAF), while preserving the original client IP via the X-Forwarded-For request header. The v2 SKU also provides autoscaling, high availability, and a resilient static VIP, aligning well with a single-region legacy web application migration.
C
Azure Traffic Manager
Why it fails: 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.
D
Azure Front Door
Why it fails: 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.

Question 5hardmultiple choice

Your company is designing a new cloud-native application on Azure that consists of multiple microservices running on Azure Kubernetes Service (AKS). The application must be accessible from the internet via a custom domain name (app.contoso.com) and must support SSL/TLS termination. You need to design a secure ingress solution that provides Web Application Firewall (WAF) capabilities, SSL offloading, and automatic scaling. The solution should also support path-based routing to different microservices (e.g., /api, /web). You have the following options: Option A: Deploy an Azure Application Gateway v2 with WAF in front of the AKS cluster. Configure Application Gateway Ingress Controller (AGIC) to route traffic to the services. Option B: Deploy an Azure Load Balancer with a public IP and install an NGINX ingress controller on AKS. Configure SSL termination on NGINX and use a third-party WAF. Option C: Deploy an Azure Front Door with WAF policy in front of the AKS cluster. Use Azure Private Link to connect Front Door to the internal load balancer of AKS. Option D: Deploy an Azure API Management instance with WAF and expose the microservices through API endpoints. Use Azure Application Gateway as a reverse proxy. Which option best meets the requirements for a high-performance, integrated, and managed solution with minimal operational overhead?

Trap 1: Deploy an Azure Front Door with WAF policy in front of the AKS…

Azure Front Door is a global, anycast-based load-balancing service designed to route traffic across multiple regions. For a single-region AKS deployment, sending traffic through Front Door's edge network adds an unnecessary network hop and introduces latency, while Private Link endpoints to the AKS internal load balancer incur extra cost and configuration complexity. Application Gateway v2, by contrast, is a regional L7 solution that keeps traffic within the region and integrates directly with AKS.

Trap 2: Deploy an Azure Load Balancer with a public IP and install an NGINX…

This approach delegates TLS termination, request routing, and web application firewall duties to an NGINX ingress controller and an external third-party WAF running on self-managed infrastructure. The Azure Load Balancer only provides Layer 4 transport rules and does not understand HTTP paths or host headers, so everything above L4 must be manually configured, scaled, and patched by your team. Compared to a managed L7 WAF ingress like Application Gateway, this significantly increases operational overhead and introduces more points of failure for security updates and routing rules.

Trap 3: Deploy an Azure API Management instance with WAF and expose the…

Azure API Management is a full API gateway platform designed for publishing, versioning, securing, and monetizing APIs, which is unrelated to the stated requirement of simply exposing internal microservices behind a WAF. If you add it, you are also forced to route traffic through an extra Application Gateway reverse proxy, creating a multi-hop chain that adds latency and cost without business value. For this scenario, a single Application Gateway v2 configured with AGIC directly fronting the AKS services gives you the needed WAF protection and ingress control with far less complexity.

A
Deploy an Azure Front Door with WAF policy in front of the AKS cluster. Use Azure Private Link to connect Front Door to the internal load balancer of AKS.
Why it fails: Azure Front Door is a global, anycast-based load-balancing service designed to route traffic across multiple regions. For a single-region AKS deployment, sending traffic through Front Door's edge network adds an unnecessary network hop and introduces latency, while Private Link endpoints to the AKS internal load balancer incur extra cost and configuration complexity. Application Gateway v2, by contrast, is a regional L7 solution that keeps traffic within the region and integrates directly with AKS.
B
Deploy an Azure Application Gateway v2 with WAF in front of the AKS cluster. Configure Application Gateway Ingress Controller (AGIC) to route traffic to the services.
Application Gateway v2 is a regional, autoscaling, Layer 7 load balancer with a managed WAF that includes OWASP rule sets, making it a strong fit for exposing AKS-based microservices. By deploying AGIC, the Kubernetes Ingress resources are automatically translated into Application Gateway routing rules, so no separate ingress controller pod is required. It provides SSL termination, path-based routing, and zone redundancy, all while being fully managed by Azure, which reduces operational burden compared to self-managed ingress.
C
Deploy an Azure Load Balancer with a public IP and install an NGINX ingress controller on AKS. Configure SSL termination on NGINX and use a third-party WAF.
Why it fails: This approach delegates TLS termination, request routing, and web application firewall duties to an NGINX ingress controller and an external third-party WAF running on self-managed infrastructure. The Azure Load Balancer only provides Layer 4 transport rules and does not understand HTTP paths or host headers, so everything above L4 must be manually configured, scaled, and patched by your team. Compared to a managed L7 WAF ingress like Application Gateway, this significantly increases operational overhead and introduces more points of failure for security updates and routing rules.
D
Deploy an Azure API Management instance with WAF and expose the microservices through API endpoints. Use Azure Application Gateway as a reverse proxy.
Why it fails: Azure API Management is a full API gateway platform designed for publishing, versioning, securing, and monetizing APIs, which is unrelated to the stated requirement of simply exposing internal microservices behind a WAF. If you add it, you are also forced to route traffic through an extra Application Gateway reverse proxy, creating a multi-hop chain that adds latency and cost without business value. For this scenario, a single Application Gateway v2 configured with AGIC directly fronting the AKS services gives you the needed WAF protection and ingress control with far less complexity.

Question 6mediummultiple choice

A company has two on-premises data centers and an Azure subscription. They need to connect each data center to Azure with a private, high-bandwidth, and reliable connection. They also want a low-cost backup connection for each data center in case the primary connection fails. Which combination of connectivity options should they recommend?

Trap 1: B

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.

Trap 2: C

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.

Trap 3: D

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.

A
A
This is the correct design because each data center establishes its own dedicated ExpressRoute circuit as the primary path, ensuring predictable, high-bandwidth, and low-latency connectivity to Azure with an SLA-backed private link. The site-to-site VPN for each data center acts as an IPsec-based backup over the internet, providing a cost-effective failover path that automatically kicks in if the ExpressRoute circuit fails. This active/passive redundancy model is a best practice for hybrid networking, as it avoids a single point of failure while keeping operational costs reasonable.
B
B
Why it fails: 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
C
Why it fails: 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
D
Why it fails: 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.

Question 7easymultiple choice

A company has multiple virtual networks in different Azure regions. They need to connect all VNets together securely over the Microsoft backbone. They also need to connect to an on-premises data center via ExpressRoute. The solution should support transitive routing between all connected networks. Which Azure service should they use?

Trap 1: Azure Virtual Network Peering

Azure VNet peering is a direct, non-transitive connection between two virtual networks. To connect multiple VNets across different regions, you would need to create a full mesh of peerings, which grows exponentially and becomes hard to manage. Additionally, peering alone does not provide transitive routing to a central hub or on-premises network, so it fails to offer the consolidated connectivity that a hub-and-spoke architecture like Virtual WAN delivers.

Trap 2: Azure VPN Gateway

Azure VPN Gateway can indeed connect VNets using IPsec tunnels, but this approach is cumbersome when many VNets are involved. Each VNet typically requires its own gateway, and inter-VNet transit via VPN gateways does not happen automatically; you must configure BGP routing explicitly and manage multiple S2S connections. This makes it operationally complex and less scalable than a managed service like Virtual WAN, which provides built-in transitive routing across all attached VNets.

Trap 3: Azure ExpressRoute Gateway

Azure ExpressRoute Gateway is designed to connect a single VNet to an ExpressRoute circuit for private, dedicated connectivity to on-premises or Microsoft services. It does not interconnect multiple VNets; each VNet must have its own ExpressRoute gateway, and traffic between those VNets cannot be transitively routed through the gateway or the ExpressRoute backbone. Therefore, using ExpressRoute Gateway alone would not satisfy the requirement of connecting multiple VNets across different regions.

A
Azure Virtual Network Peering
Why it fails: Azure VNet peering is a direct, non-transitive connection between two virtual networks. To connect multiple VNets across different regions, you would need to create a full mesh of peerings, which grows exponentially and becomes hard to manage. Additionally, peering alone does not provide transitive routing to a central hub or on-premises network, so it fails to offer the consolidated connectivity that a hub-and-spoke architecture like Virtual WAN delivers.
B
Azure VPN Gateway
Why it fails: Azure VPN Gateway can indeed connect VNets using IPsec tunnels, but this approach is cumbersome when many VNets are involved. Each VNet typically requires its own gateway, and inter-VNet transit via VPN gateways does not happen automatically; you must configure BGP routing explicitly and manage multiple S2S connections. This makes it operationally complex and less scalable than a managed service like Virtual WAN, which provides built-in transitive routing across all attached VNets.
C
Azure Virtual WAN
Azure Virtual WAN is the correct choice because it acts as a managed hub-and-spoke platform with automatic transitive routing between any connected VNets, regardless of region. Spoke VNets in different Azure regions can attach to the same Virtual WAN hub or to regional hubs, and traffic is routed over the Microsoft backbone with no need for manual peering or BGP. It also natively interconnects with VPN, ExpressRoute, and point-to-site gateways, making it the ideal centralized connectivity solution for multiple VNets.
D
Azure ExpressRoute Gateway
Why it fails: Azure ExpressRoute Gateway is designed to connect a single VNet to an ExpressRoute circuit for private, dedicated connectivity to on-premises or Microsoft services. It does not interconnect multiple VNets; each VNet must have its own ExpressRoute gateway, and traffic between those VNets cannot be transitively routed through the gateway or the ExpressRoute backbone. Therefore, using ExpressRoute Gateway alone would not satisfy the requirement of connecting multiple VNets across different regions.

Question 8easymultiple choice

A company is deploying a web application that must be accessible from the internet. The application is hosted on Azure virtual machines in a virtual network. The solution must provide SSL termination, web application firewall (WAF) protection, and URL path-based routing (e.g., /api/* to one backend pool, /app/* to another). The web tier must not be directly exposed to the internet. Which Azure load balancing solution should they use?

Trap 1: Azure Front Door

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.

Trap 2: Azure Load Balancer

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.

Trap 3: Azure Traffic Manager

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.

A
Azure Application Gateway v2
Azure Application Gateway v2 is a regional Layer 7 reverse proxy that performs SSL termination, web application firewall (WAF) inspection, and URL path-based or multi-site routing. It can be configured with a public front-end IP and a backend pool containing VMs with only private IPs, making it ideal for protecting an internet-facing web tier. The v2 SKU adds auto-scaling and zone redundancy, with the WAF policy enforcing OWASP rule sets at the HTTP edge.
B
Azure Front Door
Why it fails: 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.
C
Azure Load Balancer
Why it fails: 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.
D
Azure Traffic Manager
Why it fails: 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.

Question 9easymultiple choice

A company deploys a web application on Azure VMs across availability zones. They need to distribute HTTPS traffic, offload SSL termination, and maintain session persistence. They do not require traffic inspection. Which Azure load balancing solution should they use?

Trap 1: Azure Load Balancer (Standard).

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.

Trap 2: Azure Traffic Manager.

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.

Trap 3: Azure Front Door.

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.

A
Azure Application Gateway v2.
Azure Application Gateway v2 is the correct choice because it operates as a regional Layer 7 load balancer, directly supporting HTTPS termination, cookie-based session persistence (affinity), and HTTP health probes for backend VMs. Its v2 SKU is designed to span availability zones, enabling zone-redundant deployment across VM sets within a single region. Unlike global services, it stays in the region, minimizing latency while providing all required web-layer capabilities.
B
Azure Load Balancer (Standard).
Why it fails: 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.
C
Azure Traffic Manager.
Why it fails: 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.
D
Azure Front Door.
Why it fails: 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.

Question 10mediummultiple choice

A company has multiple on-premises sites and Azure VNets in different regions. They need to connect all networks with a single mesh topology, ensuring that any network can communicate with any other network directly. They also want to minimize administrative overhead. Which Azure service should they use?

Trap 1: Azure VPN Gateway

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.

Trap 2: Azure ExpressRoute

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.

Trap 3: Azure Peering Service

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.

A
Azure Virtual WAN
Azure Virtual WAN is the correct choice because it provides a cloud-native mesh connectivity solution built on a hub-and-spoke architecture with regional hubs. It automates the creation of any-to-any connections between branch offices, remote users, and VNets, with integrated routing that eliminates the need to manually configure individual VPN tunnels or peer each VNet. Virtual WAN uses the Microsoft backbone for transit, ensuring consistent low-latency routing across regions and on-premises sites, and supports both Site-to-Site VPN and ExpressRoute in a single managed topology.
B
Azure VPN Gateway
Why it fails: 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.
C
Azure ExpressRoute
Why it fails: 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.
D
Azure Peering Service
Why it fails: 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.

Question 11hardmultiple choice

You are a solutions architect for a financial services company. The company is deploying a new critical application on Azure that processes sensitive customer transactions. The application consists of an ASP.NET Core web app (Azure App Service), a REST API (Azure Kubernetes Service), and an Azure SQL Database. The requirements are:

- All data at rest must be encrypted using customer-managed keys (CMK) stored in a managed HSM. - All network traffic between components must be encrypted and traverse the Microsoft backbone network. - The web app must be protected against common web attacks (SQL injection, XSS). - The solution must automatically scale the API based on CPU utilization. - All API calls must be authenticated using OAuth 2.0 with Microsoft Entra ID. - Logs from all components must be sent to a central Log Analytics workspace for analysis. - The solution must have a recovery time objective (RTO) of 1 hour and recovery point objective (RPO) of 5 minutes for the database.

Which combination of Azure services should you recommend to meet ALL requirements?

Trap 1: Azure Front Door with WAF, Azure SQL Database point-in-time…

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.

Trap 2: Azure Front Door with WAF, Azure SQL Database geo-replication,…

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.

Trap 3: Azure Application Gateway with WAF, Azure SQL Database active…

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.

A
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 it fails: 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.
B
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 it fails: 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.
C
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 it fails: 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.
D
Azure Application Gateway with WAF, Azure SQL Database failover groups, Azure Key Vault Managed HSM, Azure App Service with service endpoint, AKS with HPA, Azure Monitor Agent, Microsoft Entra ID
Correct. Failover groups meet RPO and RTO, Managed HSM meets key storage, service endpoint keeps traffic on Microsoft backbone, AKS with HPA scales based on CPU, Application Gateway WAF protects against attacks, Azure Monitor Agent collects logs, and Microsoft Entra ID authenticates API calls.

Question 12mediummultiple choice

A company deploys a web application on multiple Azure VMs in a single region. They need to distribute incoming HTTP and HTTPS traffic across the VMs, offload SSL/TLS termination, and maintain session persistence (sticky sessions) so that all requests from a user session go to the same backend VM. Which Azure load balancing solution should they use?

Trap 1: Azure Load Balancer

Azure Load Balancer is incorrect because it is a Layer 4 (TCP/UDP) service, meaning it cannot inspect HTTP headers or route based on application URLs. It offers no SSL termination capability and only provides session persistence based on source IP hashing (5-tuple/2-tuple affinity), which is not cookie-based and can break when clients come from a shared NAT or proxy. Since the requirement demands HTTP-level SSL offload and cookie-based affinity, this option falls short.

Trap 2: Azure Traffic Manager

Azure Traffic Manager works at the DNS level by resolving the client's request to one of a set of globally distributed endpoints based on traffic-routing methods and health probes. As a result, it never sees the actual HTTP traffic, so it cannot terminate SSL or set HTTP session cookies. It is designed for multi-region, internet-facing failover and geographic routing, not for regional load balancing among VMs behind a single VNet.

Trap 3: Azure Front Door

Azure Front Door does indeed provide SSL termination, cookie-based session affinity, and Layer 7 routing, but it is a global, multi-region service that routes traffic over Microsoft's global edge network. It is not a regional load balancer and is not installed inside the VNet—clients share the edge entrypoint, which makes it unnecessary and cost-prohibitive for a single-region deployment. For a workload confined to one region with backends in one VNet, Application Gateway is the targeted and appropriate choice.

A
Azure Application Gateway
Azure Application Gateway is the best fit here because it operates at Layer 7 (HTTP/S) and can route traffic based on URL paths or host headers. More importantly, it performs SSL termination and enforces cookie-based session affinity, ensuring that a client's subsequent requests are consistently directed to the same backend VM. It also offers a Web Application Firewall and integrates tightly with VM scale sets in a regional VNet, making it ideal for a multi-VM web application in a single region.
B
Azure Load Balancer
Why it fails: Azure Load Balancer is incorrect because it is a Layer 4 (TCP/UDP) service, meaning it cannot inspect HTTP headers or route based on application URLs. It offers no SSL termination capability and only provides session persistence based on source IP hashing (5-tuple/2-tuple affinity), which is not cookie-based and can break when clients come from a shared NAT or proxy. Since the requirement demands HTTP-level SSL offload and cookie-based affinity, this option falls short.
C
Azure Traffic Manager
Why it fails: Azure Traffic Manager works at the DNS level by resolving the client's request to one of a set of globally distributed endpoints based on traffic-routing methods and health probes. As a result, it never sees the actual HTTP traffic, so it cannot terminate SSL or set HTTP session cookies. It is designed for multi-region, internet-facing failover and geographic routing, not for regional load balancing among VMs behind a single VNet.
D
Azure Front Door
Why it fails: Azure Front Door does indeed provide SSL termination, cookie-based session affinity, and Layer 7 routing, but it is a global, multi-region service that routes traffic over Microsoft's global edge network. It is not a regional load balancer and is not installed inside the VNet—clients share the edge entrypoint, which makes it unnecessary and cost-prohibitive for a single-region deployment. For a workload confined to one region with backends in one VNet, Application Gateway is the targeted and appropriate choice.

Question 13mediummultiple choice

A company deploys a containerized application on Azure Kubernetes Service (AKS). They need to expose the application to the internet and provide TLS termination. The solution must also include a Web Application Firewall (WAF) to protect against common attacks. Which Azure service should they use as the ingress controller?

Trap 1: Azure Front Door

Azure Front Door is a global, edge-based application delivery network that provides TLS termination, WAF, and HTTP/S acceleration, but it is not an AKS ingress controller and cannot be installed inside a cluster. Front Door routes traffic from the internet at the edge to a backend origin such as an Application Gateway, public IP, or AKS service, but it does not perform pod-level routing or integrate with AKS ingress resources. You would place Front Door in front of Application Gateway (or another origin) for global scaling, not as the ingress successor.

Trap 2: Azure Load Balancer

Azure Load Balancer is a Layer-4 (TCP/UDP) gateway that forwards IP packets to backend virtual machines or AKS nodes without inspecting the payload, so it cannot differentiate HTTP paths or hostnames. It does not support TLS termination because the connection is passed through unchanged, and it has no Web Application Firewall capability because it lacks HTTP-layer visibility. While an AKS service can use a Load Balancer to expose a workload, this option does not meet the TLS termination and WAF requirements.

Trap 3: Azure Traffic Manager

Azure Traffic Manager is a DNS-based traffic router that resolves client queries to regional endpoints but never proxies traffic between clients and your AKS workloads. Because it operates at the DNS layer only, it cannot see HTTP requests, terminate TLS, or apply Web Application Firewall rules, nor can it act as an AKS ingress controller. Traffic Manager simply points clients to the public IP of a service or another load balancer, making it unsuitable for HTTP-aware TLS termination or WAF.

A
Azure Application Gateway
Azure Application Gateway, when integrated as the Application Gateway Ingress Controller (AGIC), is the native Azure L7 load balancer that serves as an ingress gateway for AKS clusters. It terminates TLS connections at the gateway, decrypts HTTP traffic, and enforces Web Application Firewall policies (such as OWASP CRS rules) before forwarding requests to AKS pods. This makes it the correct solution for the requirement of TLS termination and WAF in an AKS environment.
B
Azure Front Door
Why it fails: Azure Front Door is a global, edge-based application delivery network that provides TLS termination, WAF, and HTTP/S acceleration, but it is not an AKS ingress controller and cannot be installed inside a cluster. Front Door routes traffic from the internet at the edge to a backend origin such as an Application Gateway, public IP, or AKS service, but it does not perform pod-level routing or integrate with AKS ingress resources. You would place Front Door in front of Application Gateway (or another origin) for global scaling, not as the ingress successor.
C
Azure Load Balancer
Why it fails: Azure Load Balancer is a Layer-4 (TCP/UDP) gateway that forwards IP packets to backend virtual machines or AKS nodes without inspecting the payload, so it cannot differentiate HTTP paths or hostnames. It does not support TLS termination because the connection is passed through unchanged, and it has no Web Application Firewall capability because it lacks HTTP-layer visibility. While an AKS service can use a Load Balancer to expose a workload, this option does not meet the TLS termination and WAF requirements.
D
Azure Traffic Manager
Why it fails: Azure Traffic Manager is a DNS-based traffic router that resolves client queries to regional endpoints but never proxies traffic between clients and your AKS workloads. Because it operates at the DNS layer only, it cannot see HTTP requests, terminate TLS, or apply Web Application Firewall rules, nor can it act as an AKS ingress controller. Traffic Manager simply points clients to the public IP of a service or another load balancer, making it unsuitable for HTTP-aware TLS termination or WAF.

Question 14mediummultiple choice

A company is deploying an internal web application on Azure VMs. The application requires SSL offloading, session stickiness, and URL-based routing (e.g., /api/* to one backend, /app/* to another). The solution must operate within a single Azure region and must not be exposed to the public internet. Which Azure load balancing solution should they use?

Trap 1: A

Azure Front Door is a global, edge-based Layer 7 load balancer that routes HTTP/S traffic across the internet using anycast and requires publicly resolvable endpoints. It cannot be deployed with a private VNet IP as its frontend; doing so would still expose the application to the public internet, which violates the internal-only deployment requirement. Its strength is multi-region and CDN scenarios, not a single-region internal workload.

Trap 2: B

Azure Traffic Manager is purely a DNS-based traffic router: it resolves a domain name to an endpoint IP but never inspects or forwards application traffic. Because it operates at the DNS layer, it cannot perform SSL offloading, cannot set cookie-based session affinity, and cannot make routing decisions on URL paths. Furthermore, the backend endpoints must have publicly accessible IP addresses or a public-facing endpoint, which contradicts the internal deployment model.

Trap 3: D

Azure Load Balancer is a Layer 4 (TCP/UDP) service that forwards traffic based on a five-tuple hash and never inspects application-layer payloads. It cannot route based on URL path segments, cannot offload SSL because it does not terminate TLS, and only provides source-IP-based distribution, not cookie-based or application-aware session affinity. Thus, it is unsuitable for a modern web application that needs advanced HTTP routing and offload.

A
A
Why it fails: Azure Front Door is a global, edge-based Layer 7 load balancer that routes HTTP/S traffic across the internet using anycast and requires publicly resolvable endpoints. It cannot be deployed with a private VNet IP as its frontend; doing so would still expose the application to the public internet, which violates the internal-only deployment requirement. Its strength is multi-region and CDN scenarios, not a single-region internal workload.
B
B
Why it fails: Azure Traffic Manager is purely a DNS-based traffic router: it resolves a domain name to an endpoint IP but never inspects or forwards application traffic. Because it operates at the DNS layer, it cannot perform SSL offloading, cannot set cookie-based session affinity, and cannot make routing decisions on URL paths. Furthermore, the backend endpoints must have publicly accessible IP addresses or a public-facing endpoint, which contradicts the internal deployment model.
C
C
Azure Application Gateway can be deployed as an internal (private) application gateway with a private frontend IP address inside the VNet, keeping the application fully internal. It offers native Layer 7 features including SSL termination (offloading), cookie-based session affinity, and URL path-based routing through listener and rule configurations. This makes it the only option that satisfies all three requirements—SSL offloading, session stickiness, and URL-based routing—within an internal network boundary.
D
D
Why it fails: Azure Load Balancer is a Layer 4 (TCP/UDP) service that forwards traffic based on a five-tuple hash and never inspects application-layer payloads. It cannot route based on URL path segments, cannot offload SSL because it does not terminate TLS, and only provides source-IP-based distribution, not cookie-based or application-aware session affinity. Thus, it is unsuitable for a modern web application that needs advanced HTTP routing and offload.

Question 15easymultiple choice

A company deploys a web application on Azure VMs within a single region. They need to distribute incoming HTTP traffic across multiple VMs, offload SSL encryption, and maintain session persistence (sticky sessions) for user sessions. Which Azure load balancing solution should they use?

Trap 1: Azure Load Balancer

Azure Load Balancer operates at Layer 4 of the OSI model, forwarding TCP/UDP traffic based on 5-tuple rules without inspecting HTTP payload. It cannot terminate TLS/SSL, so certificates remain on each VM, and its session persistence is limited to source IP affinity rather than HTTP cookie-based stickiness. This makes it unsuitable for an application that requires SSL offloading and cookie-based sticky sessions at the application layer.

Trap 2: Azure Traffic Manager

Azure Traffic Manager works at the DNS layer, directing clients to a service endpoint based on routing methods like performance or priority, but it does not intercept the actual HTTP traffic. Because it only returns a DNS response, it cannot inspect HTTP headers, offload SSL, or maintain session persistence; any TLS handshake and session logic must be handled by the destination service. It is also typically used across regions for global failover and traffic routing, not for distributing web traffic among VMs in a single region.

Trap 3: Azure Front Door

Azure Front Door is a global, anycast-based application delivery service that routes traffic through Microsoft's edge network to endpoints across regions, offering SSL offload and session affinity at a global scale. While it does support Layer 7 features, it is designed for accelerating and securing internet-facing global applications rather than for low-complexity distribution within a single region. Deploying it here would introduce unnecessary global routing and cost complexity, making Application Gateway the more appropriate single-region choice.

A
Azure Load Balancer
Why it fails: Azure Load Balancer operates at Layer 4 of the OSI model, forwarding TCP/UDP traffic based on 5-tuple rules without inspecting HTTP payload. It cannot terminate TLS/SSL, so certificates remain on each VM, and its session persistence is limited to source IP affinity rather than HTTP cookie-based stickiness. This makes it unsuitable for an application that requires SSL offloading and cookie-based sticky sessions at the application layer.
B
Azure Application Gateway
Azure Application Gateway is a Layer 7 reverse proxy that understands HTTP/S, enabling SSL termination at the gateway so VMs receive decrypted traffic and offload cryptographic overhead. It provides cookie-based session affinity (sticky sessions) using Application Gateway Affinity cookies, ensuring requests from the same user session reach the same VM. These capabilities map directly to the deployment's requirement for inbound web traffic distribution within a single region, making it the correct choice.
C
Azure Traffic Manager
Why it fails: Azure Traffic Manager works at the DNS layer, directing clients to a service endpoint based on routing methods like performance or priority, but it does not intercept the actual HTTP traffic. Because it only returns a DNS response, it cannot inspect HTTP headers, offload SSL, or maintain session persistence; any TLS handshake and session logic must be handled by the destination service. It is also typically used across regions for global failover and traffic routing, not for distributing web traffic among VMs in a single region.
D
Azure Front Door
Why it fails: Azure Front Door is a global, anycast-based application delivery service that routes traffic through Microsoft's edge network to endpoints across regions, offering SSL offload and session affinity at a global scale. While it does support Layer 7 features, it is designed for accelerating and securing internet-facing global applications rather than for low-complexity distribution within a single region. Deploying it here would introduce unnecessary global routing and cost complexity, making Application Gateway the more appropriate single-region choice.

Question 16mediummultiple choice

A company deploys a containerized microservices application on Azure Kubernetes Service (AKS). They need to expose the application to the internet with TLS termination and provide a single endpoint for multiple services. The solution must also include a Web Application Firewall (WAF). Which Azure service should they use as the ingress controller?

Trap 1: Azure Front Door with WAF

Azure Front Door provides global WAF, TLS termination, and a single endpoint, making it tempting for internet-facing applications. However, it operates as a global load balancer and CDN, not as an ingress controller that runs within an Azure Kubernetes Service (AKS) cluster. It cannot directly manage the internal HTTP/S routing rules to specific Kubernetes services based on ingress resources. Front Door would typically sit in front of an AKS cluster, requiring a separate ingress controller like Azure Application Gateway or NGINX within the cluster to handle the actual service routing.

Trap 2: Azure Load Balancer with TLS termination

Azure Load Balancer with TLS termination is incorrect because a standard Azure Load Balancer operates at Layer 4 (TCP/UDP) and forwards packets without inspecting HTTP messages. It cannot terminate TLS, as that requires decrypting HTTPS traffic at Layer 7, nor can it apply WAF rules or route requests based on URL paths or host headers. Its health probes merely check backend availability and are not a substitute for ingress-based routing to individual Kubernetes services.

Trap 3: Azure Traffic Manager with health probes

Azure Traffic Manager with health probes is incorrect because Traffic Manager works at the DNS level, not as an ingress controller for AKS. It resolves domain names to endpoints based on routing methods and health probes, but it cannot terminate TLS, inspect HTTP requests, or route to specific services or paths within a cluster. While it can distribute traffic across regions, it does not understand Kubernetes Ingress resources and therefore cannot replace Application Gateway or an NGINX-based ingress.

A
Azure Application Gateway with WAF
Azure Application Gateway with WAF is correct because the Application Gateway Ingress Controller (AGIC) runs inside AKS and watches Kubernetes Ingress resources, translating them into routing rules on the gateway. This allows TLS termination and WAF inspection at a single public endpoint, with L7 HTTP/S routing directly to the appropriate microservices. Unlike L4 or DNS-level services, it understands application paths, hostnames, and headers, making it a true ingress controller for AKS.
B
Azure Front Door with WAF
Why it fails: Azure Front Door provides global WAF, TLS termination, and a single endpoint, making it tempting for internet-facing applications. However, it operates as a global load balancer and CDN, not as an ingress controller that runs within an Azure Kubernetes Service (AKS) cluster. It cannot directly manage the internal HTTP/S routing rules to specific Kubernetes services based on ingress resources. Front Door would typically sit in front of an AKS cluster, requiring a separate ingress controller like Azure Application Gateway or NGINX within the cluster to handle the actual service routing.
C
Azure Load Balancer with TLS termination
Why it fails: Azure Load Balancer with TLS termination is incorrect because a standard Azure Load Balancer operates at Layer 4 (TCP/UDP) and forwards packets without inspecting HTTP messages. It cannot terminate TLS, as that requires decrypting HTTPS traffic at Layer 7, nor can it apply WAF rules or route requests based on URL paths or host headers. Its health probes merely check backend availability and are not a substitute for ingress-based routing to individual Kubernetes services.
D
Azure Traffic Manager with health probes
Why it fails: Azure Traffic Manager with health probes is incorrect because Traffic Manager works at the DNS level, not as an ingress controller for AKS. It resolves domain names to endpoints based on routing methods and health probes, but it cannot terminate TLS, inspect HTTP requests, or route to specific services or paths within a cluster. While it can distribute traffic across regions, it does not understand Kubernetes Ingress resources and therefore cannot replace Application Gateway or an NGINX-based ingress.

Question 17hardmultiple choice

A company is deploying a multi-tier web application on Azure. The web tier must be accessible from the internet. The application tier and database tier must be isolated within the virtual network and not directly accessible from the internet. The solution must provide SSL termination, URL-based routing, and Web Application Firewall (WAF) capabilities. Which Azure service should they use to expose the web tier?

Trap 1: Azure Load Balancer

Azure Load Balancer operates at Layer 4, forwarding traffic based on TCP/UDP source and destination IPs and ports without inspecting HTTP content. As a result, it cannot perform SSL termination, route based on URL paths, or offer a web application firewall, so it leaves critical web-tier protections unimplemented. Even when it is placed entirely inside the VNet, it lacks the application-layer intelligence needed to direct requests toward different backend services, making it an inadequate stand-in for a modern web tier load balancer.

Trap 2: Azure Traffic Manager

Azure Traffic Manager resolves DNS queries to select a public endpoint from among globally distributed endpoints, making it a DNS-level routing service rather than a network load balancer. It does not terminate TLS, inspect HTTP headers, or route requests to private VMs in a single region, so it cannot enforce application-layer rules or contribute to isolating the web tier. For a multi-tier application hosted in one region, it introduces unnecessary global complexity without providing any layer-7 functionality and would not replace the security and routing capabilities of Application Gateway.

Trap 3: Azure Front Door

While Azure Front Door offers SSL termination, URL-based routing, and WAF, it does not inherently provide the necessary network isolation for the application and database tiers. It's tempting because it excels at global traffic management and security for web applications, making it ideal for scenarios requiring a single global entry point with advanced routing and protection, but it doesn't fulfil the requirement of isolating backend tiers within a private virtual network.

A
Azure Application Gateway
Azure Application Gateway is the correct choice because it operates at Layer 7, enabling SSL termination, URL path-based routing, and integrated WAF to filter malicious traffic. It can be deployed in a dedicated subnet within the same VNet as the web and database tiers, allowing it to forward requests to a backend pool via private IP addresses while the database tier remains isolated behind NSGs. This combination of HTTP-level routing, security, and VNet integration satisfies the multi-tier isolation requirement.
B
Azure Load Balancer
Why it fails: Azure Load Balancer operates at Layer 4, forwarding traffic based on TCP/UDP source and destination IPs and ports without inspecting HTTP content. As a result, it cannot perform SSL termination, route based on URL paths, or offer a web application firewall, so it leaves critical web-tier protections unimplemented. Even when it is placed entirely inside the VNet, it lacks the application-layer intelligence needed to direct requests toward different backend services, making it an inadequate stand-in for a modern web tier load balancer.
C
Azure Traffic Manager
Why it fails: Azure Traffic Manager resolves DNS queries to select a public endpoint from among globally distributed endpoints, making it a DNS-level routing service rather than a network load balancer. It does not terminate TLS, inspect HTTP headers, or route requests to private VMs in a single region, so it cannot enforce application-layer rules or contribute to isolating the web tier. For a multi-tier application hosted in one region, it introduces unnecessary global complexity without providing any layer-7 functionality and would not replace the security and routing capabilities of Application Gateway.
D
Azure Front Door
Why it fails: While Azure Front Door offers SSL termination, URL-based routing, and WAF, it does not inherently provide the necessary network isolation for the application and database tiers. It's tempting because it excels at global traffic management and security for web applications, making it ideal for scenarios requiring a single global entry point with advanced routing and protection, but it doesn't fulfil the requirement of isolating backend tiers within a private virtual network.

Question 18easymultiple choice

A company deploys a web application on multiple Azure VMs within an availability set. They need to distribute incoming HTTP traffic evenly across the VMs and provide health probe monitoring. The solution must support SSL termination and source IP affinity (session persistence). Which Azure load balancing solution should they choose?

Trap 1: Azure Load Balancer (Basic)

Azure Load Balancer (Basic) is a layer-4 (transport) distributor that forwards TCP/UDP traffic without inspecting application payloads, so it cannot terminate SSL/TLS or make routing decisions based on HTTP headers or cookies. While it can provide basic source-IP session persistence, it lacks cookie-based affinity for web applications, has no SLA, and offers no health probe customization, making it inadequate for this scenario.

Trap 2: Azure Load Balancer (Standard)

Azure Load Balancer (Standard) also operates at layer-4, preserving encrypted traffic as opaque bytes and leaving SSL/TLS termination to the backend VMs. It improves on Basic with availability zones, richer health probes, and outbound SNAT, but its session persistence is still limited to source-IP hashing rather than application-layer cookies. Because it cannot decrypt HTTP traffic or inspect application headers, it fails to meet the SSL termination and cookie-based stickiness requirements.

Trap 3: Azure Traffic Manager

Azure Traffic Manager is a DNS-level traffic router that directs requests to global endpoints using methods like performance, priority, or weighted round-robin, but it never sits in the user-to-backend data path. It cannot see HTTP payloads, terminate SSL/TLS, or maintain local session affinity, because once DNS answers, the client connects directly to the endpoint. Its purpose is global failover and geographic distribution, not L7 load balancing among VMs within the same region or VNet, so it is unsuitable here.

A
Azure Load Balancer (Basic)
Why it fails: Azure Load Balancer (Basic) is a layer-4 (transport) distributor that forwards TCP/UDP traffic without inspecting application payloads, so it cannot terminate SSL/TLS or make routing decisions based on HTTP headers or cookies. While it can provide basic source-IP session persistence, it lacks cookie-based affinity for web applications, has no SLA, and offers no health probe customization, making it inadequate for this scenario.
B
Azure Load Balancer (Standard)
Why it fails: Azure Load Balancer (Standard) also operates at layer-4, preserving encrypted traffic as opaque bytes and leaving SSL/TLS termination to the backend VMs. It improves on Basic with availability zones, richer health probes, and outbound SNAT, but its session persistence is still limited to source-IP hashing rather than application-layer cookies. Because it cannot decrypt HTTP traffic or inspect application headers, it fails to meet the SSL termination and cookie-based stickiness requirements.
C
Azure Application Gateway v2
Azure Application Gateway v2 is a regional layer-7 reverse proxy that terminates SSL/TLS at the gateway, offloading decryption from the backend VMs, and can optionally re-encrypt traffic to the origin pool. It provides cookie-based session affinity (ARRAffinity), configurable health probes, and URL/path-based routing, directly matching the need for SSL termination and persistent user sessions across multiple VMs. Its static VIPs and WebSocket support further solidify it as the correct L7 load-balancing choice in Azure.
D
Azure Traffic Manager
Why it fails: Azure Traffic Manager is a DNS-level traffic router that directs requests to global endpoints using methods like performance, priority, or weighted round-robin, but it never sits in the user-to-backend data path. It cannot see HTTP payloads, terminate SSL/TLS, or maintain local session affinity, because once DNS answers, the client connects directly to the endpoint. Its purpose is global failover and geographic distribution, not L7 load balancing among VMs within the same region or VNet, so it is unsuitable here.

Question 19easymultiple choice

You need to design a networking solution for a multi-tier application that includes a web front-end, an API layer, and a database. The web and API tiers must be accessible from the internet, while the database tier must be isolated. What is the most secure and efficient design?

Trap 1: Place all VMs in the same subnet and use a single Azure Load…

This design eliminates any network segmentation between application and database tiers, so an attacker who compromises the web tier can directly reach backend databases on open ports, and a single public-facing load balancer exposes all VMs to the internet, including the data tier. An Azure Load Balancer (L4) only performs TCP/UDP distribution; it cannot provide layer-7 filtering, URL routing, or web application firewall protection, and it gives no mechanism to restrict traffic between tiers within the same subnet.

Trap 2: Use separate VNets for each tier and connect them with VNet peering.

Creating a separate VNet for each tier and interconnecting them with VNet peering introduces unnecessary overhead: peering is non-transitive, so you must manage multiple peering connections and complex network security groups across VNets, and you cannot leverage a single Azure Application Gateway in front of all tiers without additional hub infrastructure. Subnets inside one VNet already provide isolation with full control via NSGs and allow an application gateway to sit in the same VNet, giving the same security benefit at far lower complexity and cost.

Trap 3: Deploy all VMs in a single subnet and use Azure Firewall to inspect…

Placing every VM in a single subnet collapses compartmentalization and forces Azure Firewall to act as a central inspection point for all traffic if you add complex user-defined routes; however, Azure Firewall is a managed stateful network firewall, not a substitute for subnet isolation, so you lose the ability to apply different NSG policies per tier and you incur significant cost for features that could be handled by simpler subnet-level NSGs. Furthermore, Azure Firewall does not provide web application firewall capabilities, so you still need an Application Gateway or other WAF device, making this design both expensive and architecturally flawed.

A
Place all VMs in the same subnet and use a single Azure Load Balancer to distribute traffic.
Why it fails: This design eliminates any network segmentation between application and database tiers, so an attacker who compromises the web tier can directly reach backend databases on open ports, and a single public-facing load balancer exposes all VMs to the internet, including the data tier. An Azure Load Balancer (L4) only performs TCP/UDP distribution; it cannot provide layer-7 filtering, URL routing, or web application firewall protection, and it gives no mechanism to restrict traffic between tiers within the same subnet.
B
Use separate VNets for each tier and connect them with VNet peering.
Why it fails: Creating a separate VNet for each tier and interconnecting them with VNet peering introduces unnecessary overhead: peering is non-transitive, so you must manage multiple peering connections and complex network security groups across VNets, and you cannot leverage a single Azure Application Gateway in front of all tiers without additional hub infrastructure. Subnets inside one VNet already provide isolation with full control via NSGs and allow an application gateway to sit in the same VNet, giving the same security benefit at far lower complexity and cost.
C
Deploy all VMs in a single subnet and use Azure Firewall to inspect all inbound and outbound traffic.
Why it fails: Placing every VM in a single subnet collapses compartmentalization and forces Azure Firewall to act as a central inspection point for all traffic if you add complex user-defined routes; however, Azure Firewall is a managed stateful network firewall, not a substitute for subnet isolation, so you lose the ability to apply different NSG policies per tier and you incur significant cost for features that could be handled by simpler subnet-level NSGs. Furthermore, Azure Firewall does not provide web application firewall capabilities, so you still need an Application Gateway or other WAF device, making this design both expensive and architecturally flawed.
D
Deploy all tiers in the same VNet with separate subnets, and use NSGs to restrict traffic. Place an Azure Application Gateway with WAF in front of the web tier.
This architecture separates each application tier into its own subnet and applies per-subnet NSG rules to allow only required communication (e.g., web-to-app on port 443, app-to-data on port 3306), ensuring that a compromise in one tier does not implicitly expose another. An Azure Application Gateway with its WAF sits in a dedicated gateway subnet, providing the single internet-facing HTTPS endpoint, SSL offload, cookie-based session affinity, path-based routing, and OWASP Top-10 protection—all before traffic reaches the web tier. This is the recommended pattern because it balances security and operational simplicity.

Question 20hardmultiple choice

A company deploys a multi-tier web application on Azure VMs across availability zones. The web tier must have SSL termination, session persistence, and health probe monitoring. Additionally, all traffic must be inspected by a central firewall for compliance. The solution must be highly available. Which combination of Azure services should they implement?

Trap 1: Azure Load Balancer (Standard) in front of web VMs, with a…

Azure Load Balancer (Standard) is an L4 load balancer that only routes traffic based on IP/port and performs no TLS termination, application-aware routing, or cookie-based session persistence. A third-party NVA for inspection would need to be deployed inline, requiring custom routing, manual scaling, and additional licensing/ops overhead; it also often becomes a single point of failure unless you build your own HA cluster. This option lacks the integrated WAF and tightly managed inspection capabilities that Azure-native services provide, making it less suitable for a secure, multi-tier web application.

Trap 2: Azure Front Door in front of web VMs, with Azure Firewall for…

Azure Front Door is a global, anycast-based L7 load balancer that excels at CDN, SSL acceleration, and DDoS/WAF at the edge. However, its traffic path bypasses a VNet—requests go from the edge to the backend directly, so Azure Firewall placed in a hub VNet cannot inspect those connecting flows unless you force traffic through the hub with explicitly configured routes. Since Front Door operates outside the VNet boundary, it does not route traffic through a central firewall, meaning internal inspection and east-west filtering are absent. It is best for global distribution and edge WAF, not for centralized VNet-based inspection.

Trap 3: Azure Traffic Manager + Azure Application Gateway

Traffic Manager is a DNS-based routing service that only resolves the client to an endpoint based on priority/performance/geographic rules; it does not inspect, protect, or modify the traffic itself. Adding Application Gateway, while good for L7 load balancing and WAF, still leaves the design without a central firewall to inspect traffic crossing VNet boundaries. The combination also introduces two layers of DNS/load-balance redirection without any security inspection at the network layer, so it would not meet a requirement for central inspection. This option conflates availability routing with security, and is therefore incomplete for the stated need.

A
Azure Application Gateway (WAF) in front of web VMs, with Azure Firewall in a hub VNet for central inspection
Application Gateway (WAF) is an L7 load balancer that terminates TLS, provides web application firewall rules (SQL injection, XSS), and supports cookie-based session affinity at the HTTP layer. By placing it in front of the web VMs, you get protocol-aware routing and protection. Azure Firewall in a hub VNet then serves as the centralized inspection point for all east-west and outbound traffic via UDR or forced tunneling, enabling consistent security policy enforcement without separate L4/L7 devices. This hub-spoke design is the industry-standard pattern for multi-tier web workloads.
B
Azure Load Balancer (Standard) in front of web VMs, with a third-party Network Virtual Appliance (NVA) for inspection
Why it fails: Azure Load Balancer (Standard) is an L4 load balancer that only routes traffic based on IP/port and performs no TLS termination, application-aware routing, or cookie-based session persistence. A third-party NVA for inspection would need to be deployed inline, requiring custom routing, manual scaling, and additional licensing/ops overhead; it also often becomes a single point of failure unless you build your own HA cluster. This option lacks the integrated WAF and tightly managed inspection capabilities that Azure-native services provide, making it less suitable for a secure, multi-tier web application.
C
Azure Front Door in front of web VMs, with Azure Firewall for inspection
Why it fails: Azure Front Door is a global, anycast-based L7 load balancer that excels at CDN, SSL acceleration, and DDoS/WAF at the edge. However, its traffic path bypasses a VNet—requests go from the edge to the backend directly, so Azure Firewall placed in a hub VNet cannot inspect those connecting flows unless you force traffic through the hub with explicitly configured routes. Since Front Door operates outside the VNet boundary, it does not route traffic through a central firewall, meaning internal inspection and east-west filtering are absent. It is best for global distribution and edge WAF, not for centralized VNet-based inspection.
D
Azure Traffic Manager + Azure Application Gateway
Why it fails: Traffic Manager is a DNS-based routing service that only resolves the client to an endpoint based on priority/performance/geographic rules; it does not inspect, protect, or modify the traffic itself. Adding Application Gateway, while good for L7 load balancing and WAF, still leaves the design without a central firewall to inspect traffic crossing VNet boundaries. The combination also introduces two layers of DNS/load-balance redirection without any security inspection at the network layer, so it would not meet a requirement for central inspection. This option conflates availability routing with security, and is therefore incomplete for the stated need.