DOP-C02 Monitoring and Logging Practice Question
A company has a production Amazon EKS cluster with multiple node groups. The DevOps team notices that some pods are frequently restarting due to OOMKilled errors, but the cluster-level metrics (CPU, memory) appear normal. Which CloudWatch Container Insights metric should be analyzed to identify the specific node or pod causing the issue?
⚠ Common exam trap
DOP-C02 often tests the node-vs-pod metric distinction by making cluster-level metrics look normal, so candidates who pick node_memory_utilization miss that OOMKilled is a per-container cgroup limit event, not a node exhaustion event.
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
✓
pod_memory_utilization.
OOMKilled errors are caused by individual containers exceeding their memory limits, which is a pod-level (container-level) condition. CloudWatch Container Insights exposes 'pod_memory_utilization' (and 'container_memory_utilization') per pod, allowing you to pinpoint which pod is hitting its memory limit even when node-level memory looks normal. This is the metric that directly correlates with OOMKilled restarts.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
node_memory_utilization.
Why it's wrong here
Node-level memory utilization aggregates memory across all pods, system processes, kernel slabs, and page cache. A pod can be OOMKilled by the kernel when it exceeds its individual cgroup memory limit (configured via resources.limits.memory) even while the node has abundant free memory, so this aggregate metric masks per-pod limit violations and cannot diagnose which workload is being evicted.
- ✗
number_of_running_pods.
Why it's wrong here
The number of running pods is a capacity indicator, not a memory-consumption indicator. OOMKilled relates to a container's memory usage exceeding its pod/container memory limit, so a static or even declining pod count reveals nothing about per-pod memory pressure. A single pod with a small memory limit can be repeatedly OOMKilled while the total pod count remains unchanged.
- ✓
pod_memory_utilization.
Why this is correct
Pod memory utilization directly shows memory usage per pod compared to its configured limit, which is the exact condition that triggers the kernel's out-of-memory killer. When a container's working set (container_memory_working_set_bytes) exceeds its memory limit, the OOM killer terminates it with exit code 137, so plotting this metric against the limit surfaces the specific pod(s) at fault and helps correlate with OOMKilled events in kubectl get pods.
- ✗
pod_cpu_utilization.
Why it's wrong here
CPU utilization is a compute-resource metric and is not part of the kernel's OOM decision, which is based solely on memory pressure and memory limit enforcement. A pod can spike CPU and get throttled but will not receive OOMKilled; conversely, a pod with near-zero CPU can still be OOMKilled if its memory working set crosses its limit, making this metric useless for detecting or diagnosing OOMKilled errors.
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 →
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.