CKA Practice Question: Cluster Architecture, Installation and Configuration
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
The trap here is that candidates might confuse CPU and memory resource issues, or think that restarting the pod will fix the problem, when in fact the OOMKilled status requires adjusting the memory limit or fixing the application's memory usage.
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 that the container was terminated because it exceeded its memory limit. Since the pod ran successfully for days before crashing, the most likely cause is a memory leak or increased workload demand. Increasing the memory limit in the container's resource specification allows the pod 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 CPU request for the container
Why it's wrong here
An OOMKilled event, which typically causes a CrashLoopBackOff, signifies that the container exceeded its allocated memory limit, leading the kernel to terminate the process. Increasing the CPU request only influences the scheduler's decision on which node to place the pod and how much CPU time it is guaranteed; it has no bearing on the container's memory consumption or the enforcement of memory limits. Therefore, this action will not resolve the underlying memory exhaustion problem.
- ✗
Delete and recreate the pod to clear the crash loop
Why it's wrong here
Deleting and recreating the pod without modifying its underlying resource specification, particularly the memory limits, will not resolve the root cause of the CrashLoopBackOff. The new pod instance will be launched with the identical, insufficient memory limits, inevitably leading to another OOMKilled event and perpetuating the crash loop. This action merely restarts the problematic configuration without addressing the fundamental resource constraint.
- ✗
Delete the namespace and redeploy all workloads
Why it's wrong here
Deleting an entire namespace is an extremely destructive operation that would indiscriminately terminate all running pods, services, deployments, and other resources within that namespace. This drastic measure is entirely disproportionate and inappropriate for resolving a memory issue affecting a single pod, as it would cause widespread service disruption and potential data loss for all other workloads in the production namespace.
- ✓
Increase the memory limit in the pod's container resource specification
Why this is correct
An OOMKilled event directly indicates that the container attempted to consume more memory than specified by its `resources.limits.memory` configuration, leading the operating system to terminate the process. Increasing this memory limit in the pod's container specification provides the application with more available RAM, thereby preventing the Out-Of-Memory termination and allowing the pod to run stably without crashing. This directly addresses the root cause of the CrashLoopBackOff.
Visual reference
Go deeper
Related to this question
Learn chapter
Troubleshooting Cluster and Node Issues
Key term
Pod Failure Troubleshooting
Pod failure troubleshooting is the process of identifying and resolving issues that cause Kubernetes pods to crash, restart, or become unavailable.
Key term
kubectl Command Reference
kubectl is the command-line tool used to interact with and manage Kubernetes clusters by sending commands to the Kubernetes API.
About these practice questions
Courseiva writes every CKA question from scratch — 302 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 CKA 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 CKA exam.