High Availability practice questions

Azure Blob Storage Premium tier with geo-redundant storage (GRS)

Why it fails: Azure Blob Storage Premium is object-based storage, not a file share; it does not expose SMB protocol, which is typically needed for concurrent file-level access by media production applications. While geo-redundant storage (GRS) provides asynchronous replication to a secondary region for disaster recovery, it does not compensate for the lack of SMB support or the NFS limitations that preclude use as a drop-in share for legacy workflows. For industrial media creation, users expect access to drive-letter-mapped or UNC paths, which Blob Storage cannot natively deliver.

Azure Disk Storage with shared disks

Why it fails: Azure managed disks are block-level volumes attached to a single virtual machine; shared disks allow a modest number of VMs to attach the same disk using SCSI persistent reservations, but offer none of the file-level operations (SMB/NFS, directory enumeration, opportunistic locking) that a real file share requires. This design supports clustered applications like SQL Server failover cluster installations, not multi-user media editing where hundreds of users need a common namespace and per-file locking. As a storage solution for large media files, shared disks impose tight VM coupling and fail to provide a dedicated, network-accessible shared file system.

Azure NetApp Files Premium tier with cross-zone replication

Why it fails: Azure NetApp Files Premium tier is a powerful, enterprise-grade, multi-protocol file service with cross-zone replication, giving excellent performance and disaster resilience, but it is significantly more expensive and operationally complex than Azure Files Premium for this scenario. NetApp Files introduces capacity pools with a minimum 4 TiB commitment, professional administration of throughput, and more moving parts, while cross-zone replication adds continuous replication overhead. For a media company that simply needs a low-latency, SMB-accessible share with zone-level redundancy, Azure Files Premium ZRS delivers the same essential capabilities at a fraction of the cost and complexity.

Implement Azure DNS Private Resolver for resolution

Why it fails: Azure DNS Private Resolver provides recursive resolution and conditional forwarding for private DNS zones between on-premises and Azure virtual networks, but it is not a data-plane network connectivity service. It neither carries application traffic nor provides link failover or bandwidth; even if DNS queries resolve correctly, an outage on the underlying IP connectivity path will still prevent access to workloads. Choosing this option would address name resolution, not the required hybrid connectivity redundancy.

Use a single VPN gateway with active-standby mode

Why it fails: A single VPN gateway in active-standby mode is insufficient when the goal is overall hybrid network resilience because the gateway resource is still reliant on one underlying gateway site and one public IP, and it does not provide an independent network path for failover. The standby instance inside the same gateway only protects against an OS fault or instance maintenance, not against a regional Azure outage, an internet provider outage, or a loss of the site-to-site VPN connection. To achieve redundancy, you need either multiple gateway deployments or a second independent connection such as a second ExpressRoute circuit.

Use a single ExpressRoute circuit with a VPN gateway as failover

Why it fails: A single ExpressRoute circuit backed by a VPN gateway gives you a fallback path, but it is not as redundant as two ExpressRoute circuits because the sole circuit remains a single point of failure in the private interconnect. If the circuit experiences a fiber cut, connectivity-provider maintenance, or BGP peering loss, failover to the VPN tunnel depends on IPsec convergence and is usually constrained by the VPN Gateway's throughput, which is often lower than ExpressRoute. Meeting a strict enterprise SLA generally requires two diverse ExpressRoute circuits, not one circuit plus a best-effort VPN.

Azure App Service with autoscale rules and deployment slots

Why it fails: Azure App Service is a platform-as-a-service offering that abstracts and manages the underlying VMs on your behalf; even though it supports autoscale rules and deployment slots, you are never selecting or patching the virtual machines yourself, which violates the explicit "on Azure virtual machines" constraint in the requirement. The autoscaling in App Service scales the number of worker instances running on a shared or dedicated App Service plan, not VM scale sets, and deployment slots address staging and swap rather than compute capacity. Because the prerequisites demand IaaS-level VM control, App Service is disqualified despite its operational convenience.

