Multi-stage Docker builds
separating build tooling from runtime.
a build stage compiles with the toolchain, the final stage uses a minimal base and copies only the artifact, cutting size and attack surface.
shipping compilers and source.
What's really being asked
This evaluates whether you understand that the tools needed to build software are not needed to run it, and how Docker multi-stage builds exploit that.
The full answer
In a single-stage build you start from an image with the full SDK, compilers, and build dependencies, compile inside it, and ship the whole thing, so the final image carries the toolchain, source code, and intermediate artifacts that the running program never needs. A multi-stage build splits this. The first stage uses FROM golang:1.22 or a JDK image as a build environment, copies in source, and compiles the binary or jar. The final stage starts FROM a minimal base such as gcr.io/distroless, alpine, or even scratch for a static Go binary, and uses COPY --from=build to bring across only the compiled artifact. The result contains just the runtime essentials and your binary. Beyond shrinking the image from hundreds of megabytes to tens or less, the smaller image has a much smaller attack surface because compilers, package managers, and shells are absent, fewer CVEs to patch, faster registry pushes and pulls, faster cold starts and autoscaling, and no source code leaking inside the shipped image.
The mistakes people make
Manually deleting build tools with extra RUN rm commands, which still leaves them in earlier layers and the history. Shipping the SDK image to production. Thinking the only benefit is disk space, ignoring security and pull speed. Using scratch for a dynamically linked binary that then cannot find its libraries.
What usually comes next
What is a distroless image and when can you use scratch? How does COPY --from work and can you copy from an external image? How does this interact with layer caching? How do you debug a container with no shell?
A concrete example
A Go service built single-stage on golang:1.22 is about 800 MB. Refactored: stage one on golang:1.22 runs go build -o app, stage two is FROM gcr.io/distroless/static and does COPY --from=build /src/app /app with ENTRYPOINT ["/app"]. The final image drops to roughly 20 MB, contains no compiler or shell, pulls almost instantly, and exposes far fewer vulnerabilities.
Interview question
Beyond reducing image size, what is a key benefit of a multi-stage Docker build that leaves the toolchain out of the final image?
- a.It reduces the attack surface and vulnerabilities by excluding compilers, shells, and source codeCorrect
- b.It makes the compiled program run faster at runtime
- c.It removes the need for a container registry entirely
- d.It automatically encrypts the application binary
Why? this is the answer
A minimal final image without build tools, shells, or source has far fewer components to exploit or patch, improving security. It does not change runtime speed, remove the registry, or encrypt the binary.
Just read this? Test yourself on what you have been reading.
Read the original → docs.docker.com
- #docker
- #multi-stage-build
- #image-size
- #security
- #containers
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on docker — each one lists the topics its interview covers.
See open roles