What is a build artifact and why build once deploy many crucial?

WHAT THIS TESTS: The interviewer wants to know if you understand the difference between source code and a deployable artifact, and why immutability is a non-negotiable foundation of reliable continuous delivery. They are checking whether you can articulate the risks of rebuilding per environment and how to externalize configuration.

A GOOD ANSWER COVERS: First, define a build artifact as the versioned, compiled output of the CI pipeline, for example a container image, JAR file, or compiled binary, which includes all runtime dependencies but excludes environment-specific configuration. Second, explain the build once, deploy many principle: the exact same artifact is promoted unchanged through every environment from staging to production. Third, state that immutability guarantees that the artifact tested is precisely the artifact shipped, which eliminates an entire class of works on my machine failures and provides a single auditable unit for rollbacks. Fourth, note that configuration must be injected at deploy time via environment variables, config maps, or external secret stores, because baking configuration into the artifact forces a rebuild for each environment and violates immutability.

COMMON WRONG ANSWERS: A major red flag is saying that rebuilding the artifact per environment with different compiler flags or build-time variables is acceptable. Another is conflating the artifact with source code or the Dockerfile alone. Some candidates suggest that immutability makes rollbacks harder; in fact, it enables them because you can redeploy a known-good version instantly. Claiming that container images are naturally immutable without mentioning the rebuild risk also misses the point.

LIKELY FOLLOW-UPS: The interviewer may ask how you handle environment-specific configuration without rebuilding, or how you secure secrets if they are not embedded in the image. They might probe whether you tag artifacts with the Git SHA or semantic version, and how you store and garbage-collect old artifacts. Another angle is asking what happens when a library vulnerability is found: do you patch and rebuild the artifact, or try to mutate a running container.

ONE CONCRETE EXAMPLE: Imagine a Java service built into a container image tagged with the Git commit SHA. The CI pipeline runs unit and integration tests against this image. The same image is deployed to a staging environment using a staging database URL injected as an environment variable. After QA signs off, that identical image is deployed to production with a production database URL and API key mounted via a secret store. If a bug is found, you roll back by redeploying the previous image tag, not by reverting code and rebuilding. If you had instead rebuilt the image for production with production profile flags, a dependency resolver could have pulled a different patch version of a library, meaning the binary that passed tests was not the binary that reached users.

Source: beyond.minimumcd.org