Load Balancer practice questions

Azure Application Gateway.

Why wrong: Azure Application Gateway operates at Layer 7, performing HTTP/HTTPS routing, SSL termination, and URL-path-based forwarding. Because the scenario only requires distributing raw TCP 443 traffic to backend VMs, these application-level features are unnecessary, adding complexity and cost without meeting the basic L4 load-balancing requirement.

Azure Traffic Manager.

Why wrong: Azure Traffic Manager is a DNS-based global load balancer that resolves client queries to regional endpoints based on routing policies such as performance or priority. It does not inspect or forward individual TCP connections to VM IPs, and it cannot use a single public IP to directly balance traffic across backend VMs; therefore it fails the stated requirement.

Azure Front Door.

Why wrong: Azure Front Door is a global HTTP/HTTPS entry point that provides CDN acceleration, Web Application Firewall, and rule-based routing at Layer 7. It is designed for internet-facing web applications that need global edge termination and HTTP-level features, not for simple Layer 4 TCP load balancing on a single public IP, making it an inappropriate choice here.

Create Load Balancer → Configure backend pool → Configure frontend IP configuration → Add health probes → Configure load balancing rules → Associate VMs to backend pool

Why wrong: This order is incorrect because the frontend IP configuration must be defined before the backend pool, as the load balancing rules will reference both. Creating the backend pool first is possible but not ideal since the frontend is needed to complete the rule configuration later.

Create Load Balancer → Configure frontend IP configuration → Configure load balancing rules → Configure backend pool → Add health probes → Associate VMs to backend pool

Why wrong: This order is incorrect because load balancing rules require both a frontend and backend pool to be defined. Configuring rules before the backend pool would cause configuration errors as the backend reference does not exist yet.

Create Load Balancer → Configure frontend IP configuration → Configure backend pool → Configure load balancing rules → Associate VMs to backend pool → Add health probes

Why wrong: This order is incorrect because health probes are essential for the load balancing rules to function properly. Adding probes after associating VMs means the rules would not have a health check, potentially directing traffic to unhealthy VMs. Probes must be configured before or at the same time as the rules.

Place both VMs in a single availability set.

Why wrong: An availability set improves resilience against rack-level failures and planned maintenance by placing VMs in different fault domains and update domains, but all of those domains still live within a single Azure datacenter. A full datacenter outage -- for example, loss of power, cooling, or upstream connectivity to that facility -- will bring down every fault domain in the set, including both of your VMs. For a stateless web app that must stay online, you need isolation at the zone level, where zones are physically separate datacenters, rather than only rack-level separation. Since the load balancer already fronts the VMs, distributing them across availability zones is a stronger design.

Deploy one VM and rely on Azure Backup for recovery.

Why wrong: Backup is designed for disaster recovery, not for ongoing availability. If the single VM fails, Azure Backup can restore its VHD or files to a new VM, but that process requires manual or scripted actions and can take minutes to hours. During that time the application is offline, and because the load balancer has only one back-end VM, it has no healthy target to route traffic to. Additionally, the most recent backup only covers the configured RPO, so you could lose any changes made after the last backup.

Deploy both VMs without any fault-domain configuration.

Why wrong: When you deploy two VMs without any fault-domain or availability-zone configuration, Azure offers no guarantee about their physical placement. In the worst case, they can be placed on the same host server or the same rack, so a single hardware failure, a firmware update, or a top-of-rack switch outage brings down both instances simultaneously. You also get no protection from simultaneous patching, because Azure can apply the same update-domain event to both VMs together. This negates the value of running two VMs behind a load balancer and is strictly less resilient than using either an availability set or availability zones.

An availability set with two VMs

Why wrong: An availability set with two VMs distributes them across fault domains and update domains, but those domains are constrained to a single datacenter cluster within a region. This configuration protects against rack-level hardware failures and planned maintenance windows, but it cannot survive a full datacenter or availability zone outage because both VMs may live in the same zone. If that zone fails, the entire application is unavailable, so this is not the correct answer.

A single virtual machine scale set instance

Why wrong: A single-instance virtual machine scale set still represents a single point of failure because there is only one VM to handle traffic. If that instance crashes, the underlying host fails, or a maintenance event forces a reboot, the application goes down. Autoscaling and orchestration features do not add resilience by themselves; a scale set must run at least two instances, ideally across availability zones or fault domains, to provide redundancy.

A proximity placement group

Why wrong: A proximity placement group is designed to minimize network latency by co-locating VMs in the same geographic location, often within the same datacenter or availability zone. This deliberate co-location increases the risk of correlated failures, as both VMs may depend on the same power, cooling, and network infrastructure. A proximity placement group does not provide any zone or datacenter redundancy, so using it alone would fail to meet the resiliency requirement.

