Azure Standard Load Balancer distributes supported network flows only when frontend rules, backend membership, health probes and network controls work together. This AZ-104 tutorial isolates probe failures, incorrect ports and security-path problems without confusing a healthy VM with a healthy application.
A frontend address is not evidence that a backend is available
An Azure Standard Load Balancer can distribute TCP or UDP traffic among backend instances, but only when its frontend configuration, backend pool, load-balancing rules and health probes form a functioning path. An IP address existing in the portal does not prove the virtual machines behind it are healthy, the required NSG and routes permit traffic, or the application listens on the configured port.
Azure Load Balancer is a Layer 4 service for distributing TCP or UDP connections to configured backends. Decide whether the workload really needs that transport-level routing or instead requires application-aware HTTP routing, a WAF or global edge handling. Comparing Azure load-balancing services helps separate those needs before an administrator configures a specific load balancer. Once the Layer 4 choice is justified, verify frontend IPs, rules, backend memberships, health probes and supported SKU behavior instead of compensating for an incorrect architectural choice with more NSG changes.
These decisions separate two different responsibilities. An AZ-104 Azure administrator troubleshoots unhealthy backends, pool membership and probe definitions in a deployed service. AZ-700 Azure network engineering extends that reasoning to service selection, application delivery and network architecture. Repairing a bad probe path is not the same reader problem as deciding whether Application Gateway or a Layer 4 load balancer fits a new workload.
Choose internal versus public from clients
A public load balancer exposes a public frontend address for eligible inbound flows. An internal load balancer uses a private frontend inside the virtual network and is appropriate for services that should be reached only by authorized connected networks. The classification is about network reachability, not whether a business operation is safe for everyone who reaches it.
A fictional employee API has two backend VMs in the same regional service. If the API must be reachable only by the company’s web tier, an internal frontend may be preferable. If it accepts direct internet clients, the public exposure plan needs deliberate NSG rules, application authentication and appropriate perimeter controls. A load balancer does not inspect HTTP user permissions or replace an application gateway.
Describe the expected network path before creating anything: client, frontend address, protocol and frontend port, backend pool, backend port, probe endpoint, NSG scope and permitted return traffic.
Backend pool membership must match actual hosts
Backend pools can associate with supported VM or NIC/IP-based configurations depending on the topology and SKU. A VM deployed in a resource group does not automatically become a pool member. Membership can change during scaling or infrastructure redeployment, so inventory must identify which resources are expected to serve the application.
The instance also needs a listening service on the chosen backend port. A VM that is running but whose application process crashed should not receive useful traffic, assuming the probe is configured to detect that failure. Conversely, a healthy application cannot serve client requests if an NSG denies the necessary path or a UDR sends return traffic to an unavailable next hop.
For the fictional API, label the two backend VMs blue and green. Confirm that each is in the intended pool and serves a known harmless health endpoint. Record which application version and port each uses. A mixed-version pool may behave inconsistently even if both VMs are technically running.
Load-balancing rules connect two sides of traffic
A rule maps a frontend IP/protocol/port to the appropriate backend port and pool and specifies associated health-probe and distribution behavior. Some service configurations also use inbound NAT rules for direct management flows; they are not synonymous with application load distribution. Explain which rule a packet matches before investigating the backend.
A client connecting on the wrong port may receive no response even though the backend listens on another port. A correct frontend-to-backend rule should also be checked against NSGs and selected routes. Return traffic and outbound connectivity have their own design constraints; do not assume an inbound rule implicitly provides a complete outbound SNAT strategy for every workload.
Document the intended port, protocol, persistence or distribution requirements and how a client session should behave if a backend stops serving. A Layer 4 load balancer cannot infer application-layer authorization from the content of an HTTP request.
Health probes define eligibility, not business correctness
A health probe checks a configured port or endpoint to determine whether a backend should be eligible to receive traffic. For an HTTP/HTTPS service, a specific response status can be evaluated according to probe configuration; a TCP probe is narrower because establishing a connection does not prove the application completed a business operation.
Design the probe to reflect readiness without exposing confidential data or performing side effects. An endpoint that always returns success even when the main dependency is down may keep an unusable backend in rotation. An endpoint that performs a heavy database operation on every probe can increase load or produce false failures when a dependency is briefly slow.
Azure’s health-probe guidance identifies the platform probe source as 168.63.129.16 and explains how effective NSG rules can prevent a backend from responding. Check the configured probe port against the application listener, then check the applicable AzureLoadBalancer service-tag or source-IP allowance and host firewall. An unhealthy probe can reflect a blocked packet or a failed application response; do not fix either by adding an allow-any client rule.
Interpret an unhealthy backend in the right order
When a backend goes unhealthy, begin with evidence rather than immediately replacing the VM. Check the resource’s actual status and whether the application listens on the expected backend port. Verify the probe definition, NSG effective rules, routes, host-based firewall, service logs and the response returned to the probe. A load balancer may mark a backend unhealthy when an application’s chosen probe path is unavailable, even if some other URL still responds.
A useful failure matrix includes: the process is stopped; the process is bound to a different port; the probe path returns an unexpected status; an NSG blocks platform probe traffic; a host firewall denies the connection; and a route or backend dependency prevents a meaningful readiness response. Each condition has a different repair. Disabling the probe can send real users to broken backends and mask the original problem.
The probe’s eligibility state also has propagation timing. An operator should measure how the platform behaves when a backend fails or recovers rather than expect all clients to switch instantly. Existing long-running connections and application retries may have different behavior from new incoming flows.
Secure access includes the whole path
Standard Load Balancer works with Azure networking controls; it does not grant backend access by itself. NSGs and firewalls must allow the intended client or frontend traffic and required health checks. For an internal service, route reachability from authorized subnets matters. For a public service, only necessary ports should be exposed and the application still needs authentication.
Suppose a backend accepts traffic from a legitimate web tier but denies the same request from an unfamiliar network. A load balancer may still report a healthy backend because the probe source is not the end user. This is not inconsistent: health probes answer eligibility, while NSGs and application policy answer other questions. Avoid weakening authorization because a probe is green but a client is denied.
Protect management paths separately. If administrators need to inspect a VM, use an approved secure access method such as Bastion where suitable rather than assuming an application load-balancer rule should expose RDP or SSH publicly.
Availability zones and scale sets are complementary
A Standard Load Balancer backend may include VMs distributed across supported availability zones or managed through a Virtual Machine Scale Set. VM placement and scale-set configuration can reduce exposure to particular host or zone failures, but cannot correct a broken shared dependency, wrong listener port or probe endpoint that fails every backend. In a troubleshooting exercise, test one intentionally unhealthy application process separately from the loss of a VM, and compare the health probe results before proposing additional replicas or a different placement model.
Load balancing and resilience also depend on the data tier. If all backends contact a database with no independent recovery path, adding two more web VMs does not guarantee high availability. Separate the network/data dependencies that a probe tests from the failure classes that the business requires the system to survive.
The choice between an internal and public frontend is not a zone decision. Administrators need to select both network exposure and availability design and understand how they interact.
A synthetic troubleshooting exercise
Define a virtual service using a Standard Load Balancer with two backend VMs, a single frontend IP, a TCP application rule and an HTTP health endpoint. Create a written state table containing intended listener ports, probe path, pool membership, effective NSG rules and test-client location. Label one VM blue and the other green.
Case one: blue’s application stops responding. The health probe should detect it according to the configured threshold, and new traffic should be directed according to the platform’s load-balancing behavior. Case two: green’s application is healthy, but its NSG blocks the probe source. The same unhealthy indicator can arise for a different reason. Case three: both probes succeed while the API’s downstream storage access fails. A shallow readiness check can then leave both backends considered eligible.
For each case, identify what the probe proves, what it cannot prove, and which additional application or network evidence is needed. A completed assignment needs actual backend and request traces from a test Azure environment; the scenarios above are design fixtures only and have not been executed.
An operational acceptance checklist
Before production, verify the frontend is reachable from the intended client population, all expected backend members are enrolled, the rule maps the right protocol and port, the health check tests a meaningful readiness condition, the network permits the intended path, and the app enforces its own authorization. Run failure and recovery tests under controlled conditions and record which backend served actual requests.
Monitor health-probe failures, backend application errors, resource metrics and user-perceived latency together. A sudden rise in failed probes is an important signal, but does not identify the failing layer on its own. Avoid a runbook that always "fixes" the condition by adding NSG allow-any rules or extending permissions.
When a load-balanced service stops receiving requests, a health probe tests its configured endpoint; it does not prove that the application is healthy in every respect. The backend process may be down, the probe path or port may be wrong, an NSG may block traffic, or an application dependency may return an unhealthy response. Reproduce a failed listener and a separate application error, then compare their probe results. Before rebuilding the load balancer, verify backend-pool membership, frontend rules, probe configuration and effective traffic filtering. These are the diagnostic steps that independent AZ-104 practice questions should make an administrator explain rather than guessing from a green VM status.