Design infrastructure solutions practice questions

Use a single virtual network for all resources with a network virtual appliance.

Why wrong: Azure virtual networks are scoped to a single subscription, so a single VNet cannot span or be directly shared across multiple Azure subscriptions; each subscription would need its own VNet with peering or a gateway. Even if you forced resources into one VNet, it would quickly exhaust per-VNet limits such as the 65,536 total resources and 50,000 peerings, making the architecture unscalable. A single network virtual appliance (NVA) placed in that VNet would also become a performance bottleneck and single point of failure, especially when all outbound traffic from every subscription and on-premises site must traverse it. This design mixes unrelated workloads and fails to provide the isolation and independent management that the hub-spoke model offers.

Use an Azure Virtual WAN with security virtual WAN hub.

Why wrong: Using an Azure Virtual WAN with a security virtual WAN hub provides centralised internet egress for connected Azure VNets and integrates ExpressRoute. However, it is primarily designed for large-scale, global network connectivity and simplifying branch office integration, not specifically for enforcing a single web filtering policy for existing ExpressRoute connections to on-premises data centres. This solution would be appropriate for consolidating a complex global network with numerous branch sites requiring simplified, managed connectivity and security services.

Use Azure Traffic Manager with Azure Firewall.

Why wrong: Azure Traffic Manager is a DNS-based load balancer for distributing traffic across endpoints. It cannot enforce outbound traffic policies. Azure Firewall is a security service, but without proper routing (UDRs) and VNet architecture, it cannot control outbound traffic from multiple VNets.

A

Why wrong: 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

Why wrong: 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.

D

Why wrong: 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

Why wrong: Azure Kubernetes Service (AKS) is a managed Kubernetes cluster, but 'managed' only means the control plane is maintained by Azure; you still must handle node pool sizing, OS patching, upgrading Kubernetes versions, autoscaler tuning, and monitoring for the nodes. For a simple microservices app that doesn't need complex service discovery, ingress controllers, or stateful orchestration, this operational overhead outweighs the benefits, and you are billed for the underlying VMs even when no containers are running.

C

Why wrong: Azure App Service for Containers is built for hosting web applications, with a built-in HTTP load balancer, auto-scaling per-app, and continuous deployment support. However, each App Service plan is allocated fixed VM sizes and billing tiers, and the platform is optimized for long-running web endpoints rather than short-lived, generic container workloads; per-second billing is not available, and scaling requires either adjusting the plan tier or configuring autoscale rules, which adds latency and cost compared to ACI's instantaneous, per-second model.

D

Why wrong: Azure Virtual Machines with Docker require you to provision and manage the VM lifecycle: apply OS security patches, configure Docker daemon, manage container restarts, handle disk encryption, and set up a load balancer for scaling. You are paying for the VM even when containers are idle, and scaling requires manually creating or deallocating VMs or configuring VMSS, which involves significant operational staff time and complexity. For a simple microservices application, this is the antithesis of minimizing operational overhead and is generally reserved for legacy workloads that cannot use serverless or PaaS options.

Azure Virtual WAN with a secured hub using Azure Firewall

Why wrong: Azure Virtual WAN with a secured hub using Azure Firewall is wrong because the requirement specifically asks for a third-party network virtual appliance (NVA), but the Virtual WAN secured hub is a Microsoft-managed Azure Firewall deployment managed via Azure Firewall Manager. You cannot install a custom third-party NVA inside the Virtual WAN hub itself, and the architecture of Virtual WAN (with its own routing constructs like routing intent) is fundamentally different from a classic hub-spoke with user-defined routes. This option also forces you to change your deployment model, which is unnecessary and misaligned with the stated NVA requirement.

Azure VNet-to-VNet VPN gateways between all spokes

Why wrong: Azure VNet-to-VNet VPN gateways between all spokes is wrong because it creates a full-mesh topology requiring O(n²) VPN gateways and connections, which dramatically increases cost, operational overhead, and configuration complexity. Additionally, VPN gateway routing is based on the gateway's BGP and route table, not on the hub NVA, so inter-spoke traffic would traverse the IPsec tunnels directly between spoke gateways and bypass the NVA entirely, breaking the requirement for centralized inspection and control through the hub appliance.

