CKAD Application Observability and Maintenance Practice Question
A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?
⚠ Common exam trap
A common mix-up: candidates confuse CPU and memory resource management or think that restarting the pod will fix the issue, but OOMKilled is a persistent resource constraint problem that requires adjusting the memory limit.
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
✓
Increase the memory limit in the pod's container resource specification
The pod is in CrashLoopBackOff with an OOMKilled message, which indicates the container is being terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it has exceeded its memory limit. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly addressing the root cause.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Increase the memory limit in the pod's container resource specification
Why this is correct
The OOMKilled status means the container's memory usage exceeded its configured memory limit, triggering the kernel's out-of-memory killer. Raising the memory limit in the container resource spec gives the application more headroom to work within, directly addressing the root cause by preventing the OOM kill and subsequent CrashLoopBackOff. Correctly sizing the limit requires observing actual memory usage, as an arbitrarily high limit may hide memory leaks but does stop the crash loop.
- ✗
Increase the CPU request for the container
Why it's wrong here
OOMKilled is explicitly a memory exhaustion event, not a CPU contention issue. Increasing the CPU request only affects scheduling and CPU bandwidth guarantees; it has no influence on the memory cgroup limit that governs when the kernel kills the container. The crash loop will continue with the same OOMKilled status because the memory limit remains unchanged and the process still exceeds it.
- ✗
Delete and recreate the pod to clear the crash loop
Why it's wrong here
Deleting and recreating the pod without modifying the memory limit will produce an identical pod with the same resource constraints. The new container will start, exhaust its memory again, and be OOMKilled, re-entering CrashLoopBackOff. This action simply resets the restart counter; it does not alter the underlying reason the kernel terminates the process, so the outcome remains unchanged.
- ✗
Delete the namespace and redeploy all workloads
Why it's wrong here
Deleting the entire namespace is far too broad an action for a single pod's memory issue. It removes all pods, services, ConfigMaps, secrets, and other resources in that namespace, causing downtime for every workload there, not just the crashing pod. The correct remediation is scoped to the individual pod's resource limits, making this option both ineffective and unnecessarily destructive.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKAD question from scratch — 160 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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 CKAD practice question is part of Courseiva's free CNCF 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 CKAD exam.