Azure Load Balancer with a backend pool of VMs and autoscale rules applied to individual VMSS

Why it fails: An Azure Load Balancer is a Layer-4 load balancer that distributes traffic to a backend pool, but it has no autoscale engine of its own; any scaling rules must be created on the VMSS (or a separate autoscale setting), so this option merely describes an architectural fragment rather than a complete solution. If the backend pool is simply a loose list of standalone VMs, you cannot apply CPU-based autoscale to them at all, because autoscale in Azure is attached to a scale set. Even with a VMSS behind the load balancer, the option does not state that the scale set is distributed across availability zones, so it fails part of the high-availability requirement.

Azure Traffic Manager with endpoints in separate regions and Manual scaling of VMs

Why it fails: Azure Traffic Manager is a DNS-based global traffic router used to steer users to endpoints in different Azure regions; it does not monitor CPU utilization of your VMs and cannot automatically add or remove VM instances based on load. The requirement is for automatic scaling based on CPU and protection against a zone failure within a region, and manually scaling VMs directly contradicts "automatic". Spreading endpoints across regions can protect against a regional outage if you replicate the app, but that is not the same as zone-level high availability, and the lack of autoscale makes this option invalid.

Deploy the application on Azure Kubernetes Service (AKS) and use Azure Database for PostgreSQL.

Why it fails: AKS supplies a resilient Kubernetes control plane, but it imposes ongoing cluster lifecycle duties on the development team: managing node pools, patching the OS and kubelet, configuring ingress controllers, monitoring resource quotas, and upgrading Kubernetes versions. Even though Azure Database for PostgreSQL reduces database admin, the containerized app still must be built, configured, and operated as a workload on the cluster, which substantially exceeds the management overhead of a single App Service instance. This trade-off only pays off for larger microservice teams and custom infrastructure requirements, not for a startup's straightforward web application.

Deploy the application as Azure Functions and use Azure Cosmos DB for storage.

Why it fails: Azure Functions is a serverless compute platform optimized for event-driven triggers and transient execution, with a maximum execution timeout and cold-start latency that make it unsuitable for consistent, stateful web request serving to users. Cosmos DB is a NoSQL, multi-model database, not a relational PostgreSQL source, so any existing SQL schema, joins, transactions, or object-relational mapping would require substantial redesign. The combination fails both the compute model and the relational storage expectations of a typical web application.

Deploy the application on Azure Virtual Machines and use PostgreSQL on the same VM.

Why it fails: Deploying on Azure Virtual Machines creates an IaaS footprint where the startup is solely responsible for patching the guest OS, installing PostgreSQL, managing backups and high availability, storing database files, and handling scaling via VM resizing or replicated endpoints. Additionally, hosting the web app and database on the same VM couples compute and storage on one hardware boundary, creating a single point of failure and making it impossible to independently scale either tier. This operational burden directly contradicts the requirement to minimize management overhead.

Availability Zone

Why it fails: Availability Zones are physically separate datacenters within an Azure region, each with independent power, cooling, and networking. Deploying VMs across zones protects against a complete datacenter failure and provides a higher 99.99% SLA, but it does not serve the requirement of grouping VMs within a single datacenter across fault and update domains. Using zones would also introduce cross-zone network latency and is more expensive than an Availability Set, making it the wrong choice for this scenario.

Virtual Machine Scale Set with manual scaling

Why it fails: A Virtual Machine Scale Set is designed for running a large number of identical VMs that can be automatically scaled in or out based on demand, not for general-purpose grouping of heterogeneous VMs for high availability. Even when scaling is set to manual, the scale set still treats instances as a uniform pool and does not provide the same fault-domain and update-domain placement guarantees as an Availability Set unless it is explicitly configured with availability zones or an availability set. For this question, the requirement is simply grouping VMs for HA, not elastic scaling, so a scale set with manual scaling is an inappropriate and overcomplicated choice.

Azure Site Recovery

