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 debug -it <pod> --image=busybox -- sh

  Why this is correct

  kubectl debug -it <pod> --image=busybox -- sh is the standard command to create an ephemeral debug container in the target pod. It injects a busybox container into the pod's namespace and attaches your terminal to it, allowing you to inspect the pod's shared network, storage, and process state. This is the sanctioned workflow for adding a temporary troubleshooting container.

• ✗

  kubectl run debug --image=busybox -- sh

  Why it's wrong here

  kubectl run debug --image=busybox -- sh creates a completely separate, standalone Pod in the same namespace, not an ephemeral container inside the existing pod. Because the new pod has its own network namespace, IP address, and volumes, it cannot inspect the original pod's file system, network interfaces, or running processes. This makes it useless for debugging the specific pod's internal state.

• ✓

  Adding an ephemeral container to the pod's spec under ephemeralContainers

  Why this is correct

  Adding an ephemeral container to the pod's spec under ephemeralContainers is valid because Kubernetes exposes this mutable subresource for precisely this purpose. You can use kubectl patch --subresource=ephemeralcontainers (or the API) to inject a manual debug container. However, note that ephemeralContainers cannot be set with a standard create/apply; it requires the dedicated subresource or the kubectl debug helper, but the underlying object is indeed the pod's ephemeralContainers list.

• ✗

  kubectl exec -it <pod> -- sh

  Why it's wrong here

  kubectl exec -it <pod> -- sh runs a shell directly inside one of the pod's existing, running containers, rather than creating any new container. This approach fails when the container image lacks a shell or the container has crashed and is not running. It does not use the ephemeral container feature and cannot add new debugging binaries or tools to the pod.

• ✗

  kubectl attach to the pod

  Why it's wrong here

  kubectl attach to the pod connects your terminal to the stdin/stdout/stderr streams of the pod's primary container process, effectively attaching to that already-running process. It does not execute any command, create a new container, or alter the pod's composition. Since it cannot introduce a debugging image or launch a new process, it is not a way to debug using an ephemeral container.

Go deeper

Related to this question