Application Observability and Maintenance →easyMultiple Choice

CKAD Application Observability and Maintenance Practice Question

Exhibit

Refer to the exhibit.
```
kubectl get pods -n production
NAME                     READY   STATUS    RESTARTS   AGE
app-backend-6b4c9d8f7-2x4z5   0/1     CrashLoopBackOff   5          3m
app-backend-6b4c9d8f7-7y8u9   1/1     Running            0          5m
app-frontend-5f6a7b8c9d-1a2b3 1/1     Running            0          10m
```

Refer to the exhibit. A pod named 'app-backend-6b4c9d8f7-2x4z5' is in CrashLoopBackOff state. What is the MOST likely cause of this issue?

⚠ Common exam trap

CNCF often tests the distinction between CrashLoopBackOff and other pod failure states like OOMKilled or ImagePullBackOff, and the trap here is that candidates may assume any crash is due to resource limits or network issues without checking the specific exit code or pod events.

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

✓

The container is crashing due to a misconfiguration or application error.

A CrashLoopBackOff state indicates that the container in the pod is repeatedly crashing and being restarted by the kubelet. The most common cause is a misconfiguration (e.g., incorrect environment variables, missing dependencies, or a faulty entrypoint script) or an application error (e.g., a runtime exception or panic). The kubelet detects the crash via the container runtime (e.g., containerd) and applies an exponential backoff delay before restarting, leading to the CrashLoopBackOff status.

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 container is crashing due to a misconfiguration or application error.
Why this is correct
CrashLoopBackOff means the container has started and exited repeatedly with a non-zero exit code, and the kubelet is applying an exponential backoff between restarts. This is typically caused by a misconfiguration—such as a missing ConfigMap value, incorrect environment variable, bad command-line argument, or a malformed config file—or an application-level error like an unhandled panic. Check kubectl logs with --previous to see the actual error message and exit code.
✗
The container has exceeded its memory limit and is being OOMKilled.
Why it's wrong here
When a container exceeds its memory limit, the kernel OOM killer terminates it and the kubelet records lastState.reason as OOMKilled, not CrashLoopBackOff. Although restartPolicy: Always can cause the container to be restarted repeatedly, the termination reason displayed in pod status remains OOMKilled, making it clearly distinguishable from a generic application crash. Use kubectl describe pod to inspect the last termination reason.
✗
The node running the pod is down, preventing the container from starting.
Why it's wrong here
If the node were down, the kubelet would be unavailable to report container status, so the pod would remain in Pending (if it could not be scheduled) or transition to Unknown/NodeLost, not CrashLoopBackOff. CrashLoopBackOff is an active state maintained by a running kubelet that detects container exits and calculates restart backoff. A ReplicaSet controller would reschedule the pod to a healthy node instead of leaving it in this crash loop state.
✗
A network policy is blocking the container from accessing required services.
Why it's wrong here
NetworkPolicies are enforced by the CNI plugin at the pod's network interfaces and only filter traffic; they do not send signals to or terminate container processes. A container blocked by a policy continues running normally but may fail to connect to required services, resulting in timeouts or connection errors—not a CrashLoopBackOff exit loop. This symptom is an operational/connectivity issue, not a process lifecycle issue.

Go deeper

CKAD Application Observability and Maintenance Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question