A Go service for flood-alert SMS is compiled in CI. Why would the Dockerfile use a second FROM stage?
Select an answer to reveal the explanation.
Short Explanation
Build the furniture in a big workshop, then deliver only the finished chair to the apartment. The saws and scraps stay behind—smaller, safer images for the registry and cluster.
Full Explanation
A second FROM starts a new build stage so stage one can compile the flood-alert Go service with a full toolchain while stage two copies only the resulting binary onto a slim runtime base. The compiler, module caches, and intermediate objects stay behind in the builder stage and never reach the final registry image. That shrinks image size and attack surface on production nodes without changing how the SMS alert binary executes once the container starts.
Multi-stage builds are not intended to run the compiler again inside every production container on each request. Keeping the full toolchain and intermediate objects in the final registry image is exactly what the pattern avoids. Kubernetes does not require two FROM lines before a Pod can schedule; multi-stage is a Docker build technique, not an orchestrator admission rule.
Exam caveat: copy only what the runtime needs—missing shared libraries or CA bundles on a distroless or scratch base show up as opaque start failures, so validate the final stage image in CI, not merely the builder stage. Operational check: compare final image size and layer contents before and after introducing the second FROM, then run the slim image and prove the binary starts without the builder toolchain present.