Process running but load balancer says unhealthy

WHAT THIS TESTS The question probes whether you understand that a load balancer judges health by an explicit probe, not by whether a process exists, and whether you debug methodically from the probe's point of view.

A GOOD ANSWER COVERS The core insight is that the probe hits a specific path, port, and protocol and expects a specific status code, usually 2xx. The process can be running while the endpoint returns 404, 500, or a redirect, or while the app listens on a different port than the probe targets. A security group, NSG, or firewall may block the probe's source range even though SSH works on a different port. The app may be up but not yet ready, still warming caches or connecting to its database, so the probe path should reflect true readiness. Probe timeout, interval, and unhealthy threshold may be too aggressive for a slow endpoint. To troubleshoot, reproduce the probe exactly: curl the probe path on the probe port from within the instance and from another host, confirm the returned status, check that the configured port matches the listener, verify the security group allows the probe source, and read the load balancer's health probe logs.

COMMON WRONG ANSWERS Concluding the load balancer is broken because the process is up. Restarting the instance blindly without inspecting the probe response. Ignoring the security group or firewall as a cause because SSH succeeds on a different port.

LIKELY FOLLOW-UPS What is the difference between a liveness and a readiness check? Why separate the health endpoint from the main traffic path? How do thresholds cause flapping?

ONE CONCRETE EXAMPLE The app listens on 8080 but the probe is set to 80, so every probe times out while the process clearly runs. Pointing the probe at 8080 and a dedicated /healthz returning 200 restores the instance to rotation.