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.

• ✗

  Exec into the pod with 'kubectl exec -it' to inspect the environment

  Why it's wrong here

  In CrashLoopBackOff, the container is repeatedly restarting and is often not running at all; kubectl exec requires a live container, so it will fail with an error like 'cannot exec into a container in a crashed state'. Even if you catch a brief running window, the container may exit before you can run any useful command, and exec does not give you access to the previous crash's logs or termination reason. This approach is only valid for a pod that has a stable running container, not for one in a crash loop.

• ✗

  Check resource usage with 'kubectl top pod'

  Why it's wrong here

  kubectl top pod samples instantaneous CPU and memory usage, but a crashing container does not stay alive long enough to produce meaningful utilization data, and the metrics server often does not report metrics for terminated or backoff containers. While resource pressure can be a cause of crashes, this command only shows current consumption, not the error, exit code, or restart history that diagnose a CrashLoopBackOff. It is a monitoring tool, not a debugging technique for this scenario.

• ✓

  Use 'kubectl debug' to start an ephemeral container for troubleshooting

  Why this is correct

  kubectl debug attaches an ephemeral container to the target pod without restarting or modifying the original container, so you can inspect the shared filesystem, environment variables, and network namespace even while the main container is crash-looping. Ephemeral containers are managed by the kubelet and are not subject to the pod's restart policy, allowing them to remain available for interactive troubleshooting when the main container keeps failing. This is the direct, supported way to debug a crashing pod when exec is impossible.

• ✓

  View logs from the previous container instance with 'kubectl logs --previous'

  Why this is correct

  kubectl logs --previous retrieves the log output from the last terminated container instance, which is exactly where the crash-time stderr/stdout from the failed process resides. When a pod is in CrashLoopBackOff, the current container may not have written any logs, but the previous incarnation's logs contain the panic, fatal error, or exception that caused the restart. This is usually the fastest first step before using more invasive debugging tools.

• ✗

  Create a new pod with 'kubectl run' using the same image

  Why it's wrong here

  kubectl run creates a brand-new pod from the image but ignores the original pod's manifest specifics, such as startup probes, resource limits, environment variables, and volume mounts, so it often will not reproduce the same crash. It also creates a separate workload and gives you no information about the existing pod's restart count, termination message, or current backoff state. Debugging the original pod's specification with kubectl get pod -o yaml is more accurate than launching an unrelated pod.

Go deeper

Related to this question