Azure ExpressRoute with private peering

Why wrong: Azure ExpressRoute with private peering is wrong because ExpressRoute is designed for private, high-bandwidth connectivity between an on-premises network and Azure, not for routing traffic between Azure VNets. Using ExpressRoute for inter-spoke traffic would force traffic to hairpin through your on-premises routers, adding significant latency and requiring on-premises infrastructure to handle Azure-to-Azure traffic, and it still would not route traffic through the hub NVA. It also incurs unnecessary egress costs and complexity, making it an inappropriate choice for this hub-spoke scenario.

Azure Load Balancer

Why wrong: 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.

Azure Traffic Manager

Why wrong: 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.

Azure Front Door

Why wrong: 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.

Just-in-Time VM access

Why wrong: Just-in-Time (JIT) VM access, part of Microsoft Defender for Cloud, temporarily opens the configured management ports (RDP/SSH) via network security group rules to a specific allowed source IP address for a limited time after user approval. While this is more secure than permanently open ports, the VM still needs a public IP address or a public-facing load balancer to receive the incoming connection, and the user must use an RDP/SSH client on their machine. Because the scenario explicitly prohibits public IP exposure and requires no client software, JIT VM access does not meet the stated constraints and is therefore incorrect.

Azure VPN Gateway

Why wrong: Azure VPN Gateway establishes an encrypted IPsec/IKE site-to-site or point-to-site tunnel between on-premises networks and an Azure virtual network. However, for a remote user to connect, the device typically must run a VPN client (such as IKEv2, OpenVPN, or SSTP) and be configured with certificates or authentication details. This requirement conflicts directly with the scenario's need to avoid installing client software on user machines, so although it provides secure connectivity, it is not the appropriate solution for secure remote administration in this case.

Microsoft Entra ID Domain Services

Why wrong: Microsoft Entra ID Domain Services (formerly Azure AD DS) provides managed domain services such as LDAP, Kerberos, NTLM, and Group Policy to Azure virtual machines via domain join, addressing identity and authentication needs. It does not, however, offer any remote administration or connectivity features—it is not a proxy for RDP/SSH sessions and cannot deliver a browser-based console. Even if a VM is domain-joined to Entra DS, users are still forced to use separate RDP or SSH clients over a network path; therefore, it fails to meet the requirement for secure remote access without client software.

Azure Service Endpoints

Why wrong: Service endpoints do not create a private IP for Azure SQL; they simply extend your virtual network's identity to the service and route VNet-originated traffic to the public endpoint over the Azure backbone. The database destination remains the public fully qualified domain name, so the connection is not isolated from public exposure, and on-premises clients are not supported unless they first enter a VNet. In contrast, a private endpoint makes the database appear inside the VNet with a private address.

Azure VPN Gateway

Why wrong: A VPN Gateway creates an IPsec tunnel between your on-premises network and an Azure virtual network, but that tunnel terminates at a gateway object, not at the database. Azure SQL Database is a PaaS resource with a public namespace; even though your traffic may traverse the tunnel, the SQL listener is still resolved via public DNS and does not receive a private address. For true private connectivity, you would still need Private Link or another mechanism to map the database into the VNet.

Azure Front Door

Why wrong: Azure Front Door is a global layer-7 load balancer and HTTP/S reverse proxy that routes traffic based on URL paths and latency, primarily for web applications and APIs. It operates at the public edge and cannot expose Azure SQL through a private IP, nor does it handle the TDS protocol used by SQL clients. Using Front Door for database access would force traffic through a public HTTP endpoint, offering neither private connectivity nor the required SQL wire protocol support.

Two ExpressRoute circuits from different service providers, both active.

