Technical Lab: Implement a load balancing rule
Questions
Question 1 — Multiple Choice
An engineer configures a public Azure Load Balancer to distribute HTTP traffic across three virtual machines. After deployment, they notice that all requests from the same client always reach the same VM, even with multiple sessions opened at different times.
Which load balancing rule configuration is responsible for this behavior?
A) The rule protocol is set to TCP instead of HTTP
B) The Session persistence option is set to Client IP
C) Floating IP is enabled on the load balancing rule
D) The Idle timeout is configured with a value below default
Question 2 — Technical Scenario
An architect needs to publish an internal service running on port 8080 across three VMs, but wants clients to access the service through port 80. The Load Balancer is internal type (ILB).
What is the correct configuration to apply to the load balancing rule?
Frontend IP: 10.0.1.10
Frontend port: ?
Backend port: ?
Protocol: TCP
A) Frontend port: 80 / Backend port: 80, as ports must be identical in TCP rules
B) Frontend port: 8080 / Backend port: 80, mapping the source port to the destination port
C) Frontend port: 80 / Backend port: 8080, allowing the Load Balancer to translate the port between frontend and backend
D) Frontend port: 80 / Backend port: 0, as port zero instructs the Load Balancer to preserve the client's original port
Question 3 — True or False
A load balancing rule in Azure Load Balancer (Standard SKU) can be created without an associated health probe. In this case, the Load Balancer distributes traffic among all backend pool instances regardless of their health status.
Question 4 — Technical Scenario
An operations team maintains a cluster of servers that process financial transactions. They use an Azure Load Balancer Standard with the following configured rule:
Protocol: TCP
Frontend port: 443
Backend port: 443
Session persistence: None
Floating IP: Enabled
When inspecting logs on the VMs, the team observes that the destination IP address of received packets is the Load Balancer frontend IP, not the VM's own private IP. This behavior is causing application failures, as it expects to receive packets addressed to its own IP.
What is the root cause of the problem?
A) TCP protocol is not compatible with Standard SKU for traffic on port 443
B) The Floating IP option is enabled, causing the Load Balancer not to perform DNAT and deliver the packet with the original frontend destination IP
C) The absence of Session persistence prevents the Load Balancer from correctly rewriting the IP header
D) The backend pool lacks a Network Security Group allowing traffic on port 443, causing incorrect address rewriting
Question 5 — Multiple Choice
When configuring a load balancing rule in a public Azure Load Balancer Standard, what is the effect of enabling the "HA Ports" option?
A) The rule starts load balancing all protocols and all ports simultaneously, replacing the need for individual rules per port; this feature is only available on internal Load Balancers
B) The rule enables high availability load balancing exclusively for UDP traffic on all ports, keeping TCP with individual rules
C) The rule automatically replicates the configuration to all Azure regions where the Load Balancer has registered backends
D) The rule starts accepting connections on any frontend port, but still requires the backend to be configured with corresponding individual ports
Answer Key and Explanations
Answer Key — Question 1
Answer: B
The Session persistence option (also called sticky sessions or source affinity) controls how the Load Balancer distributes requests from the same client. When configured as Client IP, the algorithm ensures that all requests originating from the same IP address are always forwarded to the same backend instance, regardless of whether they are new or distinct sessions.
The main misconception represented by the distractors is confusing persistence behavior with protocol or timeout configurations. TCP protocol (alternative A) has no relation to session affinity. Floating IP (alternative C) changes DNAT behavior, not client-based routing. Idle timeout (alternative D) only controls termination of idle connections.
Choosing a distractor here would lead the engineer to modify irrelevant parameters without resolving the observed behavior.
Answer Key — Question 2
Answer: C
Azure Load Balancer supports asymmetric port mapping between frontend and backend. This allows the frontend to expose a different port than the one backend servers actually listen on. In the described scenario, the client accesses port 80, and the Load Balancer translates and forwards traffic to port 8080 on the VMs.
Alternative A is wrong because ports don't need to be identical. Alternative B reverses the mapping logic (client accesses 8080, backend receives 80, which doesn't match the requirement). Alternative D is invalid: port 0 is not an accepted value in standard load balancing rules for this purpose.
This feature is often underutilized but is essential for scenarios where the application cannot or should not listen on privileged ports.
Answer Key — Question 3
False
In Azure Load Balancer Standard SKU, a health probe is mandatory for a load balancing rule to function correctly. Without an associated probe, the Load Balancer considers all backend pool instances as unavailable and forwards no traffic.
This behavior differs from the Basic SKU, which in some scenarios allows operation without probe with less restrictive behavior. The question's statement describes a behavior that doesn't occur in Standard SKU, making it false.
Understanding this distinction is critical in troubleshooting scenarios where traffic simply doesn't reach the backend after creating a rule.
Answer Key — Question 4
Answer: B
Floating IP (also known as Direct Server Return in some documentation) fundamentally changes the Load Balancer's address translation behavior. With this option enabled, the Load Balancer does not perform DNAT on the packet's destination IP address. The packet arrives at the VM with the destination IP being the Load Balancer frontend IP, not the VM's network interface private IP.
This feature is designed for specific scenarios, such as SQL AlwaysOn clusters and other patterns that require the application to directly process the frontend address. Applications not developed for this model will fail when receiving packets addressed to an IP they don't recognize as their own.
Alternatives C and D introduce incorrect causalities: session persistence and NSGs have no relation to destination IP address rewriting.
Answer Key — Question 5
Answer: A
The HA Ports functionality allows creating a single load balancing rule that covers all protocols (TCP and UDP) and all ports simultaneously, instead of requiring a separate rule per port and protocol. This feature is especially useful for Network Virtual Appliances (NVAs) that need to process arbitrary traffic.
The critical and often overlooked restriction is that HA Ports is exclusively available on internal Load Balancers (ILB). A public Load Balancer does not support this configuration.
Alternative B is wrong because HA Ports covers TCP and UDP, not just UDP. Alternative C describes geographic replication behavior that doesn't exist in this context. Alternative D contradicts the nature of the functionality, which eliminates exactly the need to specify ports individually on the backend.