What is the purpose of a multistage build in a Dockerfile?

What is the purpose of a multistage build in a Dockerfile?

• A. To run multiple images sequentially
• B. To increase the build time
• C. To merge runtime and build dependencies
• D. To reduce the size of the final container image

Answer: (D)

Multistage builds use multiple FROM stages in a single Dockerfile to separate the environment used to build an application from the environment used to run it. You build your code in one stage that includes all the compiler tools, libraries, and source, then you create a final stage that starts from a slim runtime base and only copies the built artifacts into it. The final image ends up containing just what’s needed to run the application, not the heavy build tools or source code. This dramatically reduces the size of the final container and lowers the attack surface, while still letting you build everything reproducibly in the builder stage and then package a lean runtime image. Why the other ideas don’t fit: it’s not about running multiple images in sequence at runtime, nor is the goal to increase build time. And it’s the opposite of merging dependencies; the point is to keep build-time tools separate from the runtime environment so the final image stays small and secure.

Multistage builds use multiple FROM stages in a single Dockerfile to separate the environment used to build an application from the environment used to run it. You build your code in one stage that includes all the compiler tools, libraries, and source, then you create a final stage that starts from a slim runtime base and only copies the built artifacts into it. The final image ends up containing just what’s needed to run the application, not the heavy build tools or source code. This dramatically reduces the size of the final container and lowers the attack surface, while still letting you build everything reproducibly in the builder stage and then package a lean runtime image.

Why the other ideas don’t fit: it’s not about running multiple images in sequence at runtime, nor is the goal to increase build time. And it’s the opposite of merging dependencies; the point is to keep build-time tools separate from the runtime environment so the final image stays small and secure.