A company runs a microservices architecture on Amazon ECS with Fargate. They need to ensure that if a task fails, it is automatically restarted. Which configuration is required?
An ECS service is the correct mechanism for running a long-lived microservice: you specify a task definition, a desired count, and a cluster, and the service scheduler ensures that the desired number of tasks is always running. When a task crashes, is killed, or fails a health check, the service automatically replaces it by starting a new task from the same task definition. This provides self-healing and integrates with Application Load Balancers, target groups, and service discovery for production traffic.
Why this answer
An ECS service with a desired count and task definition ensures that Fargate tasks are automatically restarted if they fail. The ECS service scheduler monitors the desired count and replaces any stopped or failed tasks to maintain the specified number of running instances, providing built-in resilience without additional infrastructure.
Exam trap
The trap here is that candidates confuse the RunTask API (for one-off tasks) with ECS services (for long-running, self-healing tasks), or mistakenly think CloudWatch alarms or Auto Scaling groups are needed for task restart logic when the ECS service itself provides this capability.
How to eliminate wrong answers
Option A is wrong because CloudWatch alarms can trigger actions like sending notifications or scaling, but they cannot directly restart an ECS task; restarting requires a service or custom automation. Option B is wrong because the RunTask API launches tasks on-demand for batch or one-off jobs, not for continuous availability or automatic restart on failure. Option C is wrong because Auto Scaling groups are used for EC2 instances, not for Fargate tasks; Fargate tasks are managed by ECS services or standalone RunTask calls, and scaling is handled via ECS Service Auto Scaling, not an Auto Scaling group.