Technical Lab: Choose between public and internal load balancers
Questions
Question 1 — Multiple Choice
A company hosts a payment API on virtual machines within a private subnet in Azure. This API is consumed exclusively by a backend service running on another subnet in the same VNet. The architecture team needs to distribute traffic between API instances in a resilient manner.
Which type of load balancer is most suitable for this scenario, and why?
A) Public Load Balancer, because it offers greater availability by exposing a public IP for balancing.
B) Internal Load Balancer, because it distributes traffic between resources within the same VNet without exposing the workload to external traffic.
C) Internal Load Balancer, but only if the VMs are in different availability zones.
D) Public Load Balancer with NSG rules blocking external access, ensuring security without sacrificing balancing.
Question 2 — Technical Scenario
A network engineer configured a Public Load Balancer for a set of VMs hosting an internet-facing web application. After deploying the solution, he notices that the VMs cannot initiate outbound connections to external endpoints, such as third-party APIs, even with correct NSG rules.
Frontend IP: 20.x.x.x (Public)
Backend pool: vm-web-01, vm-web-02
Load balancing rule: TCP 80, TCP 443
Outbound rules: none configured
What is the most likely cause of the problem?
A) The VMs need their own public IP associated with the NIC to have outbound access.
B) The Public Load Balancer does not support outbound traffic unless an Outbound Rule or a NAT Gateway is explicitly configured.
C) The NSG is blocking outbound traffic on the subnet, preventing any external communication regardless of the load balancer.
D) The Standard Load Balancer does not allow VMs without public IP to make outbound calls to the internet.
Question 3 — True or False
An Internal Load Balancer in Azure can receive a frontend IP address that belongs to a different subnet from the one where the backend pool VMs are located, as long as both subnets are part of the same VNet.
Question 4 — Technical Scenario
An organization has a three-tier architecture: public frontend, application layer, and database. The team needs to ensure that:
- The frontend is accessible from the internet
- The application layer is accessible only by the frontend
- The database is accessible only by the application layer
Layer | Suggested Load Balancer Type
---------------|-----------------------------
Frontend | ?
Application | ?
Database | ?
Which combination represents the correct architecture?
A) Public Load Balancer for all three layers, using NSGs to control flow.
B) Public Load Balancer for the frontend; Internal Load Balancer for the application layer; no load balancer for the database.
C) Public Load Balancer for the frontend; Internal Load Balancer for the application layer; Internal Load Balancer for the database.
D) Internal Load Balancer for all three layers, with a NAT Gateway providing external access to the frontend.
Question 5 — Multiple Choice
When comparing Azure Load Balancer Basic SKU with Standard SKU, which statement correctly describes a relevant difference for choosing between public and internal in a production context?
A) The Basic SKU supports availability zones, while the Standard does not offer this feature for Internal Load Balancers.
B) The Standard SKU is mandatory for production scenarios with Internal Load Balancer, as the Basic does not support backend pools with VMs in availability sets.
C) The Standard SKU offers availability zone support and 99.99% SLA, while the Basic offers no SLA and does not support zone-redundancy, making it unsuitable for critical production workloads.
D) The Basic SKU supports Outbound Rules for Public Load Balancers, which positively differentiates it from the Standard in controlled outbound scenarios.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
An Internal Load Balancer (ILB) receives a private frontend IP address, routable only within the VNet (or connected networks via peering/VPN). It is the natural choice when the service consumer is internal to the infrastructure, as it never exposes the backend to internet-originated traffic.
Alternative A is wrong in assuming that availability depends on public exposure. Alternative C introduces a false restriction: the ILB does not require VMs to be in different zones. Alternative D represents a dangerous anti-pattern: using a public IP and relying solely on NSGs to isolate traffic is a fragile and unnecessary architectural choice when traffic is purely internal.
Answer Key — Question 2
Answer: B
In the Standard SKU, VMs associated with a Public Load Balancer without their own public IP depend on an Outbound Rule configured on the load balancer itself or a NAT Gateway on the subnet to establish outbound connections. Without this, outbound traffic is blocked by default, which is a behavior change from the Basic SKU.
Alternative A is incorrect: associating a public IP directly to the NIC would work, but it's not necessary and represents a workaround, not the cause of the problem. Alternative C shifts focus to the NSG without evidence that it's misconfigured. Alternative D confuses the Standard behavior with a non-existent limitation: the problem is not the absence of public IP on VMs, but the absence of an outbound rule.
Answer Key — Question 3
Answer: False
The frontend IP address of an Internal Load Balancer must belong to the subnet configured in the load balancer's frontend. This IP is allocated within the address range of that specific subnet. It's not possible to assign a frontend IP from a different subnet, even if they're in the same VNet. The ILB frontend subnet defines the scope of the private address used. Confusing "same VNet" with "any subnet in the VNet" is a common misconception that can lead to addressing planning errors.
Answer Key — Question 4
Answer: C
Each layer has a distinct access profile. The Public Load Balancer on the frontend is the only entry point from the internet. The application layer should only be accessible by the frontend, which justifies an Internal Load Balancer with private IP. The database, although it might not necessarily need a load balancer if there's only one instance, in high availability scenarios with multiple replicas also benefits from an ILB, keeping all traffic restricted to the VNet.
Alternative B is partially correct but omits the ILB for the database, which is inadequate in production architectures with multiple instances. Alternative A is an anti-pattern for reasons already discussed in Question 1. Alternative D would make the frontend directly inaccessible from the internet without an additional translation layer, introducing unnecessary complexity.
Answer Key — Question 5
Answer: C
The Standard SKU was designed for production workloads: it offers availability zone support (zone-redundant and zonal), 99.99% SLA, and detailed diagnostics via Azure Monitor. The Basic SKU offers no formal SLA, does not support zone-redundancy, and has backend pool scaling limitations.
Alternative A reverses the facts: it's the Standard, not the Basic, that supports availability zones. Alternative B is wrong in stating that the Basic doesn't support VMs in availability sets. Alternative D is incorrect: the Basic does not support Outbound Rules; this feature is exclusive to the Standard. Understanding these differences is fundamental for justifying SKU choice in projects involving both Public and Internal Load Balancers in critical environments.