CKS A pod is in a CrashLoopBackOff state 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.

• ✗

  The pod is out of memory

  Why it's wrong here

  OOM is a kernel-level event that terminates the container process when it exceeds its memory limit, typically producing a container status of OOMKilled and an exit code of 137, not a user-space error in the logs. The application would have already started and been running before being killed, so the logs would likely contain the app's normal startup output rather than a missing-executable error. Since the pod is in a CrashLoopBackOff from the very first start, a resource-limit kill is inconsistent with the observed log content.

• ✗

  The container's working directory is incorrect

  Why it's wrong here

  An incorrect working directory would not cause the container runtime to fail to locate the executable, because the image entrypoint or command is usually an absolute path like /app; the runtime resolves that path independently of the working directory. Even if the working directory were wrong, the typical failure would be an inability to find relative config files or a 'chdir: no such file or directory' error from the runtime, not a missing executable in the logs. In this case, the log error indicates the binary itself cannot be exec'd, which points to a missing file, not the current working directory.

• ✗

  The pod has a liveness probe that is failing

  Why it's wrong here

  A failing liveness probe would only trigger after the container has started and is running long enough for the probe to execute, and the failure would be visible in `kubectl describe pod` as a probe failure event, not as a startup error in the logs. The container would be repeatedly killed and restarted, but each restart would produce logs from the application itself, showing that the app is alive but unhealthy, rather than an immediate exec failure. Since the pod is in CrashLoopBackOff before any probe could even run, the log error is not consistent with a liveness probe issue.

• ✓

  The container image is missing the /app executable

  Why this is correct

  This is correct: when the container image's ENTRYPOINT or CMD references an executable that is not present in the image filesystem, the container runtime fails to fork the process with an error such as 'exec: /app: no such file or directory' or 'executable file not found in $PATH'. This error is written to the container's stderr and appears in `kubectl logs`, and the container exits immediately with a non-zero exit code, causing the kubelet to restart it and enter CrashLoopBackOff. The fix is either to rebuild the image with the executable correctly installed or to adjust the command in the pod spec.

Go deeper

Related to this question