Keep both VMs in the same availability set to spread them across update domains only.

Why wrong: An availability set spreads VMs across both fault domains and update domains, but those domains reside within the same datacenter. Even if you deliberately focus on update-domain placement, this design protects only against planned Azure maintenance and individual hardware failures, not against a whole datacenter losing power or connectivity. Because both VMs remain tied to one physical location, the workload has no automatic failover path if that datacenter becomes unavailable.

Deploy both VMs into a proximity placement group to reduce latency between them.

Why wrong: A proximity placement group is designed to co-locate VMs in the same datacenter or even the same rack to minimize network latency between them. It deliberately increases failure correlation because the VMs share the same underlying infrastructure, so it does not provide any isolation across datacenters. Adding a load balancer in front of a PPG does not introduce a second physical failure domain. This option is therefore optimized for performance, not for high availability.

Move the VMs into a single availability set and add more managed disks for redundancy.

Why wrong: Placing both VMs in the same availability set and adding extra managed disks does not address compute resilience. Availability sets distribute VMs across fault and update domains within a single datacenter, so they cannot survive a full datacenter or zone outage. Additional managed disks only provide durable storage replication, not another compute host in a separate failure domain. Thus this change fails the requirement for business continuity during a datacenter incident.

The VMs are in an availability set.

Why wrong: The VMs are in an availability set. An availability set is a logical grouping that spreads VMs across fault domains and update domains to protect against hardware failures and maintenance events. It does not remove a VM from a load balancer's backend pool; in fact, load balancers frequently work with availability sets to provide high availability. Membership in an availability set alone cannot make the VMs unreachable to the load balancer.

The storage account uses the Cool tier.

Why wrong: The storage account uses the Cool tier. Azure Storage access tiers (Hot, Cool, Cold, and Archive) are performance and cost optimizations for blob data, completely independent from compute networking resources. A load balancer routes traffic based on health probes and backend pool membership, not on storage configuration, so the Cool tier has no mechanism to influence VM availability behind the load balancer.

The subscription has a budget alert.

Why wrong: The subscription has a budget alert. Budget alerts are cost management notifications triggered when spending reaches a threshold, and they are purely informational. They do not deprovision resources, alter network configurations, or modify load balancer backend health. Since they have no effect on the control plane or data plane of Azure Load Balancer, a budget alert cannot be the cause of backend instances being marked as unavailable.

Replace ASG-Web with the VirtualNetwork service tag in the allow rule.

Why wrong: Swapping ASG-Web for the VirtualNetwork service tag expands the allow rule to every source IP in the virtual network instead of only the web-tier VMs, but the problem is the rule's priority. As long as the deny rule at priority 100 is evaluated first, the allow rule — regardless of its source scope — will never be applied to the traffic.

Add a route table that sends TCP 8443 traffic to the app subnet.

Why wrong: A route table (UDR) defines the next-hop path for forwarded traffic and is evaluated after NSG filtering determines that the packet is permitted. Re-routing TCP 8443 toward the app subnet does not modify the NSG rule set, so the inbound deny rule still matches and the connection is blocked before any routing decision is applied.

Create a second NSG on the app NIC with an allow rule at priority 50.

Why wrong: For inbound traffic, Azure evaluates a subnet-attached NSG before the NIC-attached NSG. The existing deny rule at priority 100 in the subnet NSG matches the packet first, so processing stops and the desired NIC-level allow rule at priority 50 is never evaluated; lower numeric priority on the NIC NSG does not override the sequential NSG evaluation order.

A public Standard Load Balancer with a public frontend IP.

Why wrong: A public load balancer maps a public IP address and routes inbound internet traffic to backend VMs. While it can certainly distribute TCP connections across the two application VMs, its frontend is reachable from the internet, which directly conflicts with the requirement that the application remains internal. Because the application is intended for internal users only, a public frontend would expose it to external access and misuse, so this is not the right choice.

A NAT gateway attached to the application subnet.

Why wrong: A NAT gateway provides outbound source network address translation (SNAT) so that VMs in the subnet can initiate connections to the internet, but it does not accept or forward inbound traffic. Attaching it to the application subnet would not create a frontend for the two VMs, nor would it load balance user requests to the application. Since the requirement is to distribute incoming HTTPS traffic, a NAT gateway is conceptually opposite to the needed service.

A network security group rule allowing TCP 443 from the internet.

Why wrong: An NSG rule is a filtering mechanism that permits or denies traffic based on source/destination IP, port, and protocol; it cannot perform load balancing or health probes. Even if you added a rule allowing HTTPS traffic from the internet, it would only open port 443 on NICs or subnets, and without a public IP on the VMs it would not even be reachable. More importantly, this would violate the private requirement by permitting inbound internet access to the application, and it would not spread load across the two VMs.