What is a build artifact and why build once deploy many crucial?
Tests whether you see artifacts as immutable deployable units. A strong answer says one binary is promoted through all stages, config is externalized, and rebuilding per environment creates drift. Red flag: accepting per-environment rebuilds.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
Which approach aligns with the 'build once, deploy many' principle when handling environment-specific database URLs?
- a.Embed the database URL directly in the application binary during compilation for each target environment
- b.Maintain separate Git branches per environment and build from the branch matching the target deployment
- c.Rebuild the image for each environment, passing the database URL as a build argument to the Dockerfile
- d.Build the container image once, then provide the database URL via environment variables at deployment timeCorrect
Why? this is the answer
The correct answer preserves artifact immutability by externalizing configuration and deploying the same binary everywhere. Option C is tempting because build arguments appear to parameterize deployments cleanly, but they force per-environment rebuilds that can introduce unverified dependency changes.
Just read this? Test yourself on what you have been reading.
Read the original → beyond.minimumcd.org
- #ci/cd
- #immutable-artifacts
- #continuous-delivery
- #deployment
- #devops
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ci/cd — each one lists the topics its interview covers.
See open roles