Skip to main content

Technical Lab: Troubleshoot Load Balancing

Questions​

Question 1 — Multiple Choice​

An administrator configured a public Azure Load Balancer with a load balancing rule on port 80 pointing to a backend pool with three VMs. After deployment, none of the VMs receive external traffic, although all are running and have the web service active.

What missing or misconfigured component is the most likely cause?

A) The Load Balancer SKU is Standard, but the VMs use Basic public IP addresses
B) There is no health probe configured or it is failing on all backend pool instances
C) The backend pool is associated with a different subnet than the Load Balancer subnet
D) The Load Balancer does not have an inbound NAT rule configured for port 80

Question 2 — Technical Scenario​

A team configured an Azure Application Gateway with two backend pools: pool-api and pool-web. The listener is configured for path-based routing with the following rules:

/api/*   → pool-api
/static/* → pool-web

During testing, requests to /api/users return HTTP 502. Requests to /static/logo.png work normally. The servers in pool-api are running and respond correctly when accessed directly via private IP on port 80.

What is the most likely cause of the 502 error?

A) The Application Gateway listener is configured with HTTPS protocol, but the backend pool uses HTTP
B) The health probe for pool-api points to a non-existent path on the server, causing the Application Gateway to remove all instances from the pool
C) The NSG associated with the Application Gateway subnet is blocking outbound traffic to pool-api
D) Path-based routing does not support the wildcard character * in URL rules

Question 3 — True or False​

An internal Azure Load Balancer with Standard SKU, upon detecting that all backend pool instances have failing health probes, begins distributing traffic equally among all pool instances, regardless of probe status, to avoid complete service interruption.

Is this statement true or false?

Question 4 — Technical Scenario​

An administrator is investigating why a specific VM in a backend pool never receives connections, even though the health probe returns success for it. The Load Balancer configuration is as follows:

SKU: Standard
Load balancing rule:
  - Protocol: TCP
  - Frontend port: 443
  - Backend port: 443
  - Session persistence: Client IP and protocol
  - Idle timeout: 30 min

Test traffic is generated by a single client with fixed IP making repeated calls. The other two VMs in the pool receive connections normally.

What is the most likely explanation for the VM never receiving traffic?

A) The VM is in a different Availability Zone than the others, and the Load Balancer does not have zone redundancy enabled
B) The VM was added to the backend pool after client sessions were already established, and the session hash fixed traffic to the other instances
C) The session persistence algorithm based on client IP creates a hash that consistently maps that IP to the other instances, excluding this VM from that client's flow
D) The load balancing rule with 30-minute idle timeout prevents redistribution of active connections to new instances

Question 5 — Multiple Choice​

An administrator needs to expose three distinct applications via HTTPS on the same port 443 and the same public IP address, routing traffic based on request hostname (app1.contoso.com, app2.contoso.com, app3.contoso.com). Each application has its own set of backend servers.

Which Azure service meets this requirement natively?

A) Azure Load Balancer Standard with three distinct load balancing rules, one per hostname
B) Azure Traffic Manager with priority routing profile configured for each hostname
C) Azure Application Gateway with multi-site listeners and hostname-based routing rules
D) Azure Load Balancer Standard with Network Address Translation (NAT) rules configured per hostname

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

The health probe is the mechanism by which the Load Balancer determines which backend pool instances are fit to receive traffic. If no health probe is configured or if it is failing on all instances, the Load Balancer removes all from the active pool and no requests are forwarded, even with VMs running.

The main misconception represented by incorrect alternatives is confusing data plane connectivity with Load Balancer distribution logic. Alternative A is plausible in other contexts, but SKU incompatibility affects resource creation, not traffic itself after deployment. Alternative C is incorrect because the Load Balancer operates at layer 4 and does not require placement in the same subnet as the backend. Alternative D confuses load balancing rules with inbound NAT rules, which have distinct purposes.

Answer Key — Question 2​

Answer: B

HTTP 502 error in Application Gateway indicates that the gateway could not obtain a valid response from the backend. When the health probe points to a path that returns status other than 2xx/3xx, the Application Gateway considers all pool instances unhealthy and rejects requests with 502, even though servers are functioning correctly on other endpoints.

The fact that servers respond directly via private IP eliminates basic network issues and makes B the most likely cause. Alternative A would describe a protocol incompatibility issue, which typically generates handshake error and not clean 502. Alternative C would be unlikely if other rules from the same gateway work normally, since NSG would block all outbound traffic from the subnet. Alternative D is false: Application Gateway supports wildcards in routing paths.

Answer Key — Question 3​

Answer: False

The correct behavior of Azure Load Balancer Standard when all backend pool instances fail the health probe differs according to probe type: for TCP and HTTP probes, the Load Balancer does send traffic to all pool instances as a partial recovery mechanism. However, this "all-down" behavior does not equate to normal operation and is documented as a degraded state, not as an availability guarantee.

The statement is false because it describes this behavior as an intentional decision to avoid complete interruption, when in reality it represents a generalized failure state with unpredictable behavior. Additionally, the statement omits that this behavior applies only when all instances fail simultaneously, and is not equivalent to normal load balancing operation. Understanding this limit is critical for designing high availability strategies.

Answer Key — Question 4​

Answer: C

Session persistence based on "Client IP and protocol" uses a five-tuple (or two, depending on configuration) hash to deterministically map a client to a backend pool instance. If the resulting hash for that specific IP never points to the VM in question, that instance simply will not receive traffic from that client, regardless of health probe status or idle time.

Alternative B describes behavior that is plausible in theory, but session persistence operates based on hash at request time, not at the time of VM addition to the pool. Alternative A could cause latency issues or zone failure, but would not permanently exclude a VM from receiving traffic. Alternative D is incorrect because idle timeout controls termination of inactive connections, not distribution of new connections.

Answer Key — Question 5​

Answer: C

Azure Application Gateway operates at layer 7 and natively supports multi-site listeners, allowing a single IP address and port 443 to receive traffic from different hostnames and route each to its respective backend pool based on the HTTP Host header.

Azure Load Balancer (alternatives A and D) operates at layer 4 and has no visibility into HTTP hostname, being unable to route based on this criterion. Azure Traffic Manager (alternative B) is a DNS traffic balancer and operates outside the data flow, not being suitable for multiplexing hostnames on the same IP and port. Choosing Load Balancer in this scenario would result in the inability to distinguish applications, requiring distinct IPs or ports for each one.