DOP-C02 Monitoring and Logging Practice Question
A company uses Amazon ECS with Fargate for containerized applications. The DevOps team notices that some tasks are failing with 'OutOfMemoryError' but the CloudWatch metric 'MemoryUtilization' for the service shows values well below the task memory limit. What is the most likely cause of this discrepancy?
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
✓
The container's memory usage is hitting the kernel's memory cgroup limit before the Docker-reported usage reaches the task memory limit.
The MemoryUtilization metric reported by CloudWatch for ECS on Fargate is based on the Docker-reported memory usage, but the Linux kernel's out-of-memory (OOM) killer terminates the container when it exceeds the hard memory limit defined at the container level in the task definition. This can happen even if the task-level metric appears below the limit, as the metric may smooth out spikes or not reflect the container's actual memory cgroup limit. Option B is wrong because averaging across tasks does not cause a discrepancy for individual tasks; the metric is per-task. Option C is wrong because in Fargate, the task definition specifies both memory reservation (soft limit) and memory limit (hard limit), and the issue is with the hard limit. Option D is wrong because Fargate does not support swap space.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The container's memory usage is hitting the kernel's memory cgroup limit before the Docker-reported usage reaches the task memory limit.
Why this is correct
The OOM killer can be triggered by the kernel's memory cgroup limit, which may be set lower than the task memory limit, or by the container exceeding the soft limit, causing the metric to not reflect the actual limit breach.
- ✗
The CloudWatch metric 'MemoryUtilization' is aggregated across all tasks in the service, so individual task spikes are averaged out.
Why it's wrong here
The MemoryUtilization metric is not aggregated at the service level; ECS emits a separate time series for each task, with the task ID as a dimension. If you view an average across the service, that is a statistic you are computing, not the raw metric. A single task's memory spike will still be visible in its own per-task CloudWatch metric, so this option cannot explain why a task is OOM-killed while the service-level average appears normal.
- ✗
The task definition has a memory reservation but no hard limit, causing ECS to overcommit memory.
Why it's wrong here
A memoryReservation in an ECS task definition is only a soft limit used by the ECS scheduler to place tasks on an EC2 instance; it does not create a kernel-level memory cgroup cap. Without a corresponding memory (hard limit), the container is not constrained by that reservation, and ECS does not 'overcommit' in a way that directly triggers the OOM killer. The kernel OOM killer is invoked when actual cgroup memory usage exceeds the hard limit, which in Fargate is always set to the task memory value, so a missing reservation is not the cause.
- ✗
The container is using swap space, which is not included in the MemoryUtilization metric.
Why it's wrong here
Fargate does not provide swap space for tasks, and ECS on Fargate does not support configuring swap. Even if swap were present, the OOM killer in a Linux cgroup operates on the memory cgroup's current memory usage (anonymous, page cache, kernel memory), not on swap usage. Swapped-out pages are not counted in the MemoryUtilization metric, but they also do not cause the cgroup memory limit to be exceeded; therefore, swap cannot explain why the kernel kills the container while the reported metric is below the task memory limit.
Go deeper
Related to this question
About these practice questions
This DOP-C02 question is part of Courseiva's 1,013-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 →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.