Why it fails: Azure Site Recovery is a disaster recovery service that replicates Azure VMs or on-premises machines to a secondary Azure region, enabling failover in the event of a catastrophic regional outage. It is entirely focused on recovery after a disaster, not on the initial high-availability placement of VMs within a single region or datacenter. Site Recovery introduces replication overhead and recovery time objectives, whereas the requirement here is for continuous availability during local hardware or maintenance events, which is exactly what an Availability Set provides.

Hot tier

Why it fails: Hot tier is designed for frequently accessed data and carries the highest per-GB storage price, with no early-deletion penalty but premium capacity costs. Since the video files are touched only once each month, you would be provisioning high-cost storage for long idle periods, making it economically unjustified. The access latency is identical to Cool tier, so you gain no operational benefit that compensates for the extra storage expense.

Cold tier

Why it fails: Cold tier lowers the base storage cost but imposes a higher per-GB retrieval fee and a mandatory 90-day retention period, which does not match a 30-day access cadence. Over the course of a year, the cumulative retrieval charges for twelve monthly reads can quickly erase the storage savings relative to Cool tier. Additionally, the 90-day minimum means you would either pay early-deletion fees or keep data longer than the business needs, further increasing cost.

Archive tier

Why it fails: Archive tier is the least expensive for static data, but it stores blobs in an offline state that requires manual rehydration to a readable tier, a process that can take up to 15 hours. For a media company that must access a video every month, this delay is operationally unacceptable, and rehydration also incurs additional read and write costs. Even if you schedule the rehydration in advance, the complexity and unpredictability make Archive unsuitable for a predictable 30-day access pattern.

Azure Traffic Manager

Why it fails: Traffic Manager is a DNS-based traffic router that only resolves domain names to endpoint IPs at the DNS level. It cannot terminate SSL, inspect HTTP content, or apply WAF rules, and it lacks URL path-based routing because it never sees the actual traffic. While it can route users globally, it cannot make application-layer decisions or protect the application, so it does not meet the full requirements.

Azure Application Gateway

Why it fails: Application Gateway is a regional Layer 7 load balancer that provides SSL offloading, WAF, and URL path-based routing, but its scope is limited to a single Azure region. It can route traffic among backends within that region but cannot distribute or intelligently route users across multiple geographic regions. For global e-commerce scale and redundancy, you need a multi-region front-end, which Application Gateway alone cannot provide.

Azure Load Balancer

Why it fails: Azure Load Balancer is a Layer 4 network load balancer that forwards TCP/UDP traffic without any awareness of HTTP content. It does not perform SSL termination, cannot inspect URLs for path-based routing, and does not integrate a WAF. Additionally, it is a regional service, so it lacks the global anycast-based edge routing that Front Door offers for worldwide traffic distribution.

Azure Traffic Manager

Why it fails: Azure Traffic Manager operates strictly at the DNS layer, resolving public domain names to endpoints and directing clients based on routing methods such as performance, priority, or geographic proximity. Because it never sees the actual HTTP/S traffic, it cannot provide TLS termination, web application firewall (WAF) inspection, path-based routing, or content caching at the edge. For a web application that requires SSL offloading and WAF protection, Traffic Manager is only a DNS-level traffic distribution mechanism and lacks the layer 7 security and acceleration features needed.

Azure Application Gateway

Why it fails: Azure Application Gateway is a regional-only layer 7 load balancer, meaning it can handle TLS termination, WAF rules, and path/URL routing, but only for backends within a single Azure region or availability zone. It is not a global service, so a multi-region deployment would need one Application Gateway per region and still require a separate DNS-level mechanism or another global router to steer users to the correct regional gateway. While it offers similar security features to Front Door, it lacks the built-in global edge caching, anycast networking, and cross-region health-based routing that a worldwide e-commerce platform demands.

Azure Content Delivery Network (CDN)

