Docker multistage build technique reduces final image size.

• A. Convert to multi-arch
• B. Use smaller base images
• C. Use multiple build stages to discard build artifacts and dependencies
• D. Squash layers after build

Answer: (C)

Using multiple build stages lets you separate the environment used to build the application from the environment that runs it. In the first stage you install compilers, build tools, and other dependencies needed to compile or assemble the app. In a later stage you start from a minimal runtime base and copy only the final, built artifacts into it. This means all the build tools, caches, and intermediate files stay out of the final image, so the runtime image is much smaller.

For example, you build with a full-featured image in the first stage, then use a slim or specialized runtime image in the final stage and transfer only what’s needed (the compiled binary, libraries it truly depends on, and the application files). This approach directly targets reducing the final image size by excluding unnecessary build-time content.

Other options touch related ideas but don’t achieve the same guaranteed reduction. Converting to multi-arch is about supporting multiple CPU architectures, not about shrinking the image. Using smaller base images helps, but if you still carry over build tools and caches, the final size won’t shrink as much. Squashing layers can reduce the number of layers or, in some cases, the apparent size, but it doesn’t reliably remove build-time artifacts and can complicate caching and reproducibility.