Technical Lab: Identify appropriate use cases for Azure Load Balancer
Questions
Question 1 — Multiple Choice
An infrastructure team needs to distribute TCP traffic on port 1433 among three SQL Server instances hosted on virtual machines within the same virtual network. The requirement is that the load balancing operates at the transport layer and that sessions from the same client are always directed to the same instance during the connection.
Which combination of resource and configuration correctly meets this requirement?
A) Azure Application Gateway with cookie-based session affinity
B) Azure Load Balancer internal with load balancing rule and Session Persistence configured as "Client IP"
C) Azure Load Balancer public with inbound NAT rule and persistence disabled
D) Azure Traffic Manager with "Session" routing method pointing directly to the VMs
Question 2 — Technical Scenario
An engineer configured an Azure Load Balancer public to distribute HTTP traffic between two VMs. The VMs are in the backend pool, health probes are configured on port 80, and load balancing rules are active. However, after deployment, no requests reach the VMs.
The engineer verifies the following:
Health probe status: Degraded
Backend pool: 2 associated VMs
Load balancing rule: port 80 -> port 80
Frontend IP: associated to a Public IP
When inspecting the VMs, he finds that the Network Security Group (NSG) associated with each VM's NIC has no explicit inbound rules.
What is the most likely cause of the failure?
A) The public Load Balancer requires VMs to be in an Availability Set mandatorily
B) The health probe cannot reach the VMs because the NSG blocks inbound traffic, including Load Balancer probes
C) The public frontend IP cannot be associated with a Load Balancer without an Azure Firewall in front
D) Load balancing rules require frontend port and backend port to be different
Question 3 — True or False
The Azure Load Balancer Standard supports load balancing rules for traffic on all ports simultaneously, using a single rule object with the HA Ports option enabled, with this feature being available in both internal and public SKUs.
True or False?
Question 4 — Technical Scenario
A financial company operates a set of microservices on VMs distributed across two Azure regions: East US and West Europe. The business requirement demands that, in case of complete regional failure, traffic is automatically redirected to the healthy region. The latency between regions is acceptable for failover.
The architect proposes using exclusively Azure Load Balancer to solve this requirement.
What is the problem with this approach?
A) Azure Load Balancer Standard does not support backends with public IPs in other regions
B) Azure Load Balancer operates within a single region and has no native mechanism for routing or failover between regions
C) Azure Load Balancer requires all VMs to be in the same virtual network, which makes cross-region usage impossible
D) Azure Load Balancer does not support TCP protocols in high availability scenarios with multiple backends
Question 5 — Multiple Choice
A video streaming solution uses the UDP protocol for real-time packet transmission. The team needs to load balance this traffic among a set of media servers in an Azure virtual network, without inspecting request content.
Which Azure service is most suitable for this scenario?
A) Azure Application Gateway, as it offers native support for media protocols
B) Azure Load Balancer, as it operates at layer 4 and supports UDP traffic load balancing
C) Azure Front Door, as it is optimized for global streaming with low latency
D) Azure API Management, as it allows traffic routing based on custom policies
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Azure Load Balancer operates exclusively at layer 4 (transport), making it suitable for TCP traffic on any port, including 1433. The Session Persistence configuration with "Client IP" mode ensures that requests originating from the same source IP address are always forwarded to the same backend, meeting the session affinity requirement.
The main misconception represented by the distractors is confusing the operating layer: Application Gateway (A) operates at layer 7 and uses HTTP cookies for affinity, which doesn't apply to pure TCP traffic like SQL Server. Traffic Manager (D) is a DNS service and has no session visibility or direct VM connectivity. Option C ignores the session persistence requirement.
Choosing Application Gateway in this scenario would generate unnecessary overhead and potentially incompatibility with the TDS protocol used by SQL Server.
Answer Key — Question 2
Answer: B
Azure Load Balancer health probes originate from a reserved Azure infrastructure IP address (168.63.129.16). When an NSG is associated with the VM's NIC and has no explicit inbound rule allowing this traffic, the probes are blocked. As a result, the Load Balancer marks backends as unhealthy and stops forwarding traffic to them.
The conceptual error represented by other distractors is attributing the failure to non-existent structural restrictions: Availability Sets (A) are not mandatory for public Load Balancer; Azure Firewall (C) is not a prerequisite for public IP association; and frontend/backend port correspondence (D) is optional, not mandatory.
The practical consequence of not understanding this behavior is deploying seemingly correct solutions that fail silently due to NSG blocking, which is one of the most common causes of incorrect diagnosis in Azure environments.
Answer Key — Question 3
Answer: False
The HA Ports feature is only available in Azure Load Balancer Standard in internal (Internal Load Balancer) mode. It is not supported in public Load Balancer. This restriction exists because HA Ports was designed for network virtual appliance (NVA) scenarios in hub-and-spoke topologies, where the internal load balancer needs to inspect and distribute traffic of any protocol and port without configuring individual rules.
Assuming HA Ports works in public SKU leads to design errors in network security architectures, especially when trying to expose a set of firewalls or NVAs directly to the internet using this approach.
Answer Key — Question 4
Answer: B
Azure Load Balancer is a regional resource. It distributes traffic among backends within the same region and has no geographic routing capability, regional failure detection, or traffic redirection between regions. For this requirement, the correct service is Azure Traffic Manager (DNS-based) or Azure Front Door (global anycast-based with layer 7 failover).
Other distractors introduce incorrect technical restrictions: Load Balancer Standard supports backends with public IPs via IP-based backend pool functionality (A is partially inaccurate in context); VMs in different virtual networks can be added to the backend pool via peering or direct IP (C is incorrect); and TCP support in high availability scenarios is exactly one of Load Balancer's strengths (D is incorrect).
Using exclusively Load Balancer for cross-region failover would result in total unavailability during regional failure, with no automatic recovery mechanism.
Answer Key — Question 5
Answer: B
Azure Load Balancer operates at layer 4 of the OSI model and supports TCP and UDP protocols, without inspecting request content. This makes it directly suitable for load balancing UDP video streaming traffic among media servers in a virtual network.
The central misconception in other distractors is applying layer 7 services to a layer 4 problem: Application Gateway (A) does not support UDP; Front Door (C) also operates at layer 7 focusing on HTTP/HTTPS and is not designed for internal UDP streaming traffic; API Management (D) is aimed at REST/SOAP APIs and has no UDP traffic routing capability.
Choosing a layer 7 service for UDP traffic would result in complete connectivity failure, as these services simply do not process this type of protocol.