Technical Lab: Configure an internal or public load balancer
Questions
Question 1 — Multiple Choice
You need to distribute HTTPS traffic between three virtual machines in the same Azure region. The requirement is that sessions from the same client always be directed to the same VM during an active connection, without relying on cookies managed by the load balancer.
Which configuration combination in Azure Load Balancer meets this requirement?
A) TCP protocol, Client IP distribution mode B) HTTP protocol, Client IP and protocol distribution mode C) TCP protocol, None (5-tuple hash) distribution mode D) HTTP protocol, Client IP distribution mode
Question 2 — Technical Scenario
A team configured a public Azure Load Balancer with the following set of rules:
Frontend IP: 20.10.5.100 (Public IP SKU Standard)
Backend pool: vm-app-01, vm-app-02
Health probe: HTTP, port 80, 15s interval, 2 failure threshold
Load balancing rule: TCP, port 80 -> 80
Outbound rule: not configured
After deployment, the VMs in the backend pool can receive requests but cannot initiate outbound connections to the internet. What is the most likely cause?
A) HTTP health probe is not compatible with TCP load balancing rules B) Standard SKU Load Balancer blocks outbound traffic by default and there's no outbound rule nor NAT Gateway associated C) The backend pool needs at least three instances for outbound traffic to be allowed D) Standard SKU Public IPs don't support outbound traffic associated with Load Balancers
Question 3 — True or False
An Internal Load Balancer in Azure can be configured with a static frontend IP within a subnet, and this IP remains accessible even when all VMs in the backend pool are failing health probes.
True or False?
Question 4 — Technical Scenario
You administer a three-tier application in Azure. The application tier (app tier) should not be directly accessible from the internet but needs to receive load-balanced traffic from the web tier. The database tier should receive traffic only from the application tier.
A colleague proposed the following architecture:
Internet -> Public Load Balancer -> Web VMs (public subnet)
|
Internal Load Balancer
|
App VMs (private subnet)
|
Internal Load Balancer
|
DB VMs (private subnet)
Which statement correctly describes the role of components in this architecture?
A) The Public Load Balancer could be replaced by an Internal Load Balancer with a public IP assigned to the frontend B) The two Internal Load Balancers must be in the same VNet for routing to work C) The Internal Load Balancer distributes traffic only within a VNet or network connected via peering or VPN, without exposing a public IP D) The Internal Load Balancer requires that backend pool VMs be in the same subnet as its frontend IP
Question 5 — Multiple Choice
When creating a health probe in an Azure Load Balancer Standard, what is the expected behavior when all instances in the backend pool fail the health probe simultaneously?
A) The Load Balancer stops accepting new connections on the frontend and returns TCP RST error to clients B) The Load Balancer enters preservation mode and distributes traffic equally among all instances, regardless of probe status C) The Load Balancer temporarily removes the frontend IP until at least one instance recovers D) The Load Balancer keeps the frontend IP active but silently drops packets until an instance recovers
Answer Key and Explanations
Answer Key — Question 1
Answer: A
Azure Load Balancer supports three distribution modes: 5-tuple hash (default), Client IP (2-tuple: source and destination IP), and Client IP and protocol (3-tuple). When the requirement is session affinity without cookies, Client IP mode is appropriate as it ensures requests from the same source IP always reach the same VM.
Alternative B introduces protocol as a third tuple, which would break affinity when the same client uses different ports in distinct HTTPS connections. Alternatives C and D use the default hash or combinations that don't guarantee affinity by source IP alone. The critical point here is that affinity cookies are a feature of Application Gateway, not Load Balancer.
Answer Key — Question 2
Answer: B
Azure Load Balancer Standard doesn't provide implicit outbound connectivity. In the Basic SKU, there was implicit SNAT; in Standard, this was intentionally removed to give explicit control to administrators. Without a configured Outbound Rule in the Load Balancer or a NAT Gateway associated with the subnet, VMs with private IPs cannot initiate connections to the internet.
Alternative A is false: HTTP health probes and TCP rules coexist without conflict. Alternative C invents a minimum quantity requirement that doesn't exist. Alternative D is wrong because the problem isn't the public IP itself, but the absence of a configured outbound route for traffic originating from the VMs.
Answer Key — Question 3
Answer: False
When all instances in a backend pool fail the health probe, Azure Load Balancer enters probe down recovery behavior: it resumes distributing traffic to all instances, treating them as if they were healthy. This behavior prevents the service from becoming completely inaccessible due to a generalized probe failure.
Therefore, the frontend IP remains accessible, but the protection mechanism is different from what the statement suggests. The statement implies the IP would be accessible and traffic would simply be dropped, which doesn't reflect actual behavior. Understanding this distinction is important for diagnosing scenarios where traffic reaches apparently inactive instances.
Answer Key — Question 4
Answer: C
The Internal Load Balancer operates exclusively with private IP addresses. Its frontend IP is allocated within a VNet subnet and is accessible only to resources within the same VNet, or from networks connected via VNet Peering or VPN/ExpressRoute. It never exposes a public IP.
Alternative A is wrong because an Internal Load Balancer doesn't accept public IP on the frontend, by definition. Alternative B is incorrect: two Internal Load Balancers can be in different VNets connected via peering. Alternative D represents a common misconception: backend pool VMs can be in different subnets from the frontend IP subnet, as long as they belong to the same VNet or connected network.
Answer Key — Question 5
Answer: B
This is the probe down behavior in Azure Load Balancer Standard: when all instances fail simultaneously, the load balancer doesn't drop traffic or remove the frontend. Instead, it distributes connections among all pool instances, temporarily ignoring probe results. This mechanism is called "all down" behavior and was designed to avoid total service blackhole.
Alternative A describes behavior that doesn't occur: the frontend remains active. Alternative C is false because the frontend IP is never automatically removed by the Load Balancer in response to probe failures. Alternative D confuses the behavior with that of a firewall or NSG, which drop packets silently. The Load Balancer, in this scenario, attempts to deliver traffic, not drop it.