Interview Kubernetes, Docker, Helm & Podman

What is a distroless or scratch image, and what are the trade-offs?

Kubernetes, Docker, Helm & Podman · Advanced level

Answer

scratch and distroless images are minimal runtime images with little or no OS userland. They reduce image size and attack surface, but they make debugging harder because tools like shell, package manager, curl, or ps may be absent.

Technical explanation

Distroless images often include runtime libraries and CA certs, while scratch is completely empty unless you copy everything required.

For debugging, use ephemeral debug containers or rebuild a debug variant rather than adding tools to production images.

Container image quality affects supply chain, startup time, vulnerability surface, rollout reliability, and debugging workflows.

Prefer reproducible builds: pinned dependencies, small build context, deterministic Dockerfile order, non-root runtime, and immutable image references.

Understand the runtime boundary: an image is not a VM, and container isolation depends on kernel, namespaces, cgroups, capabilities, seccomp, and mounts.

Hands-on example

1. Create a tiny sample app and Dockerfile for this exercise: build a distroless runtime image and debug it with an ephemeral debug container.

2. Build and inspect it with docker build or podman build, docker history, image inspect, and a vulnerability or size scan if available.

3. Run it locally with explicit env vars, ports, user, volumes, and signal tests depending on the question.

4. Convert the final runtime assumptions into Kubernetes fields such as image, command, args, ports, securityContext, probes, and volumeMounts.

Preparing for an interview?

Check how well your resume matches the role with our free resume checker— match score, ATS check, and the skills you're missing.

More Kubernetes, Docker, Helm & Podman interview questions

← All Kubernetes, Docker, Helm & Podman questions