CKAD Application Design and Build 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
Watch out — candidates often confuse CPU and memory resource issues, or think that restarting the pod (Option B) will fix the underlying resource constraint, when in fact the OOMKilled status persists until the memory limit is increased.
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 'OOMKilled' message indicates the container was terminated because it exceeded its memory limit. Increasing the memory limit in the container's resource specification allows the container to use more memory, preventing the out-of-memory kill. This directly addresses the root cause without losing the pod's state or affecting other workloads.
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 CPU request for the container
Why it's wrong here
Raising the CPU request only affects CPU scheduling guarantees and the CPU cgroup weight, not the container's memory cgroup limit. Since OOMKilled is triggered by the kernel when the container's memory usage exceeds its memory limit, altering CPU parameters has no effect on the memory cgroup that enforces the limit, so the container will continue to be OOM-killed.
- ✗
Delete and recreate the pod to clear the crash loop
Why it's wrong here
Deleting and recreating the pod does not change its resource specification; the ReplicaSet or Deployment controller will immediately create a replacement pod with the same memory limit. The new container will again exceed that limit during startup or normal operation and again be OOM-killed, so the crash loop backoff will simply start anew rather than being resolved.
- ✓
Increase the memory limit in the pod's container resource specification
Why this is correct
OOMKilled specifically indicates that the container's memory usage hit the memory limit set in its resources.limits field, causing the kernel's out-of-memory killer to terminate the process. Increasing the memory limit grants the container a larger memory cgroup allowance, so it can continue running with its actual memory footprint without being killed, which directly addresses the root cause.
- ✗
Delete the namespace and redeploy all workloads
Why it's wrong here
Deleting the production namespace would destroy every workload, service, configmap, secret, and persistent volume claim in it, causing a much larger outage than the single pod's crash loop. It does not fix the underlying memory limit issue, because any pod recreated afterwards would still specify the original limiting resource values, and the action is completely disproportionate for a problem that can be resolved by a targeted pod spec update.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 160 original CKAD practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.