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.

• ✗

  kubectl logs web-app-84b7f6f5b6-abcde

  Why it's wrong here

  This command retrieves only the current stdout/stderr logs from the main container of pod web-app-84b7f6f5b6-abcde. Since the pod's pod template creates a unique instance suffix (abcde), the default log request reads from the running container's log file, which is empty or overwritten if the container has restarted. Restarting a container does not append to the same log stream; the kubelet rotates the log file, making the old instance's logs inaccessible without the --previous flag.

• ✗

  kubectl logs --all-containers web-app-84b7f6f5b6-abcde

  Why it's wrong here

  The --all-containers flag expands the log retrieval to every container in the pod, prepending each line with the container's name. However, it does not change the fundamental behavior of kubectl logs: it still reads only from the currently running instances of those containers. For a pod that has restarted, the previous container's log data is not included in this stream, so this command would miss the exact logs the developer needs unless the pod has multiple containers and all of them have crashed simultaneously, which is not the stated requirement.

• ✓

  kubectl logs --previous web-app-84b7f6f5b6-abcde

  Why this is correct

  The --previous flag instructs kubectl to retrieve logs from the previous, terminated instance of the container rather than the current one. In a typical crash-loop scenario, the kubelet retains the log file of the last terminated container on the node, and kubectl accesses it through the API's 'previous' option. This gives the developer visibility into the exact output that caused the prior container to exit, making it the correct command when the pod is named with an instance suffix and the developer suspects a restart has occurred.

• ✗

  kubectl logs -f web-app-84b7f6f5b6-abcde

  Why it's wrong here

  The -f (--follow) flag causes kubectl to keep the log stream open, continuously printing new lines as the container writes them. This is useful for live debugging or tailing a running process, but it does not access any historical logs from a previous incarnation of the container. Since the developer is looking for logs from a prior instance, following the current (already restarted) container's output would show new logs, not the lost ones, and would not fulfill the request.

Go deeper

Related to this question