Why wrong: Deploying two ExpressRoute circuits from different service providers, both active, is a valid strategy for maximizing availability, but it does not satisfy the 'lower cost' requirement. Both circuits carry identical premium pricing, including port and egress charges, so total cost roughly doubles compared to using one ExpressRoute and a VPN backup. Additionally, while active-active placement can distribute traffic, the failure of one circuit still requires the other to carry all load, but the design offers no cost advantage over a single circuit with a cheaper internet-based fallback.

Site-to-Site VPN as the primary connection and Point-to-Site VPN as the backup.

Why wrong: Choosing a Site-to-Site VPN as the primary connection fails the 'high bandwidth and private connectivity' requirement because all traffic traverses the public internet and is subject to variable latency and ISP throughput. A Point-to-Site VPN is fundamentally a client-to-Azure tunnel for individual devices, not a site-to-site tunnel between networks, so it cannot act as a backup for an on-premises data center's entire traffic. Even if both are IPsec-based, a P2S tunnel would require per-user credentials and doesn't route whole subnet-to-subnet traffic.

Azure VPN Gateway with active-passive mode and a second VPN Gateway for failover.

Why wrong: An Azure VPN Gateway configured in active-passive mode adds redundancy for the VPN endpoint within Azure, but both active and passive instances still terminate IPsec tunnels over the public internet. Adding a second VPN Gateway for failover does not change the underlying transport; it remains internet-based and does not meet the 'private, dedicated' criterion. Furthermore, active-passive mode is designed to handle internal gateway maintenance or zone failures, not to provide a lower-cost alternate path, and two VPN Gateways incur duplicate licensing and data-processing costs.

Azure Load Balancer

Why wrong: Azure Load Balancer operates at the transport layer (L4) and makes forwarding decisions based on source/destination IP addresses, ports, and protocol—without inspecting HTTP request bodies or URLs. Consequently, it cannot perform URL-based path routing or terminate SSL sessions, which are critical for a web application that requires routing to different back-end pools based on the request path. While it is excellent for distributing TCP/UDP traffic and preserving a high-throughput, low-latency data path, it lacks the application-level awareness needed for this scenario.

Azure Traffic Manager

Why wrong: Azure Traffic Manager is a DNS-based global traffic load balancer that operates entirely at the DNS query level, directing clients to the nearest or healthiest regional endpoint but having no visibility into the actual HTTP request path or URL. Because it only resolves endpoint IP addresses based on routing methods like priority, performance, or geographic location, it cannot inspect paths such as /images or /api to route within a single region and cannot perform SSL offloading. Its role is to distribute traffic across Azure regions for disaster recovery or geo-expansion, not to provide application-layer URL routing for VMs in a single Azure region.

Azure Front Door

Why wrong: Azure Front Door is a global, layer-7 load balancer and CDN that uses Microsoft's anycast network to route HTTP(S) traffic across regions to the nearest point of presence, making it designed for multi-region failover and acceleration rather than intra-region VM load balancing. While Front Door does support URL-based routing and SSL termination, its global scope and content-delivery features introduce additional latency and cost without benefit for a set of VMs colocated in a single Azure region. For a purely regional, single-region web application with URL-specific routing needs, Azure Application Gateway is the more aligned and cost-effective service.

Azure Jump Box VM

Why wrong: A jump box VM is a manually managed Windows or Linux VM that acts as a bastion host but requires a public IP address to reach from the internet, creating a direct attack surface. It must be patched, NSG-secured, and configured with additional tools for MFA, and it does not natively integrate with Microsoft Entra ID for single sign-on—forcing users to manage separate VM credentials or deploy complex domain-join and AAD extension configurations. This operational overhead and security risk make it an inferior choice compared to Azure Bastion's managed, identity-aware model.

Azure VPN Gateway

Why wrong: Azure VPN Gateway establishes site-to-site or point-to-site network-level connectivity by creating an encrypted tunnel (IKEv2, SSTP, OpenVPN) between a client or on-premises network and Azure, but it does not provide any direct RDP/SSH proxying for specific VMs. Users must install and configure a VPN client, authenticate to the gateway (often with separate credentials or a certificate, not natively via Entra ID unless complex SAML/MFA flows are added), and then manually connect to a VM's private IP. It lacks the browser-embedded, portal-integrated, identity-aware access that Azure Bastion delivers, and it does not offer per-VM RBAC or session-level controls.

