Three techniques to shrink a Docker image

WHAT THIS TESTS This checks whether you know concrete size-reduction levers and can reason about what each costs in debuggability or build complexity.

A GOOD ANSWER COVERS First, multi-stage builds: compile or install in a builder stage, then COPY only the runtime artifact into a minimal final stage, leaving compilers, headers, and dev dependencies behind. Trade-off is a slightly more complex Dockerfile. Second, a smaller base image: moving from a full OS image to slim, alpine, or distroless can cut hundreds of megabytes. Alpine uses musl libc which can break glibc-dependent binaries and complicate native modules; distroless has no shell or package manager, so debugging requires ephemeral containers or a debug variant. Third, layer hygiene: combine related commands, clean apt or package caches within the same RUN so they never persist in a layer, pin and remove only what is needed, and add a dockerignore so build context junk never enters the image.

COMMON WRONG ANSWERS Listing techniques without trade-offs. Suggesting docker save or compression as a real fix. Cleaning caches in a separate RUN, which leaves the bloat in the earlier layer. Switching to alpine without considering musl breakage.

LIKELY FOLLOW-UPS Why does cleaning in a later layer not help? When is alpine risky? How do you debug a distroless image? How does squashing differ from multi-stage?

ONE CONCRETE EXAMPLE A 2GB Node image carried the full build toolchain. A multi-stage build compiles in a node builder, then copies node_modules and the dist folder into a node-slim runtime stage, dropping compilers. Switching the runtime base from the full image to slim removes hundreds of megabytes more, and a dockerignore excludes the local node_modules and git history. The result drops well under 300MB, at the cost of a two-stage Dockerfile and fewer debugging tools in the final image.