CKA Troubleshooting Practice Question

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 an excessively disruptive action that removes Services, ConfigMaps, PersistentVolumeClaims, and other dependent objects unrelated to the crashing pod. It does not alter the container's declared memory limit or resource requests, so the newly created pod will still be subject to the same cgroup memory constraint and will again be OOMKilled. This approach ignores the actual root cause—an undersized memory limit—and creates unnecessary downtime and risk of data loss.

• ✗

  Increase the CPU request for the container

  Why it's wrong here

  Increasing the CPU request for the container changes only the CPU scheduling guarantees and CPU shares allocated to the container; it has no effect on the memory cgroup limits that govern the OOM killer's behavior. A container in CrashLoopBackOff with an OOMKilled status is being terminated for exceeding its memory limit, not for insufficient CPU resources, so altering CPU requests will not prevent the kernel from killing it when memory usage spikes. In fact, raising CPU requests may unnecessarily constrain scheduling and cause the pod to be unschedulable if nodes lack sufficient CPU capacity.

• ✓

  Increase the memory limit in the pod's container resource specification

  Why this is correct

  Raising the memory limit in the pod's container resource specification directly addresses the cause of the CrashLoopBackOff: the kernel's OOM killer terminates the container when its memory usage exceeds the cgroup limit defined by spec.containers[].resources.limits.memory. Increasing this limit provides additional headroom for the application's legitimate memory footprint, allowing the container to remain within its constraint and avoiding repeated OOMKilled terminations. Be sure to verify that the node has enough allocatable memory and that limits are aligned with actual usage patterns.

• ✗

  Delete and recreate the pod to clear the crash loop

  Why it's wrong here

  Manually deleting and recreating the pod will simply apply the same unchanged resource limits and container configuration, so the new instance will follow the identical startup sequence and be OOMKilled and restarted again once memory usage crosses the limit. If the pod is managed by a Deployment or ReplicaSet, deletion only causes an automatic replacement from the existing spec, giving you a temporary restart at best. The crash loop is driven by the memory limit itself, not by a stale pod instance, so this action is ineffective unless the pod specification is updated simultaneously.

Go deeper

Related to this question