4 of the 11 questions we have for this objective, shown with the answer and the reasoning.
Design and implement Azure Load Balancer and Azure Traffic Manager
Sablewood Insurance runs a three-tier application in a virtual network named vnet-claims. The web tier VMs accept HTTPS from the internet, and the business-logic tier VMs accept gRPC on TCP port 9090 only from the web tier. Security policy states that the business-logic tier must never have a public IP address or public frontend of any kind.
How should you load balance traffic to the business-logic tier?
- ACreate an internal Standard Load Balancer with a frontend IP from the business-logic subnet and a TCP rule on port 9090.An internal load balancer uses a private frontend IP from a subnet of the virtual network, so the business-logic tier is reachable from the web tier without any public exposure.
- BCreate a public Standard Load Balancer and restrict the frontend with a network security group that allows only the web-tier subnet.A public load balancer still allocates a public frontend IP, which violates the policy even if an NSG limits who can connect to it.
- CAdd the business-logic VMs to the same public Standard Load Balancer as the web tier and create a second rule on port 9090.This exposes port 9090 on a public frontend and mixes tiers in one backend pool, violating the no-public-frontend rule for the business-logic tier.
- DCreate a Global Load Balancer with the business-logic VMs as backends.Global (cross-region) Load Balancer only offers public frontends and only accepts regional load balancers as backend pool members, so it cannot provide a private frontend for VMs.
Why: The choice between a public and an internal load balancer is decided by where the clients are. A public load balancer maps a public IP to the backend pool and is for internet-facing tiers; an internal load balancer takes a private IP from a subnet and is for traffic that stays inside the virtual network, over peering, or over VPN and ExpressRoute. Because the policy forbids any public frontend on the business-logic tier, only the internal load balancer qualifies. Restricting a public frontend with an NSG is the common trap, since it still leaves a public IP in place.
Design and implement Azure Load Balancer and Azure Traffic Manager
Orrindale Bank exposes a trading API through a Standard public Load Balancer named lb-trade in East US. A security mandate requires that all inbound internet traffic to lb-trade be inspected by a pair of third-party firewall NVAs (nva-1 and nva-2) deployed in a separate virtual network named vnet-security, without changing the public IP that clients use and without adding user-defined routes to the application subnets. The NVAs support VXLAN encapsulation.
What should you do?
- ADeploy a Gateway Load Balancer in vnet-security with nva-1 and nva-2 in its backend pool, configure internal and external VXLAN tunnel interfaces on the pool, and reference the Gateway Load Balancer frontend from the frontend IP configuration of lb-trade.Gateway Load Balancer chains transparently in front of a consumer Standard public load balancer by linking its frontend to the consumer frontend, and traffic is encapsulated to the NVAs over VXLAN tunnel interfaces; the public IP and routing are unchanged.
- BDeploy an internal Standard Load Balancer in vnet-security with HA ports, and add a user-defined route on the application subnets with the internal load balancer as the next hop.An internal load balancer with HA ports plus UDRs is the classic NVA pattern, but it requires route tables on the application subnets, which the mandate prohibits, and it does not intercept inbound traffic to the existing public frontend.
- CReplace lb-trade with an Application Gateway v2 and add nva-1 and nva-2 to its backend pool.Application Gateway is a layer 7 reverse proxy, so this changes the public IP, terminates connections, and sends HTTP traffic to the NVAs as application backends rather than as inline inspection devices.
- DDeploy a Gateway Load Balancer in the same virtual network as lb-trade and add the two NVAs to the backend pool of lb-trade.NVAs belong in the backend pool of the Gateway Load Balancer, not the consumer load balancer, and the Gateway Load Balancer may live in a different virtual network from the consumer; adding NVAs to lb-trade would send API traffic to the firewalls as if they were API servers.
Why: Gateway Load Balancer is the Standard Load Balancer SKU designed for transparent insertion of network virtual appliances. The provider deploys the Gateway Load Balancer with the NVAs as its backend pool and configures tunnel interfaces (an internal and an external interface) that carry traffic over VXLAN. The consumer then chains it by selecting the Gateway Load Balancer frontend on the frontend IP configuration of their own Standard public load balancer or on a VM public IP. Because the chaining is done at the frontend, no UDRs are needed, the public IP does not change, and the provider can be in a different virtual network or even a different subscription. The internal load balancer with HA ports is a valid NVA design but requires routes, which the scenario forbids.
Design and implement Azure Load Balancer and Azure Traffic Manager
Tessaline Payments runs a TCP settlement gateway behind a Standard public Load Balancer in East US and an identical deployment behind a Standard public Load Balancer in West US. Partner banks whitelist a single static IP address and cannot tolerate DNS caching delays during failover. The company wants automatic failover between regions in seconds, with clients continuing to connect to the same IP.
What should you deploy?
- AA Standard Global Load Balancer with the two regional public load balancers in its backend poolGlobal Load Balancer provides a single static anycast public IP, uses the regional load balancers as backends, and fails over at the network layer without depending on client DNS behavior.
- BAn Azure Traffic Manager profile with the priority routing method and both regional frontends as external endpointsTraffic Manager is DNS-based, so each region keeps its own IP and failover is delayed by the DNS TTL and client resolver caching, which the partner banks cannot tolerate.
- CA third Standard Regional Load Balancer in Central US with VMs from both regions in its backend poolA regional load balancer can only include backend instances from the same region as the load balancer; it cannot span East US and West US VMs.
- DAn Azure Front Door Standard profile with the two load balancer frontends as originsFront Door terminates HTTP and HTTPS only and does not forward arbitrary TCP settlement traffic; its anycast IPs are also not guaranteed to be a single dedicated static address.
Why: The deciding constraints are a single static IP, a non-HTTP TCP protocol, and failover that does not depend on DNS. Global (cross-region) Load Balancer is the Standard tier built for exactly this: it exposes one static anycast frontend, routes clients to the closest healthy regional Standard public load balancer, and moves traffic in near real time when a region fails its health check. Traffic Manager is the classic trap because it also does cross-region failover, but through DNS, which inherits TTL delays and changes the IP the client sees. A regional load balancer cannot hold backends from another region.
Design and implement Azure Load Balancer and Azure Traffic Manager
Kestrelbay Networks has deployed two firewall NVAs (fw-1 and fw-2) in an active-active pair behind an internal Standard Load Balancer named lb-fw in a hub virtual network. Spoke subnets route all traffic to the frontend IP of lb-fw. The NVAs must receive every TCP and UDP port, and the team wants to avoid creating and maintaining a rule for each port.
How should you configure the load balancing rule on lb-fw?
- ACreate a single rule with protocol All, frontend port 0, and backend port 0 (HA ports).An HA ports rule, defined as protocol All with frontend and backend port 0, load balances every TCP and UDP flow on all ports and is supported on internal Standard Load Balancer, which is exactly the NVA active-active pattern.
- BCreate one rule per well-known port (TCP 80, 443, 22, 3389) with protocol TCP.Per-port rules only cover the listed ports; other TCP ports and all UDP traffic would be dropped, and the rules must be maintained as applications change.
- CCreate a single rule with protocol TCP, frontend port 0, and backend port 0, and enable Floating IP.HA ports require protocol All; a port 0 rule with protocol TCP is not valid, and Floating IP alone does not forward all ports.
- DCreate an inbound NAT rule with a frontend port range of 1-65535 targeting the backend pool.Inbound NAT rules map ports to individual backend instances for direct access, not for load balancing flows across the NVA pair.
Why: A load balancing rule normally maps one frontend port to one backend port for a given protocol. The HA ports variant, available only on internal Standard Load Balancer, uses protocol All and port 0 on both sides so that a single rule balances every flow on every port; it was created precisely for network virtual appliance scale-out and high availability. The per-port approach is the trap because it looks careful but fails for unknown ports and UDP. Inbound NAT rules are a different construct intended for port forwarding to a specific instance.