An ALB target group for an ECS civic app should not receive traffic until DB connections are warmed and feature flags are loaded. What should they configure?
Select an answer to reveal the explanation.
Short Explanation
Listening on a port is not the same as ready. Point the ALB health check at a readiness probe that waits for warm DB pools and loaded feature flags.
Full Explanation
An ALB target group for an ECS civic app should not receive traffic until DB connections are warmed and feature flags are loaded. Configure a readiness-style health check (or equivalent probe) that passes only when the application is truly ready—not merely when the process is listening on a port. That keeps citizens off half-initialized tasks that would otherwise shed errors during deploys and scale-out.
A health check that returns 200 as soon as the container PID exists ignores DB and feature-flag readiness and admits unhealthy tasks.
Removing all health checks so the ALB always sends 100% of traffic immediately maximizes failed requests during startup.
Cost Explorer anomaly detection is a billing signal, not an ALB readiness gate.
Exam caveat: Distinguish liveness (process up) from readiness (safe to serve). ALB health checks should reflect readiness for user traffic.
Operational check: Implement a /ready endpoint that verifies DB connectivity and flag load, point the target group health check at it, deploy a slow-starting revision, and confirm the ALB waits until readiness passes before routing civic traffic. Keep the civic/municipal context in mind: permit and benefits apps that touch databases during boot will otherwise flap during every ECS rollout.