A SaaS runs checkout on ECS Fargate behind an ALB with Auto Scaling and order processing on Lambda with SQS. Unhealthy tasks occasionally serve 500s and failed messages disappear without retry. Which automated failure recovery using health checks and replacement restores service?
Select an answer to reveal the explanation.
Short Explanation
You've got sick checkout tasks to pull fast so they don't keep tossing errors, like pulling a wobbly player off the field. You'll use ALB health checks with auto healing to swap in fresh tasks while SQS redrive and Lambda retries save your failed orders.
Full Explanation
The correct design restores both tiers because ALB target health checks detect application failures like HTTP 500s, ECS service auto healing terminates unhealthy tasks and launches replacements to maintain desired count with Auto Scaling, while an SQS redrive policy moves messages exceeding max receives to a dead-letter queue to prevent silent loss and Lambda retry destinations preserve failed asynchronous invocations for later reprocessing, together providing automated detection, replacement, and durable retry. The long-polling approach correctly combines load-balancer detection with replacement but fails on durability because long polling only reduces API cost and latency and provides no dead-letter routing, so poison messages still exhaust receives and disappear without retry. The EC2 status-check approach correctly preserves messaging durability but fails on detection because host-level checks cannot observe application 500s, so unhealthy Fargate tasks stay in service behind the ALB and keep serving errors. The deregistration-only approach correctly detects failures and preserves messages but fails on capacity because removing targets without ECS replacement steadily shrinks usable tasks and degrades throughput under load. An exam caveat is to separate detection scope from replacement action and retrieval optimization from retention, since plausible designs often include one correct mechanism while omitting the paired recovery path. As a practical check, verify target health with replacement events, confirm redrive maxReceiveCount with dead-letter depth and destination metrics, and inject 500s and poison messages in staging to observe automatic recovery.