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 exec -it my-pod -- /bin/bash

  Why it's wrong here

  kubectl exec -it my-pod -- /bin/bash attempts to start a shell inside the existing container, but this fails cleanly when no /bin/bash (or any shell) is present in the image. Exec requires a binary that actually exists in the container's writable layer or image, and the process must be able to spawn in the container's PID and mount namespaces. If the image is distroless or intentionally stripped of shells and coreutils, there is simply no way to get an interactive TTY via exec, so this option is useless for debugging such a pod.

• ✗

  kubectl cp /tmp/debug-tool my-pod:/tmp/

  Why it's wrong here

  kubectl cp /tmp/debug-tool my-pod:/tmp/ copies a file into the container's filesystem, but it does not execute that file or open any interactive session. Even after the copy, you still need a way to run the binary—which requires an existing shell or an exec call that itself needs a shell in the container. Moreover, a statically linked debug binary is rare; a dynamically linked tool would fail due to missing shared libraries in the stripped container, and the copied file is also subject to the container's read-only filesystem or lack of execute permissions. This approach only delivers the tool, not the ability to use it interactively.

• ✓

  kubectl debug -it my-pod --image=busybox --target=my-container

  Why this is correct

  kubectl debug -it my-pod --image=busybox --target=my-container is correct because it creates a new ephemeral container in the same pod, sharing the pod's network namespace and, with --target, the process namespace of my-container. Busybox comes with a built-in ash shell and standard diagnostic utilities (ps, netstat, ls, cat), giving you an interactive shell without needing anything preinstalled in the original container. The ephemeral container has its own filesystem and can run commands that see and signal the target container's processes, exactly what you need to debug a pod that lacks a shell or debugging tools.

• ✗

  kubectl port-forward my-pod 8080:80

  Why it's wrong here

  kubectl port-forward my-pod 8080:80 simply opens a tunnel from your local machine to a port on the pod's IP, which only enables network-level testing of the application. It does not provide access to the container's process namespace, filesystem, or middleware runtime, and it does not allow you to run any commands or inspect container internals. This is useful for hitting an HTTP endpoint or debugging a network issue, but it is completely irrelevant when the goal is to have a shell or debugging utilities inside a container that lacks them.

Go deeper

Related to this question