SAP-C02 Continuous Improvement for Existing Solutions Practice Question

A startup runs its application on Amazon ECS with Fargate launch type. The application uses an Application Load Balancer to distribute traffic. During a recent marketing campaign, the application experienced high latency and some requests returned 503 errors. The team suspects that the tasks are hitting resource limits. The team wants to automatically scale the tasks based on CPU utilization. Which solution should the team implement?

⚠ Common exam trap

SAP-C02 often tests the misconception that ECS clusters are scaled with EC2 Auto Scaling groups; for Fargate, scaling is done at the service level with Application Auto Scaling, not at the cluster level.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Configure Application Auto Scaling for the ECS service with a target tracking scaling policy based on average CPU utilization.

Application Auto Scaling with a target tracking policy on average CPU utilization is the native, recommended way to scale ECS service tasks. It automatically adjusts the desired count of tasks to keep CPU near the target value, responding to load changes without custom code. This directly addresses the high latency and 503 errors caused by tasks hitting resource limits.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Configure Application Auto Scaling for the ECS service with a target tracking scaling policy based on average CPU utilization.
Why this is correct
Application Auto Scaling target tracking adjusts the ECS service's desired task count to hold average CPU utilisation at a target, directly addressing the resource-limit saturation causing 503s and latency. It works with Fargate because scaling operates on task count, not cluster capacity.
✗
Create a CloudWatch alarm that triggers a Lambda function to stop idle tasks.
Why it's wrong here
Stopping idle tasks reduces capacity rather than adding it under load, so latency and 503 errors worsen. Lambda remediation is tempting for cost control or cleaning up stuck tasks, but it is correct only when tasks are genuinely idle, not when CPU-bound demand requires ECS service auto scaling.
✗
Create an Auto Scaling group for the ECS cluster and configure it to scale based on CPU utilization.
Why it's wrong here
Fargate tasks are not EC2 instances, so an Auto Scaling group cannot manage them; ECS service auto scaling with target tracking on CPU is required. Auto Scaling groups are tempting because they scale EC2-backed clusters, which is correct only for the EC2 launch type.
✗
Use AWS Lambda to periodically check CPU utilization and update the desired count of the ECS service.
Why it's wrong here
Using Lambda to periodically poll CPU utilisation and manually adjust the desired count introduces a polling interval that cannot react quickly enough to sudden traffic spikes, whereas the correct solution—ECS Service Auto Scaling with a target tracking policy—adjusts capacity continuously based on real-time CloudWatch metrics. This approach is tempting because Lambda is often used for custom, event-driven scaling logic in systems that lack native auto-scaling support, such as when scaling third-party resources or performing scheduled capacity adjustments.

Go deeper

SAP-C02 Continuous Improvement for Existing Solutions Practice Question

Why each option matters

Option-by-option breakdown

Related to this question