A university Application Load Balancer marks every target unhealthy, yet a curl of each instance's home page returns HTTP 200. The target group health check uses the path /healthz, and the application does not serve that path. What is the least disruptive fix?
Select an answer to reveal the explanation.
Short Explanation
The doctor is knocking on a door the building does not have, then declaring the building empty. You point the health check at a path the application really serves. Replacing the fleet does not invent /healthz.
Full Explanation
The load balancer marks a target unhealthy when its own health-check request fails. That request uses /healthz, and the application does not serve /healthz, while a curl of the home page still returns HTTP 200. Pointing the health check at a path the application actually serves lets these same instances pass without a rebuild. Tearing down the Auto Scaling group and launching a replacement group under a new name and a new AMI drops live capacity, and the new instances still fail if they are registered into the same missing path. Opening port 22 from anywhere does not change the request the load balancer sends, and it exposes a management port to the internet. Turning off target health checks would send users to every registered IP, including an instance that is later actually down. Caveat: the path you choose has to be one the application returns successfully, or the targets stay unhealthy for a different missing page. Operational check: after the path change, request that path from a host in the VPC and confirm the target group reports healthy before you send users back to it.