Promote an artifact from staging to release without rebuilding it
Tests immutable artifact discipline. Answer: promote by copying the binary or retagging the image digest, never recompiling, because rebuilds introduce dependency drift and untested bits.
What's really being asked
The interviewer is checking whether you understand immutable artifacts and environment parity. They want to know if you treat the artifact produced by the pipeline as sacred, ensuring the exact bits that passed staging are the bits that reach production. This separates senior engineers who think in systems from those who treat CI/CD as a collection of scripts.
The full answer
First, describe a concrete promotion mechanism. For a Docker image, that means retagging an immutable digest from a staging registry to a release registry, or using registry replication and access controls so the same layer blobs are referenced by a new tag. For a JAR, that means copying the binary from a staging repository manager like Nexus or Artifactory to a release repository, or flipping metadata that marks it as released, without ever re-invoking the build tool. Second, explain why rebuilds are dangerous. Rebuilds violate the principle that what you test is what you ship. Source dependencies can resolve to newer transitive versions, build toolchains can differ, and timestamps or environment variables can inject variation. A rebuild means the production artifact is not the artifact that passed automated tests and staging validation. Third, mention that configuration belongs outside the artifact. Environment-specific settings should be injected at deploy time via environment variables, config maps, or externalized configuration, not baked into the build.
The mistakes people make
Saying you would rebuild with a release profile or production flag. Arguing that rebuilding ensures a clean slate. Suggesting that Docker layer caching makes rebuilds safe, which ignores base image drift and package index updates. Proposing to embed environment configuration into the artifact during the rebuild, which creates a snowflake artifact per environment and breaks parity.
What usually comes next
How do you handle environment-specific configuration if it is not baked into the artifact? What is your rollback strategy if the promoted artifact fails in production? How do you sign or verify artifact integrity during promotion? Have you dealt with regulatory requirements that demand reproducible builds, and how does that change your approach?
A concrete example
A team builds a Java service in CI, producing JAR version 1.2.3 and pushing it to a staging repository in Artifactory. After passing integration tests and staging deployment, the pipeline copies that exact JAR file to the release-candidates repository and updates a release manifest to reference the same checksum. The production deployment job pulls from the release-candidates repository using that checksum. The build job is never triggered again. If a bug is found, the team rolls back by updating the manifest to the previous checksum, not by rebuilding an old commit.
Interview question
When promoting a tested JAR or image to production, which approach follows immutable artifact discipline?
- a.Copy the exact binary or retag the immutable digest without rebuilding.Correct
- b.Inject production configs and rebuild for the release repository.
- c.Rebuild from cache using the same source to preserve tested bits.
- d.Rebuild it with a production profile to guarantee a clean artifact.
Why? this is the answer
Copying or retagging the exact artifact guarantees that production receives the identical bits validated in staging, whereas rebuilding from cache is risky because base images, package indexes, or transitive dependencies may have drifted.
Just read this? Test yourself on what you have been reading.
Read the original → beyond.minimumcd.org
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