CKAD Application Observability and Maintenance 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.

• ✓

  Check Pod status, then inspect logs and events, then fix the issue, then restart the Pod.

  Why this is correct

  Start with `kubectl get pods` and `kubectl describe pod` to confirm the CrashLoopBackOff status and capture the container's exit code, reason, and events. Then gather diagnostics: `kubectl logs <pod> --previous` for the terminated container's output, and review events to identify root causes such as a missing environment variable, image pull failure, or failing liveness probe. Apply a precise fix to the deployment manifest—adjusting the command, env vars, resources, or probe thresholds—and only then delete the Pod (or rollout restart) to let the controller schedule a fresh instance, followed by verifying the Pod reaches Running and remains stable.

• ✗

  Restart the Pod, then check Pod status, then inspect logs and events, then fix the issue.

  Why it's wrong here

  Deleting a Pod before gathering any diagnostics destroys the current container's logs and events, which are exactly the evidence needed to understand why it crashed. The replacement Pod created by the ReplicaSet will use the identical broken spec, so the kubelet will just re-enter the CrashLoopBackOff sequence, often with an even longer backoff delay. Restarting first is a common anti-pattern because it wastes time and can reset the backoff timer without exposing the actual root cause, leaving you to repeat the cycle.

• ✗

  Inspect logs and events, then fix the issue, then restart the Pod, then check Pod status.

  Why it's wrong here

  Without first checking Pod status, you might spend time debugging a Pod that is actually Pending due to a scheduling problem or one that is Running but has a failing readiness probe—events that are not classified as CrashLoopBackOff. The initial status check confirms the phase and the container restart count (`kubectl describe` shows `Restart Count`), which indicates whether you're truly in a crash loop. Additionally, this sequence says to restart before verifying the fix; you should always validate that the Pod stays Running after the restart, because some fixes only mask a slow crash.

• ✗

  Fix the issue, then check Pod status, then inspect logs and events, then restart the Pod.

  Why it's wrong here

  Diagnosing the issue through logs and events before attempting a fix is non-negotiable; guessing at a fix without evidence leads to wasted effort and can introduce new errors (e.g., changing an env var that wasn't the problem). Checking Pod status after the fix but before restart is misleading because the old Pod is still in CrashLoopBackOff; only after applying the new configuration via a restart can you assess whether the change worked. The proper order is observe, diagnose, fix, restart, and then validate—a sequence that ensures you're acting on facts, not assumptions.

Go deeper

Related to this question