A city open-data team containerizes an ETL helper. Build tools and compilers are needed during image creation but must not remain in the image that runs in production. Which Dockerfile practice best meets that goal?
Select an answer to reveal the explanation.
Short Explanation
You can build the ETL helper in a workshop, then send only the finished work into production. With a multi-stage build, compilers stay in an earlier stage while the final image carries just what the ETL job needs.
Full Explanation
City open-data ETL containers may need compilers, headers, and build tools to assemble wheels or native extensions, but those tools add image size and attack surface if they remain in production. A multi-stage Docker build keeps the toolchain in an earlier stage, produces the needed artifacts there, and copies only runtime binaries, libraries, or installed packages into the final image. The ETL helper can run without gcc, make, or SDK leftovers, supporting security baselines that favor minimal runtime images. Installing compilers in the final image and disabling commands with environment variables still leaves the binaries and packages in the image; environment flags do not remove the tools or their CVEs. Mounting the host’s toolchain as a bind volume at each start couples containers to operator laptops or jump hosts, reduces portability across Kubernetes nodes, and weakens immutable image provenance. Running apt-get upgrade in a single-stage image refreshes package versions but does not automatically remove unused build packages or separate build and runtime contents. Exam caveat: multi-stage builds copy artifacts between named stages; they do not mean omitting a FROM line or relying on cache mounts alone. Practical check: inspect the final image’s layer inventory to confirm compilers are absent, then verify the ETL entrypoint still imports and runs successfully.