Why it fails: Azure CDN is optimized primarily for caching and delivering static content from edge locations to reduce latency and origin load, but it does not function as a layer 7 load balancer with real-time backend health awareness. A standard Azure CDN profile does not natively provide web application firewall (WAF) inspection for every request, nor does it perform per-request routing decisions to the nearest healthy origin based on continuous health probes in the way Front Door does. Although it can improve delivery of images and video, it cannot address the need for SSL offloading to origins, WAF protection, and intelligent failover routing across multiple regions.

Long-term retention (LTR) backups

Why it fails: Long-term retention (LTR) backups are not a high-availability feature because they simply store full database backups for up to 10 years to satisfy compliance or archival requirements. These backups are kept in the same region or a paired region, but they are static copies that require a manual restore operation to be used. LTR does not create live replicas, offer automatic failover, or contribute to continuous service availability. Thus, while it improves recoverability, it does not keep the database accessible during an outage, making it incorrect.

Automatic tuning

Why it fails: Automatic tuning relies on artificial intelligence and machine learning to continuously analyze query performance, and then it automatically creates or drops indexes, and adjusts query plan choices. It operates on the logical query execution side, not on the physical infrastructure, so it has no effect on data redundancy, replication, or failover mechanisms. This feature is primarily a performance optimization capability, and it does not provide any form of high availability. Therefore, it is an incorrect answer for a high availability question.

Transparent Data Encryption (TDE)

Why it fails: Transparent Data Encryption (TDE) is not a high-availability feature because it encrypts data and log files at rest using a symmetric encryption key, preventing unauthorized access to the physical files. TDE does not create any replicas, does not provide failover, and does not affect how the database is served to clients. Its purpose is data protection at the storage layer, not ensuring continuous operation or redundancy. So it is incorrect for this question about high availability.

Use Azure Files with zone-redundant storage (ZRS) and SMB multi-channel.

Why it fails: Azure Files is a distinct managed file offering, not a substitute for Azure NetApp Files (ANF). While ZRS on Azure Files replicates data synchronously across availability zones, SMB multi-channel is only a performance feature that improves throughput by using multiple SMB connections, it does nothing for availability. This option fails the stated requirement to use ANF and ignores that ANF itself does not support zone-redundant storage; it would require re-architecting to a different file protocol and feature set.

Use Azure Backup for ANF with daily snapshots stored in a different zone.

Why it fails: Azure Backup for ANF takes point-in-time snapshots and stores recovery points, but a backup is not an active replica: it has to be restored to a new volume before application traffic can resume, which yields a high RTO. Daily snapshots also create a maximum data loss window of up to 24 hours, which is generally unacceptable for high availability. Storing the backup in a different zone only protects the backup artifacts themselves; it never provides automatic failover, continuous replication, or instant read access from a secondary zone.

Deploy the application in an Availability Set and use ANF volumes with zone-redundant storage (ZRS).

Why it fails: An Availability Set spreads VMs across fault domains and update domains within a single availability zone, so it protects only against rack-level or maintenance events, not a full availability zone outage. Additionally, Azure NetApp Files does not support zone-redundant storage (ZRS); ANF volumes are provisioned in a single availability zone and use locally redundant storage (LRS) by default. Pairing an Availability Set with an unbacked ANF volume still leaves the file data vulnerable, so this combination does not deliver zonal high availability.

Use Azure Traffic Manager to route traffic to the primary region.

Why it fails: Azure Traffic Manager routes traffic by publishing DNS responses that resolve to the IP addresses of the primary region’s AKS endpoint; when it detects a failure, it changes DNS responses, but the actual failover time is governed by DNS TTLs and client DNS caching, which can take minutes and is not guaranteed. It also performs endpoint health checks only at the level of a monitored endpoint (typically the domain/IP), not by probing application-specific HTTP behavior or AKS ingress health. This makes it less suitable than Azure Front Door for fast, application-aware failover of Kubernetes workloads.

Use Azure SQL Database with failover groups for the database tier.

