A team's pipeline builds the artifact separately for each environment because "the config differs". What is wrong, and what do you propose?

What the interviewer is testing

Whether you can articulate why build-once-deploy-many is a correctness property rather than an efficiency one.

What is wrong

You are testing something you are not shipping. Two builds from the same source can differ: a dependency range resolves to a new patch version, a base image tag has moved, a transitive dependency was republished, a build-time code generator produced different output, or the build machine had a different toolchain.

Each difference is individually unlikely and collectively routine — and the failure is the worst kind, where staging passed because staging genuinely had different code.

It also breaks traceability. "Which artifact is in production" no longer maps to a single hash, so incident forensics and vulnerability response both become guesswork.

The proposal

Build one artifact, identified by digest, and promote it unchanged. Configuration is injected at deployment — environment variables, mounted config, a configuration service — never baked in.

Baking configuration per environment is the trap in the third option: it looks like build-once but produces a different artifact per environment, which is the original problem with better branding.

Practically:

• Secrets come from the secret manager at runtime, using workload identity
• Environment-specific endpoints come from configuration, not from compile-time constants
• The artifact is promoted by label or by moving between repositories, not rebuilt
• Deployment references the digest, so what runs is unambiguous

What a strong answer adds

The one legitimate exception: some client-side builds must embed environment configuration because there is no runtime injection point in a static bundle. The answer there is to keep the embedded set minimal and to fetch the rest at runtime from a configuration endpoint — and to be explicit that this is a compromise with a known cost.

Also worth adding: this is a prerequisite for supply-chain attestation. You cannot meaningfully sign and verify an artifact whose production variant was built by a different job.

Common weak answers

Accepting per-environment builds because they are deterministic — determinism of the build process does not guarantee identical inputs. Suggesting the difference does not matter in practice.