Azure ExpressRoute

Why wrong: Azure ExpressRoute provides a private, dedicated Layer-3 network connection between an on-premises datacenter and Azure, typically via MPLS or Ethernet, but it is designed for high-bandwidth, low-latency network integration between sites—not for individual user access to VMs. It does not include any RDP/SSH gateway or proxy functionality, no browser-based portal integration, and no native Microsoft Entra ID authentication for user sessions; it simply extends the network path. Using ExpressRoute to reach VMs would still require a separate jump box or Bastion to establish a remote desktop session, making it redundant and unnecessarily expensive for this single-user remote access scenario.

Site-to-Site VPN only

Why wrong: A Site-to-Site VPN establishes an IPsec tunnel over the public internet, which is a best-effort network with variable latency, jitter, and throughput. While it can be used for encryption and basic connectivity, it cannot provision a dedicated, high-bandwidth link with consistent low latency and a guaranteed SLA for the primary path. For a production workload requiring stable performance, relying solely on VPN makes performance unpredictable and may fail to meet network requirements.

ExpressRoute only

Why wrong: ExpressRoute provides a private, dedicated connection to Azure through a service provider, bypassing the public internet and offering a higher SLA. However, a single ExpressRoute circuit is a single point of failure; if the provider suffers an outage, the fiber is cut, or the customer-premises equipment fails, connectivity to Azure is completely lost. ExpressRoute does not inherently provide redundancy unless a second circuit or another connection type is configured, so using it alone fails the resilience requirement.

Azure Virtual WAN with VPN

Why wrong: Azure Virtual WAN is a managed hub-and-spoke networking service that simplifies routing and consolidates multiple connectivity types, but it is not a transport medium. If the planned connectivity uses only a VPN, traffic still traverses the public internet, subject to the same bandwidth, latency, and SLA limitations as any Site-to-Site VPN. Virtual WAN can include ExpressRoute, but this option explicitly specifies VPN only, so it lacks the dedicated private path required for the primary link and does not meet the core performance requirement.

Azure Load Balancer

Why wrong: Azure Load Balancer is a Layer 4 (TCP/UDP) load balancer that distributes traffic only within a single Azure region and a single backend pool, such as virtual machines in one virtual network. It cannot perform geographic or DNS-based routing across two regions, nor can it make decisions based on application-layer attributes like URL or host header. Therefore, it is an incorrect choice for directing users to the nearest of two regional web application deployments.

Azure Application Gateway

Why wrong: Azure Application Gateway is a regional, Layer 7 (HTTP/HTTPS) load balancer that offers capabilities like SSL termination, cookie affinity, URL path–based routing, and a Web Application Firewall inside a single region. While it provides rich application-layer control, it is deployed as one resource within a specific region and has no global DNS or cross-region routing logic to balance traffic between two Azure regions. It would only be a component within each regional deployment, not the global routing service needed here.

Azure Front Door

Why wrong: Azure Front Door is tempting as it provides global HTTP/S load balancing, directing web traffic to the nearest healthy backend based on geographic location and health probes. However, it is specifically designed for Layer 7 (HTTP/S) traffic and acts as a reverse proxy, terminating user connections at the edge. If the web application requires directing users based on DNS resolution for non-HTTP/S protocols or a broader range of services, Azure Traffic Manager would be the appropriate choice, as it operates at the DNS layer to distribute traffic.

Azure Load Balancer

Why wrong: 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.

Azure Traffic Manager

Why wrong: 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.

Azure Front Door

Why wrong: 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.

Azure Virtual Network peering

