An engineer needs tools to triage a one-off crash in a production Pod. Which approach best matches ephemeral troubleshooting versus always-on helpers?
Select an answer to reveal the explanation.
Short Explanation
Don’t weld a full mechanic’s garage onto every car for one weird noise. Call a mobile mechanic (ephemeral debug) when you need it, and keep permanent sidecars for real day-to-day helpers only.
Full Explanation
When an engineer needs tools to triage a one-off crash in a production Pod, the approach that best matches ephemeral troubleshooting is to use an ephemeral debug container (for example kubectl debug) instead of baking a permanent debug sidecar into every replica. You gain shells and tooling for the incident window without permanently expanding CVE surface, image size, or CPU requests across the municipal production fleet.
Rebuilding every image with a permanent debug sidecar containing full distro toolchains continuously increases attack surface. Converting the application Deployment into a privileged DaemonSet for all debugging is a severe overreach of privilege and scope. Adding a hostPath mount to the container runtime socket on every application Pod by default is a critical security anti-pattern.
Exam caveat: Distroless production images plus kubectl debug align with modern CKAD practice. Document break-glass steps for city operators and remove debug sessions when finished.
Operational check: kubectl debug -it <pod> --image=busybox --target=<container>; collect stacks and filesystem clues; exit; confirm the Deployment Pod template was not permanently modified to include a debug sidecar.