Why it fails: Azure SQL Database failover groups use an active-passive model in which only the primary database accepts writes, while the secondary database is a readable but non-writable replica located in another region. In an unplanned outage, the failover group must promote the secondary, and because replication is asynchronous, any transactions committed to the old primary but not yet replicated can be lost, violating strict RPO or zero-data-loss goals. This is why a failover group cannot replace an active-active database like Cosmos DB with multiple write regions in a global multi-region write scenario.

Azure Application Gateway v2.

Why it fails: Azure Application Gateway v2 is a Layer 7 load balancer featuring SSL termination, URL path-based routing, and cookie-based session affinity. Those capabilities are extraneous for a stateless HTTP workload that simply needs to distribute raw TCP connections across VMs. It also adds operational complexity and higher per-hour cost than a Standard Load Balancer because it runs a dedicated gateway tier. Therefore it is not the recommended regional HA solution here.

Azure Traffic Manager.

Why it fails: Azure Traffic Manager is a DNS-based traffic router that maps domain names to endpoints across different Azure regions, such as scale sets or regional load balancers. It decides which endpoint receives traffic based on DNS resolution using routing methods like priority or performance, but it does not load-balance individual TCP/HTTP connections within a region. Its health checks are coarse endpoint-level probes, not VM-level or port-level monitoring, and it cannot replace a regional load balancer to keep VMs available within one region.

Azure Front Door.

Why it fails: Azure Front Door is a global HTTP(S) delivery and protection service that accelerates requests through Microsoft's edge network by routing to the closest healthy origin. It operates at the DNS/anycast level with features like caching, SSL offload, and WAF policies, all of which are excessive for a single-region stateless web app. Equally important, it does not perform L4 load balancing inside a region; it expects an origin load balancer to handle that. For a deployment that only needs regional high availability, Front Door adds extra latency and cost without tangible benefit.

Use Azure ExpressRoute as the primary connection, and configure VNet-to-VNet VPN as a backup for ExpressRoute.

Why it fails: A VNet-to-VNet VPN creates an encrypted tunnel between two Azure virtual networks, not between on-premises and Azure. Since ExpressRoute's role is to provide a private connection from the on-premises network, its failover path must also originate on-premises; a site-to-site VPN over the internet is the correct redundant path. VNet-to-VNet connectivity is irrelevant to ExpressRoute backup because it doesn't involve the on-premises gateway.

Use Azure VPN Gateway to connect the on-premises network to Azure, and use VNet peering for VNet-to-VNet connectivity.

Why it fails: Relying solely on an Azure VPN Gateway connects on-premises over the public internet via IPsec, which introduces higher latency and variable performance compared to ExpressRoute. While VNet peering is indeed the correct method for VNet-to-VNet traffic, this design omits the private, high-bandwidth ExpressRoute circuit that enterprise architectures typically require as the primary path. Without ExpressRoute, there is no redundant private connection, and the VPN becomes a single point of failure for hybrid connectivity.

Use Azure ExpressRoute as the primary connection, and use Azure Firewall to inspect traffic between VNets.

Why it fails: Azure Firewall is a managed, cloud-native network security service that filters and inspects traffic between VNets and to the internet, but it has no role in establishing WAN connectivity. It cannot carry IPsec tunnels or route traffic from an on-premises datacenter to Azure, so it cannot act as a failover path for ExpressRoute. Its placement in the architecture would add security inspection, but it does not address the requirement for redundant hybrid connectivity.

Deploy VMs in an Availability Set

Why it fails: An Availability Set spreads VMs across fault domains within a single datacentre, which does not satisfy the physically separate hardware requirement across zones. It is tempting because it is the classic anti-affinity construct, and it would be correct for protecting against rack-level failures within one region.

Deploy VMs in a Proximity Placement Group

Why it fails: A Proximity Placement Group reduces network latency by co-locating VMs within a single datacentre; it does not place them on physically separate hardware, nor does it protect against host maintenance events. It suits tightly coupled, latency-sensitive workloads such as HPC clusters, not the fault-isolation requirement stated here.

Deploy VMs in a Virtual Machine Scale Set