Why wrong: Azure Virtual Network peering creates a point-to-point connection between exactly two virtual networks, using Azure's private backbone only between those VNets. It cannot directly terminate on-premises connections, and it lacks a centralized management plane for routing policy across many regions and sites. To connect on-premises, you would still need to attach an additional gateway (VPN or ExpressRoute) to one of the peered VNets, and scaling to many VNets requires manually configuring each peering relationship. This makes it a suboptimal choice compared to a service that natively aggregates multi-region and on-premises connectivity.

Azure VPN Gateway with multi-site connections

Why wrong: Azure VPN Gateway with multi-site connections allows a single VPN gateway to terminate Site-to-Site IPsec tunnels from multiple on-premises locations, but it is still deployed per VNet and does not natively interconnect other VNets across regions without additional peering or routing configuration. Traffic to and from on-premises is typically encrypted over the public internet (or through a partner provider), not necessarily using the Microsoft backbone for all routing—though some paths may use it depending on configuration. It also lacks a global management plane; each VPN gateway must be configured individually, and multi-region VNet-to-VNet connectivity would require VNet peering or additional gateway settings. Thus, while it can handle multiple sites, it does not provide the consolidated, centrally managed global network fabric that a Virtual WAN does.

Azure ExpressRoute Gateway

Why wrong: Azure ExpressRoute Gateway is the Azure-side gateway object that connects an ExpressRoute circuit to a single virtual network, providing private, high-bandwidth connectivity between on-premises and that specific VNet. It does not, by itself, create links between multiple VNets—those VNets still need VNet peering or a hub-and-spoke topology with user-defined routes to communicate. It also does not provide a centralized management interface across regions; each ExpressRoute Gateway lives inside one VNet and applies to that VNet only. While ExpressRoute is a premium connectivity option, the gateway alone is not a replacement for a transit or global WAN architecture like Virtual WAN, which can incorporate ExpressRoute circuits as one of its connection types.

VNet peering

Why wrong: VNet peering creates a direct, non-transitive connection between exactly two VNets; the peered VNets can communicate, but a third VNet cannot use that peering as a hop to reach the other side. Connecting several VNets in different regions requires an O(n²) mesh of peerings, and each new VNet increases configuration and route-table complexity. It also lacks native integration with ExpressRoute or VPN sites as a managed hub, so while it is a fundamental building block, it is not a WAN solution.

ExpressRoute

Why wrong: ExpressRoute provides a dedicated private Layer 3 connection from on-premises to Azure, but it does not directly interconnect multiple VNets. For one VNet to reach another over an ExpressRoute circuit, you still need a VNet gateway, a hub VNet, and VNet peering or route-server route propagation, and the routing is not automatically transitive across many VNets and regions. ExpressRoute solves the on-premises-to-Azure connection, not the inter-VNet connectivity requirement described in the question.

VPN Gateway

Why wrong: A VPN Gateway terminates point-to-point IPsec tunnels on a single VNet or between two VNet gateways (VNet-to-VNet), but the path is non-transitive: a third VNet or another on-premises site cannot automatically route through that gateway unless you manually configure additional tunnels or complex route tables. Each VNet that requires VPN connectivity needs its own gateway, so scaling this across multiple regional VNets becomes operationally heavy and error-prone. It is not a centrally managed WAN and lacks the automatic transitive routing that Azure Virtual WAN provides.

VNet peering

Why wrong: VNet peering establishes a direct, non-transitive layer-3 link between exactly two VNets in the same or different regions, but it does not forward traffic through any intermediate VNet by default. Peer connectivity is pairwise, so interconnecting a handful of regional VNets requires a full mesh of peering objects, and there is no built-in routing table orchestration, branch access, or centralized operations dashboard. In addition, peering alone cannot present a global WAN service—it simply moves packets between the two peered VNets you explicitly configure.

Azure VPN Gateway

Why wrong: Azure VPN Gateway is a per-VNet device that builds an IPsec/IKE site-to-site tunnel to on-premises or another Azure VNet, and it supports active-active and ExpressRoute coexistence, but it is not a multi-region backbone product. Connecting multiple regional VNets would require you to configure and manage gateway-to-gateway tunnels for each pair, which lacks automatic route exchange between all VNets and does not yield the hub-and-spoke orchestration offered by Virtual WAN. Its primary role is site-to-site and point-to-site access, not an integrated meshed WAN spanning many regional VNets.

