Skip to main content

Technical Lab: Map requirements to features and capabilities of Azure Load Balancer

Questions​

Question 1 — Multiple Choice​

An architecture team needs to distribute inbound TCP traffic on port 443 to a set of virtual machines in a private subnet. The requirement is that no public IP address should be exposed on the VMs and that the load balancer operates at layer 4. Additionally, the source traffic is exclusively internal to the virtual network.

Which SKU and type of Azure Load Balancer correctly meet this scenario?

A. Basic SKU, public type
B. Standard SKU, public type
C. Standard SKU, internal type
D. Basic SKU, internal type

Question 2 — Technical Scenario​

An engineer configured a public Azure Load Balancer Standard with the following backend pool and health probe:

Health Probe:
  Protocol: TCP
  Port: 80
  Interval: 5s
  Unhealthy threshold: 2

Backend Pool:
  VM-A: responding on port 80
  VM-B: local firewall blocking port 80
  VM-C: responding on port 80

After a few minutes, users report that approximately one-third of requests fail with timeout. The engineer verifies that the load balancer is active and the VMs are running.

What is the most likely cause of the problem?

A. The health probe interval is too short, causing false negatives on all VMs
B. VM-B is not responding to the health probe and continues to receive traffic due to failure in backend removal
C. VM-B is being correctly excluded from the pool, but the hash algorithm redistributes traffic disproportionately
D. The Standard SKU requires the health probe to use HTTP instead of TCP to detect failures correctly

Question 3 — True or False​

An internal Azure Load Balancer Standard, without any outbound rules configured, automatically guarantees outbound internet connectivity for VMs in the backend pool, the same way the Basic SKU does by default.

Question 4 — Technical Scenario​

A financial application requires that all connections from the same client are always processed by the same backend instance during the session, as transaction state is maintained locally on the VM. The environment uses a public Azure Load Balancer Standard.

The engineer configures the load balancing rule as follows:

Load Balancing Rule:
  Frontend IP: pip-finance-prod
  Protocol: TCP
  Port: 443
  Backend Port: 443
  Session Persistence: None
  Idle Timeout: 4 min

After deployment, users report intermittent session loss.

Which change resolves the problem with the least configuration change?

A. Increase the Idle Timeout to 30 minutes
B. Change Session Persistence to "Client IP"
C. Change Session Persistence to "Client IP and Protocol"
D. Replace the Load Balancer with an Application Gateway with cookie-based session affinity

Question 5 — Multiple Choice​

An organization needs the Azure Load Balancer to forward inbound traffic directly to the network interface of each VM individually, instead of using a shared virtual IP address on the frontend. The goal is to preserve the original destination IP of the packet so the application can inspect it.

Which Azure Load Balancer feature allows this behavior?

A. Outbound Rules
B. Floating IP (Direct Server Return)
C. High Availability Ports
D. Inbound NAT Rules

Answer Key and Explanations​

Answer Key — Question 1​

Answer: C

An internal Load Balancer (ILB) does not expose a public IP address and distributes traffic within the virtual network or networks connected via peering or VPN. The Standard SKU is mandatory when there are production requirements with SLA, availability zone support, and integration with other resources like NAT Gateway. The Basic SKU does not offer formal SLA and has scale and security limitations. The public type would be inadequate because it would require a public IP on the frontend, contradicting the requirement. The Basic internal combination would be functionally possible in simple scenarios, but is not the correct choice for environments that require robustness and is being discontinued by Microsoft.

Answer Key — Question 2​

Answer: B

The TCP health probe on port 80 periodically checks if each VM responds. VM-B has the local firewall blocking this port, so the probe fails for it. When the number of consecutive failures reaches the unhealthy threshold (2 in this case), the Load Balancer removes VM-B from the active pool and stops sending traffic to it.

The conceptual error of the distractors is assuming that the Load Balancer ignores the probe result or that the TCP protocol is insufficient. In the described configuration, the 5-second interval with threshold of 2 is perfectly functional. Alternative C describes a behavior that doesn't exist: after VM-B removal, traffic is redistributed equally between VM-A and VM-C. Alternative D is false: the Standard SKU supports TCP health probes normally.

The symptom of "one-third of requests fail" indicates that VM-B was still receiving traffic before being marked as unhealthy, during the window between checks. Once removed, the failures cease.

Answer Key — Question 3​

Answer: False

This is an important breaking point between SKUs. The Basic SKU provides default outbound access for VMs in its backend pool, without explicit configuration. The Standard SKU does not provide this behavior: VMs in an internal Standard Load Balancer or without configured outbound rules do not have outbound connectivity guaranteed by the load balancer.

To guarantee internet outbound with Standard SKU, it's necessary to explicitly configure Outbound Rules on the public Load Balancer, associate a NAT Gateway to the subnet, or assign an individual public IP to the VM's NIC. Assuming that Basic behavior applies to Standard is an operational error that can cause silent connectivity failures in production.

Answer Key — Question 4​

Answer: B

The configuration with Session Persistence: None uses the 5-tuple hash algorithm (source IP, source port, destination IP, destination port, protocol). Since the source port changes with each new TCP connection, the same client can be directed to different VMs on reconnections, breaking the local session state.

Changing to "Client IP" instructs the Load Balancer to use 2-tuple hash (source IP and destination IP), ensuring that all connections from the same client IP are always forwarded to the same VM.

Alternative C ("Client IP and Protocol") uses 3 tuples and would be appropriate if the client used multiple protocols, which is not the case here. Increasing the Idle Timeout (A) doesn't solve the affinity problem on new connections. Replacing with Application Gateway (D) would solve the problem, but represents a disproportional architectural change when the solution is available in the Load Balancer itself.

Answer Key — Question 5​

Answer: B

Floating IP, also known as Direct Server Return (DSR), changes the default Load Balancer behavior by preserving the frontend destination IP in the packet delivered to the VM. Without Floating IP, the Load Balancer performs DNAT and replaces the destination IP with the VM's IP before delivery. With Floating IP enabled, the packet arrives at the VM's NIC with the frontend virtual IP as destination, allowing the application to inspect the original address.

Outbound Rules (A) control only outbound traffic. High Availability Ports (C) enable load balancing of all protocols and ports on a single internal Load Balancer, unrelated to destination IP preservation. Inbound NAT Rules (D) map specific frontend ports to individual instances, but also perform DNAT without preserving the original IP.