Why it fails: A Virtual Machine Scale Set provides elasticity and autoscaling across identical instances, but its default distribution offers no guarantee of separation across fault domains or protection during host maintenance. It is the right choice for demand-driven horizontal scaling, not for the physical hardware separation this scenario demands.

SQL Server Failover Cluster Instance (FCI)

Why it fails: A SQL Server Failover Cluster Instance protects the entire SQL Server instance at the compute/storage level using shared storage (e.g., Azure Shared Disks or Storage Spaces Direct in Azure VMs). It does not replicate data on its own; the single copy of data lives on shared storage, and the secondary node owns the same storage after failover. It cannot provide synchronous zero-data-loss replication across separate storage, and it has no readable secondary replicas for reporting, so it does not meet the stated requirements.

Azure Site Recovery

Why it fails: Azure Site Recovery orchestrates VM-level replication to a secondary Azure region for disaster recovery, continuously replicating managed disks using asynchronous snapshots. It targets regional outages, not high availability within the primary region; RPO is typically a few minutes, so it cannot guarantee zero data loss. Even if used for failover, it replicates the whole VM rather than enabling readable secondary SQL replicas, so it cannot satisfy the zero-data-loss or reporting-offload requirements.

Azure Backup

Why it fails: Azure Backup provides application-consistent snapshots and long-term retention of SQL Server VMs, but it is purely a backup and restore mechanism. It does not monitor SQL Server health or perform automatic failover, and a restore inherently recreates data only as of the last recovery point. Because backups are taken on a schedule (e.g., daily or hourly), recent transactions since the last backup would be lost, so it cannot achieve zero data loss or provide active readable secondaries for reporting.

Use Azure Firewall to provide static private IP and load balancing.

Why it fails: Azure Firewall is a managed network security service that filters and logs traffic using network/application rules, but it is not a load balancer. Its static IP addresses belong to the firewall's own frontend and backend interfaces for routing and NAT, not to a VM's NIC. It cannot perform health checks or distribute inbound connections across backend instances; high availability for a VM requires a dedicated load balancer such as Azure Load Balancer.

Use Azure Traffic Manager to assign static private IP.

Why it fails: Azure Traffic Manager is a DNS-based global traffic router that steers clients to different endpoints based on methods like priority, performance, or geolocation. It does not allocate, assign, or control any IP addresses on Azure VMs; it simply maps a domain name to existing public endpoints via DNS records. Therefore, Traffic Manager cannot create or guarantee a static private IP for a VM, because that address can only be set on the VM's virtual NIC within the VNet.

Use Application Gateway with a static private IP.

Why it fails: Application Gateway is a layer-7 load balancer designed for HTTP/HTTPS traffic, and any static private IP you configure is the frontend address for the gateway appliance itself. The backend VM's own private IP address is still assigned to its NIC independently and will remain dynamic unless explicitly changed to a static assignment in the NIC properties. Thus, placing a static private IP on the gateway does not make the VM's IP static, and the gateway is not intended to solve VM-level IP addressing questions.

Deploy Azure SQL Database Managed Instance with failover group to a secondary instance in West US.

Why it fails: Managed Instance's failover groups rely on a geo-replication mechanism that guarantees at most a 5-minute RPO, which is insufficient for a healthcare workload that may need near-zero data loss to meet compliance obligations. Additionally, Managed Instance failover groups require the secondary to be a Managed Instance too, adding administrative overhead and complexity compared to a single Azure SQL Database logical server deployment.

Deploy Azure SQL Database Business Critical tier with auto-failover group and a secondary replica in a different availability zone within East US.

Why it fails: Placing the secondary replica in a different availability zone—even in Business Critical tier—addresses only zone-level faults, not a wholesale East US region outage. Failover groups require the secondary server to reside in a separate Azure region, so this design lacks true disaster recovery capability across geographical boundaries and would still go down if the entire region is impacted.

Deploy Azure SQL Database General Purpose tier with zone-redundant configuration.

