ECS Memory-Based Auto Scaling with Target Tracking Policy
A company runs a containerized web application on Amazon ECS with AWS Fargate. The application is critical and requires high availability. The DevOps team has set up an Amazon CloudWatch alarm that triggers an auto scaling action when the average CPU utilization exceeds 75% for 5 minutes. However, during a recent traffic spike, the application became slow and some requests timed out, even though the CloudWatch alarm did not fire. The team checked the ECS service auto scaling configuration and found that the target tracking scaling policy based on average CPU utilization is set with a target value of 75%. The ECS service is configured with a minimum of 2 tasks and a maximum of 10 tasks. Upon investigation, they noticed that the CPU utilization metric for the service remained below 75% during the spike, but the memory utilization was high (over 90%). The application logs show that the tasks were running out of memory, causing garbage collection pauses and slow responses. Which course of action should the DevOps engineer take to prevent this issue in the future?
Quick Answer
The answer is to add a second target tracking scaling policy based on average memory utilization with a target value of 75%. This is correct because the root cause is memory pressure, not CPU—the existing CPU-based policy never triggered since utilization stayed below 75%, while memory spiked above 90%, causing garbage collection pauses and timeouts. On the AWS Certified DevOps Engineer Professional DOP-C02 exam, this scenario tests your understanding that ECS memory-based auto scaling with a target tracking policy can independently scale tasks based on a different resource metric, and that a single policy may miss critical bottlenecks. A common trap is assuming CPU is always the primary scaling signal, or reaching for static fixes like increasing task memory, which wastes cost and fails to handle dynamic spikes. Remember the memory tip: “CPU sleeps, memory creeps—track both to keep the service deep.”
⚠ Common exam trap
DOP-C02 often tests the misconception that CPU-based scaling is sufficient for all performance issues, when in fact memory bottlenecks require memory-based scaling policies.
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
✓
Add a second target tracking scaling policy based on average memory utilization with a target value of 75%.
The issue is that the application is running out of memory, causing performance degradation, but the scaling policy only monitors CPU. To prevent this, you should add a target tracking scaling policy based on memory utilization. This will trigger scaling when memory exceeds the target, providing additional tasks to handle the load and preventing memory exhaustion.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Add a second target tracking scaling policy based on average memory utilization with a target value of 75%.
Why this is correct
Memory exhaustion caused the timeouts while CPU stayed below target, so CPU-based target tracking never scaled out. A second target tracking policy on memory utilisation triggers scaling on the actual bottleneck, preventing garbage collection pauses during future spikes.
- ✗
Decrease the CPU target value to 50% to trigger scaling earlier.
Why it's wrong here
Lowering the CPU target cannot help, because CPU stayed below the existing 75% threshold; the bottleneck was memory, so CPU-driven scaling never triggers regardless of target. It is tempting because target tracking on CPU is the standard ECS scaling pattern, and it would be correct if CPU saturation were the actual constraint.
- ✗
Increase the minimum number of tasks from 2 to 5 to provide more capacity upfront.
Why it's wrong here
Raising the minimum task count adds static baseline capacity but leaves the scaling policy blind to memory, so tasks still exhaust heap during spikes. It is tempting because minimum capacity does improve availability, and it would be the right lever if the workload needed guaranteed floor capacity rather than demand-responsive scaling on the saturated resource.
- ✗
Increase the task memory limit in the task definition to 8 GB.
Why it's wrong here
Enlarging the memory limit per task delays out-of-memory pauses but does not add tasks when memory pressure rises, so the service still cannot scale on the real constraint. It is tempting because raising task memory is a legitimate fix for undersized containers, and it would be correct if a fixed task count were acceptable.
Go deeper
Related to this question
About these practice questions
This DOP-C02 question is part of Courseiva's 1,298-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on DOP-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company has deployed a containerized application on Amazon ECS with Fargate. The application is fronted by an Application Load Balancer (ALB). The DevOps team is using CloudWatch Container Insights to monitor the ECS cluster. They notice that the 'MemoryUtilized' metric for the service is consistently above 80%, and the 'CPUUtilized' is around 50%. The ALB's 'TargetResponseTime' is increasing over time. The team wants to resolve the performance issue. Which action should the team take?
medium- ✓ A.Increase the memory limit for the ECS task definition to allow the container to use more memory.
- B.Increase the CPU limit for the ECS task definition to improve performance.
- C.Increase the number of ALB targets by adding more availability zones.
- D.Increase the desired count of the ECS service to distribute the load across more tasks.
Why A: The metrics show MemoryUtilized consistently above 80% while CPUUtilized is only around 50%, and TargetResponseTime is rising — this is a classic memory-bound bottleneck. When a container approaches its memory limit, the kernel may reclaim page cache, trigger GC pressure, or begin swapping (if enabled), all of which degrade response time. Increasing the memory limit in the task definition gives the container headroom to operate without memory pressure, directly addressing the root cause.
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.