The AZ-104 networking domain (15–20%) lists "configure public IP addresses," "configure an internal or public load balancer," and "troubleshoot load balancing" as separate items in the official skills outline. In our question bank, nearly 30 questions involve public IPs and more than 20 ask about Load Balancer SKUs, health probes, and session persistence, with Application Gateway, Front Door, and Traffic Manager appearing among the answer options. If you memorize four similarly named load balancing services without a rule for telling them apart, they blur together in the exam room.
This article covers public IP SKUs and allocation methods, the two questions that pick one of the four load balancing services, Azure Load Balancer components and session persistence, a troubleshooting order for when traffic doesn't arrive, and the 2026 change to how VMs reach the internet by default. Basic SKU public IPs and the Basic Load Balancer were retired on September 30, 2025, so anything older material says about the Basic SKU needs to be reread with that in mind.
---
Public IP Addresses: Getting a Number That Doesn't Change
If a company's main phone number changed every month, customers and partners' firewall administrators alike would struggle. Public IP addresses, which let the internet reach Azure resources, are similar: the SKU and allocation method you pick decide whether the address stays the same and how secure it is by default.
| Item | Standard | Basic (retired September 30, 2025) | |------|------|------| | Allocation method | Static only | Dynamic or static for IPv4 | | Default security | Closed to inbound by default; an NSG must allow traffic | Open by default | | Availability zones | Zone-redundant, zonal, or non-zonal | Not supported | | Routing preference | Supported (Microsoft network or internet routing) | Not supported | | Global tier | Supported (frontend for a cross-region load balancer) | Not supported |
Static allocation assigns the address at creation and keeps it until you delete the public IP resource; dynamic allocation releases it when the associated resource stops In regions with availability zones, a Standard public IP created without a zone now behaves as zone-redundant A public IP's availability zone can't be changed after creation When you need a contiguous range of public IPs, create a public IP prefix and allocate addresses from it The new Standard v2 public IP can currently be attached only to a Standard v2 NAT gateway
Exam tip: "The address registered in a partner's firewall must not change even when the VM restarts" calls for static allocation. Standard SKU supports only static, so choosing Standard solves it automatically. If "RDP fails after attaching a Standard public IP," first check whether an NSG has an inbound allow rule.
---
Pick One of Four Load Balancing Services With Two Questions
An airport information desk sends people to gates on different floors; an airline's call center routes calls to offices around the world. Both "distribute," but over different ranges and with different information. Microsoft classifies Azure load balancing services along two dimensions: global or regional, and HTTP(S) web traffic or not.
!Choose a load balancing service by answering two questions: scope and traffic type
| Service | Layer | Scope | Key features | Clues in a question | |------|------|------|------|------| | Azure Load Balancer | Layer 4 (TCP, UDP) | Regional (a cross-region tier also exists) | High performance, ultra-low latency, internal or public frontend, outbound rules | "TCP port," "UDP," "internal load balancing," "all ports (HA ports)" | | Application Gateway | Layer 7 (mainly HTTP, HTTPS) | Regional | URL path-based routing, TLS termination, WAF, cookie-based session affinity | "send /images to pool A," "web application firewall," "SSL offload" | | Azure Front Door | Layer 7 (HTTP, HTTPS) | Global | Worldwide edge, caching (CDN), fast failover, WAF | "users worldwide," "nearest edge," "cache static content" | | Traffic Manager | DNS-based | Global | Chooses a regional endpoint through DNS responses; priority, performance, and geographic routing | "at the DNS level," "cross-region failover for non-HTTP services" |
Traffic Manager only steers traffic at the DNS step, so clients move to another region only after their DNS cache expires. That's why Front Door is the better fit for fast cross-region failover of web applications.
Exam tip: Only Load Balancer is named directly in the AZ-104 skills outline, but the other three often appear as wrong options. "URL path," "WAF," or "cookie-based affinity" means a layer 7 service; "TCP/UDP" or "distribute over an internal IP" means Load Balancer.
---
Azure Load Balancer Components, Revisited
A load balancer is a traffic officer that accepts incoming connections and hands them to backend VMs according to rules. A public load balancer receives internet traffic on a public IP, and an internal load balancer receives internal traffic on a private IP in the VNet.
| Component | Role | What to remember | |------|------|------| | Frontend IP configuration | The address clients connect to | A public LB needs a Standard public IP | | Backend pool | VMs or scale set instances that receive traffic | Configured by NIC or by IP address | | Health probe | Checks regularly whether a backend is healthy | TCP, HTTP, HTTPS; source IP is 168.63.129.16 | | Load-balancing rule | Distributes a frontend port to a backend port | Always requires a health probe | | Inbound NAT rule | Forwards a specific port to a specific VM | For example, frontend 50001 → VM1 port 3389; no health probe needed | | Outbound rule | Configures SNAT for backend VMs going to the internet | Used with a public Standard LB |
Standard Load Balancer is "secure by default." Inbound traffic doesn't flow unless an NSG on the backend subnet or NIC allows it. On an internal Standard Load Balancer, an HA ports rule (protocol All, port 0) distributes TCP and UDP flows on every port at once, which is why it often sits in front of network virtual appliances (NVAs) such as firewalls.
Session Persistence: Keeping a User on the Same VM
| Setting | Hash based on | Behavior | |------|------|------| | None (default) | 5-tuple (source IP, source port, destination IP, destination port, protocol) | Even the same client may land on a different VM per connection | | Client IP | 2-tuple (source IP, destination IP) | The same client IP goes to the same VM | | Client IP and protocol | 3-tuple (source IP, destination IP, protocol) | The same client IP and protocol combination goes to the same VM |
Exam tip: "Session data lives in VM memory, so a user must keep connecting to the same VM" means changing session persistence to Client IP. Cookie-based affinity is an Application Gateway feature, not a Load Balancer one.
---
When Traffic Doesn't Reach the Backend
Most load balancing problems fall into two branches: "the health probe fails" or "the probe is healthy, but data doesn't get through." Here is where to look for each symptom.
| Symptom | Common cause | What to check | |------|------|------| | Backend VMs don't respond to the health probe | The app isn't listening on the probe port, or the VM is stopped | Whether the probe port is listening inside the VM, VM state | | The health probe is blocked | An NSG or the VM firewall blocks 168.63.129.16 or the AzureLoadBalancer service tag | Deny rules evaluated before the default AllowAzureLoadBalancerInBound rule | | Probe is healthy but the service port doesn't respond | The app isn't listening on the data port, or an NSG blocks it | The backend port in the load-balancing rule, NSG inbound rules | | Requests from a backend VM to the internal LB frontend fail | Outbound flows from a backend VM to the same internal LB's frontend aren't supported | Test from another VM or change the design | | Inbound traffic stops after moving to Standard | Standard blocks inbound by default | Add an allow NSG rule on the backend subnet or NIC |
To see health as numbers, check two Load Balancer metrics together: Data Path Availability (the path to the frontend) and Health Probe Status (probe results per backend instance). If data path availability is healthy and only the probe status is 0, the problem is on the backend VMs.
Exam tip: If "every VM turns unhealthy after the health probe is changed to HTTP /health," the app either has no /health path or doesn't return 200. An HTTP probe treats only a 200 response as healthy.
---
Outbound Internet Access for VMs: Now You Choose Explicitly
Until now, even a VM without a public IP could reach the internet through a "default outbound access" address that Azure quietly assigned. But that address belongs to Microsoft, can change without notice, and can't be registered in a partner's firewall. So Azure is changing the default behavior.
New virtual networks created with API versions released after March 31, 2026 use private subnets by default (defaultOutboundAccess = false) The Azure portal already defaults to private subnets Existing virtual networks and the VMs in them aren't changed VMs in private subnets need one of the explicit methods below to reach the internet and Microsoft public endpoints
| Explicit outbound method | Characteristics | |------|------| | NAT gateway | Attached per subnet, egresses through static public IPs; once attached, all new outbound connections use the NAT gateway | | Public IP attached directly to the VM | The same address serves inbound and outbound for one VM | | Load Balancer outbound rules | The backend pool of a public Standard LB egresses through the frontend IP | | UDR through a firewall or NVA | Egresses through a device such as Azure Firewall, which can inspect traffic |
Exam tip: "Several VMs without public IPs must reach the internet through a fixed public IP, and inbound connections must not be allowed" is a NAT gateway. If inbound ac