Azure ExpressRoute

Why wrong: ExpressRoute provisions a dedicated, private Layer-3 circuit from an on-premises network to a Microsoft edge or partner network, giving high throughput and low latency for connectivity to Azure services. A separate virtual network gateway on each VNet is still required for traffic to flow over the circuit, and while one ExpressRoute circuit can reach multiple VNets through auth keys and service provider wiring, it does not route VNet-to-VNet traffic or maintain any topology among those VNets. It is therefore a connectivity circuit, not a regional VNet interconnection or orchestration mechanism.

Azure App Service

Why wrong: Azure App Service is incorrect because it is a fully managed Platform-as-a-Service (PaaS) offering for hosting web apps, REST APIs, and mobile backends, not a service for managing or scaling a fleet of VMs. With App Service, you deploy your code to a managed runtime environment and scale via App Service plans, which adjust the number and size of worker nodes behind the scenes—you never control or access the underlying VMs. Since the company in the question is already running on Azure VMs, App Service would require rearchitecting the application to a PaaS model, rather than providing VM-level scaling.

Azure Functions

Why wrong: Azure Functions is incorrect because it is a serverless compute service designed for event-driven, short-lived functions that scale automatically based on incoming triggers such as HTTP requests, queue messages, or timers, not for orchestrating or scaling a set of virtual machines. It abstracts away all infrastructure, including VMs, and executes stateless code with scale controlled by the Functions runtime, not by VM scale rules. For a web application already deployed on VMs, Functions cannot scale or manage those VMs; it is a completely different execution model.

Azure Batch

Why wrong: Azure Batch is incorrect because it is a service for planning, scheduling, and running large-scale parallel and high-performance computing (HPC) batch workloads, not for autoscaling web application VMs. Batch allocates and manages a pool of compute nodes to process many jobs in a queue, with scaling based on the number of pending tasks, and those nodes are typically isolated from public-facing traffic. Unlike VMSS, which integrates with load balancers for serving web requests, Batch is designed for offline processing and does not provide the health probes, rolling upgrades, or load balancing features needed to operate a web frontend.

Azure Load Balancer

Why wrong: 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.

Azure Traffic Manager

Why wrong: 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.

Azure Front Door

Why wrong: 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.

Azure API Management

Why wrong: Azure API Management (APIM) is a dedicated API gateway designed to publish, secure, and monitor APIs for internal and external consumers. When deployed in internal VNet mode, its gateway endpoint is private by default, but it can be exposed to external partners through a public IP or via an external front-end device while retaining all of its own API security features. APIM natively integrates with OAuth2, supports subscription-based rate limiting and quotas, caching, CORS, and rich policy definitions, making it the correct service for securely exposing APIs to external partners.

Azure Front Door

Why wrong: Front Door is a global, cloud-scale entry point that offers HTTP/HTTPS load balancing across backends, SSL offload, path-based routing, and content caching through a large edge network, along with a global WAF. It is a CDN and application delivery controller, not an API gateway; it lacks the ability to manage API subscriptions, issue or validate OAuth2 tokens, enforce per-subscription throttling, or apply API transformation and governance policies. Although it may accelerate and protect HTTP traffic, it does not provide the API-level management capabilities required in this scenario.

Azure Traffic Manager

Why wrong: Traffic Manager provides DNS-based traffic routing to distribute traffic across global Azure endpoints based on routing methods like performance, failover, or geographic priority. It works at the DNS resolution level and has no awareness of HTTP/HTTPS content, so it cannot perform TLS termination, URL-path inspection, or apply any kind of API policy. It simply resolves a domain name to the appropriate endpoint IP and is therefore completely unsuitable for exposing an API with authentication, rate limiting, and monitoring.

Availability Zone

Why wrong: 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 wrong: 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 wrong: 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.