A tourism booking widget uses a distroless image, and operators cannot kubectl exec with bash. What is the right takeaway for application design?
Select an answer to reveal the explanation.
Short Explanation
Distroless is a locked glass case—great for production safety, terrible if you expected a picnic table and a toolbox inside. No bash is often a feature: use logs, a debug sidecar/image, or ephemeral debug workflows instead of stuffing a shell into every runtime image.
Full Explanation
Tourism booking widgets on distroless images intentionally omit shells and package managers. That is a security and size feature for public-facing city services, not evidence of a broken cluster. Operators should not expect kubectl exec with bash to work; instead rely on structured logs, metrics, ephemeral debug containers (kubectl debug), or a dedicated debug image when deep triage is required. Application design should expose health and diagnostics without shipping a full distro in every production replica.
Treating distroless images as broken and replacing them with full Ubuntu undoes minimal-image benefits and expands CVE surface. Claiming the cluster is misconfigured because every CKAD application image must include a shell is false. Interpreting missing shells as kubelet admission failure misunderstands ImagePull and Ready conditions; a Running Pod can simply lack /bin/sh by design.
Exam caveat: distroless and other minimal images are valid CKAD application choices. Plan the debugging strategy separately from the hardened production runtime image used for the booking widget.
Operational check: confirm the app serves traffic and readiness passes; use kubectl logs and kubectl debug with a toolbox image targeting the Pod; avoid baking permanent debug sidecars into every replica by default.