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
Candidates often confuse CPU and memory resource constraints, thinking increasing CPU requests will solve an OOM issue, or they assume a simple pod restart is sufficient without addressing the underlying resource 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 OOMKilled status indicates the container exceeded its memory limit and was terminated by the Linux kernel's Out-Of-Memory (OOM) killer. Since the pod ran successfully for days, the issue is likely a memory leak or increased workload demand, not a configuration error. Increasing the memory limit in the container's resource specification allows the pod to handle the higher memory usage without being killed.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Delete the namespace and redeploy all workloads
Why it's wrong here
Deleting the namespace and redeploying all workloads is a destructive and overly broad action. It removes every resource in the production namespace, causing widespread downtime, and the newly deployed pod will still inherit the same memory limit unless the manifest is changed. This does not address the specific OOMKilled event affecting a single pod.
- ✗
Delete and recreate the pod to clear the crash loop
Why it's wrong here
Deleting and recreating the pod will only restart the container with the same configured resource limits. Since the manifest still sets an insufficient memory limit, the container will quickly exceed it again and be terminated by the kernel, resulting in the same CrashLoopBackOff. This action treats the symptom without correcting the underlying configuration.
- ✗
Increase the CPU request for the container
Why it's wrong here
Increasing the CPU request for the container does not affect the memory cgroup quota that governs OOM kills. OOMKilled indicates the container's memory usage exceeded resources.limits.memory, not that it lacked CPU shares. Adjusting CPU requests may even alter scheduling but cannot prevent memory exhaustion, so this option is orthogonal to the problem.
- ✓
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 the limit specified in resources.limits.memory. Raising this limit in the pod's container resource specification gives the process more headroom under the cgroup, allowing it to run without being killed by the kernel. This directly resolves the cause of the crash loop, provided the node has sufficient allocatable memory.
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.