Promote an artifact from staging to release without rebuilding it

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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?

ONE 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.

Source: beyond.minimumcd.org