Technical Lab: Create and Configure an Azure Load Balancer
Questions
Question 1 — Multiple Choice
A platform team needs to distribute TCP traffic on port 443 between virtual machine instances located in different availability zones within the same region. The requirement demands that the solution support public IP address and ensure zonal resilience.
Which SKU and frontend type should be used?
A. Basic SKU with static public IP frontend
B. Standard SKU with public IP frontend configured as zone-redundant
C. Basic SKU with public IP frontend configured as zone-redundant
D. Standard SKU with dynamic public IP frontend
Question 2 — Technical Scenario
An engineer configured an internal Standard Azure Load Balancer to distribute traffic between three VMs in a backend pool. The health probe is configured with TCP protocol on port 80. After deployment, logs show that traffic is not reaching any of the VMs, although all are running and responding on port 80 locally.
Frontend IP: 10.0.1.10 (internal)
Backend pool: VM1, VM2, VM3
Health probe: TCP / port 80 / 5s interval / 2 failure threshold
Load balancing rule: port 80 -> port 80, Session persistence: None
NSG on VM subnet: no explicit inbound rule for 10.0.1.10
What is the most likely cause of the problem?
A. Standard SKU does not support internal Load Balancer
B. The NSG on the VM subnet is blocking probe and data traffic from the Load Balancer
C. TCP protocol is not supported in health probes for internal Load Balancers
D. The absence of Session persistence prevents correct traffic routing
Question 3 — True or False
A Standard SKU Azure Load Balancer, when created without any configured outbound rules, automatically provides internet outbound connectivity to VMs in the backend pool, as long as these VMs do not have individual public IPs.
Question 4 — Technical Scenario
A financial application requires that all requests from the same client are always directed to the same VM instance during the session, to preserve local state. The architect configured the Load Balancer with the following rule:
Protocol: TCP
Frontend port: 443
Backend port: 443
Session persistence: Client IP and protocol
Idle timeout: 4 minutes
After three weeks in production, users report sporadic session loss in long connections. The application code has no identified issues.
Which adjustment to the Load Balancer configuration resolves the described problem?
A. Change Session persistence to None to distribute load more evenly
B. Increase the Idle timeout value beyond 4 minutes to cover longer connections
C. Replace the Load Balancer with an Application Gateway, as Load Balancer does not support session persistence
D. Change the health probe protocol from TCP to HTTP to detect session failures
Question 5 — Multiple Choice
A public Standard Load Balancer has a load balancing rule configured with Floating IP enabled. A developer needs to understand how traffic reaches the backend pool VMs with this configuration active.
What differentiates Floating IP behavior from default behavior?
A. The packet delivered to the VM has the Load Balancer frontend IP address as destination IP, not the VM's IP
B. The Load Balancer encapsulates the original packet in a new IP header before delivering it to the VM
C. Traffic is distributed only to the VM with lowest CPU utilization at connection time
D. The VM receives the packet with destination IP rewritten to its own private IP, as in default behavior
Answer Key and Explanations
Answer Key — Question 1
Answer: B
The Standard SKU is the only one that supports availability zones and allows configuring the frontend public IP as zone-redundant, ensuring that the Load Balancer continues operating even if a zone fails. The Basic SKU has no availability zone support, making alternatives A and C invalid regardless of IP configuration. Alternative D is wrong because a dynamic public IP is not supported as a Standard Load Balancer frontend; Standard requires static IP. The wrong choice of Basic SKU in environments with zonal resilience requirements is an architecture error with direct SLA impact.
Answer Key — Question 2
Answer: B
Azure Standard Load Balancer uses IP address 168.63.129.16 as the source for health probes, but data traffic originated by the internal Load Balancer reaches VMs with the client IP as source and the frontend IP as destination. NSGs on VM subnets that don't have explicit rules allowing traffic from the Load Balancer range or probe IP can silently drop packets. The result is that probes fail, the Load Balancer marks all instances as unhealthy and traffic stops. Alternative A is false: Standard SKU supports internal configuration. Alternative C is false: TCP is a valid protocol for health probes. Alternative D represents a common misconception: Session persistence affects distribution hash, not routing itself.
Answer Key — Question 3
Answer: False
As of September 2025, Azure removed implicit default SNAT for VMs in Standard Load Balancer backend pools without configured outbound rules. With Standard SKU, VMs without individual public IP and without explicit outbound rule or associated NAT Gateway do not have internet outbound connectivity. This behavior is opposite to Basic SKU, which still provides implicit SNAT. Relying on Standard's implicit SNAT to guarantee traffic egress is a design error that can result in silent connectivity failures in workloads that need to access external services.
Answer Key — Question 4
Answer: B
The Azure Load Balancer Idle timeout defines how long an inactive TCP connection can be maintained before being terminated by the Load Balancer. The default value of 4 minutes is insufficient for applications with long connections or longer inactivity periods. Increasing the Idle timeout (up to 30 minutes in Standard SKU) keeps the session mapping active longer. Alternative A would eliminate session persistence, worsening the problem. Alternative C is incorrect: Load Balancer supports session persistence via IP hash or IP and protocol. Alternative D is a plausible distractor, but health probes verify instance availability, not individual user session state.
Answer Key — Question 5
Answer: A
With Floating IP enabled (also referenced in some contexts as Direct Server Return), the Load Balancer delivers the packet to the VM with the destination IP preserved as the frontend IP, without rewriting to the VM's private IP. This requires the VM itself to have the frontend IP configured on its network interface or loopback to properly accept and process the packet. This configuration is necessary in scenarios like SQL Server Always On Availability Groups and other topologies that require the VM to "see" the virtual IP. Alternative B describes encapsulation, which is not the mechanism used. Alternative C describes load balancing by CPU metrics, which is not supported in Load Balancer. Alternative D describes exactly the default behavior without Floating IP.