In a GHES deployment fronted by a load balancer for high availability, what should health checks primarily verify before sending user traffic to a node?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Load balancers should only send users to nodes that are actually healthy primaries (or the active serving role), not to a pure replica that is not meant to take writes, and not based on silly checks like 'can it resolve the internet.' Wire health checks to GHES-supported health endpoints/status and remove failed nodes quickly so clients do not get half-broken sessions during failover.
Full explanation below image
Full Explanation
The correct answer is that the node is healthy and appropriate to receive production application traffic. Load balancers in GHES HA designs must avoid routing users to failed nodes or to roles that should not serve primary traffic. Health checks should align with GitHub's guidance for appliance readiness so failover or recovery does not black-hole requests. Option A is irrelevant to whether the appliance should serve enterprise traffic. Option B confuses Management Console credential parity with runtime health. Option C confuses Actions runner topology with the main GHES application tier. Combine health checks with DNS or VIP cutover procedures documented for ghe-repl-promote scenarios, and test failure injection carefully in non-production first.