How do you keep one build artifact immutable across environments?

What's really being asked

This question probes whether you understand the strict separation between build and run stages defined by the Twelve-Factor App methodology, specifically factors three, five, and ten. The interviewer wants to see that you know how to keep an artifact immutable while still allowing environment-specific configuration, and that you can articulate why rebuilding per stage destroys parity and auditability.

The full answer

First, the build stage should compile code and resolve dependencies into a single artifact such as a container image or binary, and this artifact must contain no environment-specific configuration. Second, configuration must be supplied at runtime through mechanisms that do not modify the artifact, such as environment variables, mounted secret volumes like Kubernetes secrets or AWS Secrets Manager, or external configuration stores like Consul or etcd that the application reads on startup. Third, the release stage combines the immutable artifact with the current environment configuration to create a runnable instance, and this mapping should be versioned and auditable. Fourth, you should mention that secrets require additional protections such as encryption at rest, least-privilege access, and rotation policies.

The mistakes people make

A major red flag is suggesting that the CI pipeline rebuilds or re-tags the image for each environment with a different config file baked in, because this creates divergent artifacts and makes it impossible to guarantee that what was tested in staging is exactly what runs in production. Another mistake is proposing build-time substitution of variables inside the Dockerfile or build script, which again couples configuration to the artifact. Templating config files into the image during build is also incorrect for the same reason. Some candidates suggest storing secrets in the source repository or build context, which violates security principles.

What usually comes next

The interviewer may ask how you would rotate a database credential without restarting the process, how you handle configuration that changes frequently versus rarely, or how you validate that an artifact has not been tampered with as it moves between registries. They might also ask for a comparison between environment variables and mounted secret files, or how you manage configuration for local development without polluting production settings.

A concrete example

A team builds a Java application into a container image and pushes it to a registry with a semantic version tag. The image contains only the compiled JAR and a base JVM, with no application properties file. In the dev environment, the deployment manifest mounts a ConfigMap and a sealed secret as files under a directory named config, and the application reads these on startup. The identical image is promoted to staging and production, where different ConfigMaps and secrets are mounted, but the image digest remains unchanged across all three environments. If production breaks, the team can instantly roll back by pointing the production manifest to the previous image digest, confident that the artifact itself is identical to the one that passed staging tests.