CKS Supply Chain Security 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.

• ✗

  Faster image build times

  Why it's wrong here

  Build times are not significantly improved by switching to distroless images. While the base image contains fewer layers and less data to pull, the actual image build is dominated by compiling your application and copying in artifacts, and base layers are typically cached. The marginal savings in download/extraction time are not a primary reason to adopt distroless, so this is not a core benefit.

• ✓

  Smaller image size

  Why this is correct

  Distroless images strip away shells, package managers, and non-essential OS utilities, retaining only the runtime environment (e.g., JVM, Python runtime) and necessary libraries. This reduces compressed image size from hundreds of MB to tens of MB, directly accelerating image pull times and lowering storage and bandwidth costs on Kubernetes clusters. For large deployments, the cumulative effect of smaller images can significantly improve pod startup latency and cluster resource consumption.

• ✗

  Better compatibility with Kubernetes security contexts

  Why it's wrong here

  Kubernetes security contexts, such as runAsNonRoot, readOnlyRootFilesystem, capabilities, and seccomp profiles, are enforced by the container runtime and kernel, not by the base image. Distroless images may conveniently run as non-root by default and lack a shell, but they do not alter how the kubelet or CRI applies securityContext policies. The same PodSpec settings behave identically regardless of the base image, so this is not a compatibility advantage; any perceived benefit is just a side effect.

• ✓

  Smaller attack surface

  Why this is correct

  A distroless image reduces attack surface by omitting shells, package managers, and standard utilities like curl, wget, and bash, which are common vectors for exploitation and post-breach activities. This dramatically cuts the number of installed binaries and shared libraries, and therefore the number of potential CVEs that can be exploited directly inside the container. Even if an attacker exploits the application, the lack of tooling hampers lateral movement, reverse shells, and arbitrary command execution, making this a fundamentally security-focused benefit.

• ✗

  Easier debugging

  Why it's wrong here

  Distroless images intentionally exclude interactive shells and debugging tools, so you cannot run kubectl exec to invoke commands like ls, ps, or strace inside the container. Debugging requires attaching from outside, using ephemeral debug containers, or building a one-off image with the same runtime plus tooling — all of which are more complex than opening a shell in a standard image. This is a deliberate trade-off: greater security at the cost of operational convenience, making distroless harder, not easier, to troubleshoot.

Go deeper

Related to this question