Why it fails: Zone-redundant configuration in General Purpose tier replicates data automatically across availability zones but confines the copies to the same region, giving high availability for datacenter incidents while providing no protection against a regional failure. While General Purpose offers active geo-replication, zone-redundancy by itself does not create a secondary in another region and therefore does not satisfy the need for cross-region disaster recovery.

Site-to-Site VPN Gateway

Why it fails: Site-to-Site VPN Gateway establishes IPsec tunnels over the public internet, and the commonly deployed SKUs (e.g., VpnGw3) offer only up to 1.25 Gbps aggregate throughput. Additionally, the standard configuration is active-passive, meaning only one tunnel carries traffic at a time; while active-active is possible, the solution still depends on internet-based connectivity and does not provide the dedicated 10 Gbps private bandwidth required.

Azure Virtual WAN

Why it fails: Incorrect. Azure Virtual WAN aggregates multiple connection types but does not itself provide dedicated 10 Gbps throughput; it is a networking service that can use ExpressRoute or VPN, but not a standalone solution for the specified requirements.

ExpressRoute FastPath

Why it fails: Incorrect. ExpressRoute FastPath is a feature that improves performance by bypassing the gateway, but it is not a standalone service. It requires an ExpressRoute circuit and does not inherently provide active-active routing or guarantee 10 Gbps throughput. The question asks for a service, not a feature.

Azure Traffic Manager

Why it fails: Azure Traffic Manager operates at the DNS level, resolving client queries to regional endpoints rather than directly routing packets to VM instances. Its health checks verify availability of the monitored endpoint as a whole, not the individual virtual machines behind a load balancer, so it cannot reroute traffic away from a failed VM within a single region. For this scenario, you need a regional Layer 4 load balancer with per-VM health probes.

Azure Front Door

Why it fails: Azure Front Door operates at the application layer (HTTP/HTTPS) and is designed for global load balancing and web application acceleration across regions, not for rerouting traffic among VMs within a single Azure region behind a load balancer. The scenario requires a regional load balancer that uses health probes to detect VM failure and redirect traffic at Layer 4 (TCP/UDP) or Layer 7 within the same region. Front Door would be correct if the need were to distribute traffic across multiple regional endpoints or to provide global failover with path-based routing.

Azure Application Gateway

Why it fails: Application Gateway uses Layer 7 routing and HTTP/HTTPS health probes, but the scenario requires only basic VM health monitoring behind a load balancer, which is a Layer 4 function. It is tempting because its health probes can redirect traffic away from failed VMs, yet it introduces unnecessary protocol-level inspection and SSL termination. It would be correct if the application needed URL-based routing or web application firewall capabilities.

Azure Front Door

Why it fails: Azure Front Door is tempting as it provides a single global DNS endpoint, automatically routes traffic to the nearest healthy region based on latency, and offers failover for high availability, which aligns with several requirements for a global web application. However, it fails to meet the specific requirement for routing traffic based on "available capacity". Front Door primarily uses latency-based routing and health probes, not dynamic load-based distribution across regions to account for current capacity constraints, which is a key distinction for this scenario.

Azure Load Balancer

Why it fails: Azure Load Balancer is a regional, layer-4 network load balancer that distributes traffic within a single Azure region and a single virtual network. It cannot route or redirect traffic across multiple regions because it has no DNS-based or global endpoint capability, and its health probes only monitor VMs in its own backend pool. Therefore, it fails to provide the cross-region capacity-based routing required for a multi-region VM deployment.

Azure Application Gateway

Why it fails: Azure Application Gateway operates at Layer 7 (HTTP/HTTPS) and is deployed within one region, providing SSL termination, path-based routing, and WAF capabilities for regional web traffic. While it can perform sophisticated request routing based on URL and host headers, it lacks a global DNS-based traffic management layer and cannot direct users to the nearest or most available regional deployment. Its backend pools are confined to a single region, so it cannot satisfy the requirement for routing across multiple regional VM deployments based on available capacity.