skip to content

A team bundles every environment's settings inside the image and picks one at start-up by stage name — what does that cost?

level: middleimportance: nice to knowfreq 30%

answer

  1. one artifact, but the values ride inside
  2. a configuration change becomes a build
  3. every environment's settings ship everywhere
  4. a new stage needs a rebuild, not a value set
  5. defaults inside, per-stage deltas outside

basics

~20 s

Every value change becomes a rebuild, because the values live in the bytes. It also ships every environment's settings to everyone who can pull the artifact, and adding an environment needs a new build — the coupling that one-artifact delivery was meant to break.

solid answer

~50 s

The pattern gets the important half right: one set of tested bytes reaches every environment, so the test evidence still transfers. What it costs is the other half. Because the value sets are inside the artifact, changing a timeout or an endpoint means a build, a new artifact and a fresh trip through delivery — a configuration change is now a release, and the release you ship for it is not the one that was tested as such. Every environment's settings also travel wherever the artifact goes, so production endpoints and internal hostnames sit in every copy anyone can pull, and adding an environment means rebuilding. Credentials must never be in the bundle at all. The usual middle ground is to keep safe **defaults** inside the artifact and supply only each stage's differences from outside.

go deeper

for a junior

Notice where the value physically lives. If it is inside the artifact, changing it means producing a new artifact, whatever the deployment supplies at start-up.

for a middle

Separate the two halves: one artifact everywhere is satisfied, but configuration is still coupled to the build, and every environment's settings travel in every copy.

for a senior

Argue the cost-of-change and disclosure consequences concretely, and propose the migration — safe defaults stay inside, environment-identifying values become required and supplied per stage.

for a principal

Decide where the boundary between artifact and configuration sits as a standard, including the genuine exception of targets you do not operate, so teams are not each rediscovering it.

## What the pattern gets right It is worth being fair to it, because it is not the classic mistake. There is exactly one artifact, its bytes are identical everywhere, and the stage name supplied by the deployment selects which bundled set is used. The evidential guarantee holds: the thing tested in the lower environment is the thing serving production. Many teams arrive here honestly, as the first step away from building one image per environment, and it is a real improvement on that. The problem is that it satisfies the letter of one-artifact delivery while re-creating, in a different place, the coupling the practice exists to remove. ## What it costs - **A value change is now a build.** Adjusting a queue depth, a retention window or an endpoint means a source change, a build, a new artifact and a full trip through delivery. The lead time for a one-line operational change becomes the lead time for a release. - **The artifact you ship for that change was not tested as that change.** The new build is a new artifact; whatever evidence you had attached to the previous one. - **Every environment's settings travel everywhere.** Production hostnames, internal endpoints, queue names and thresholds are inside every copy of the artifact — in every lower environment, on every machine that can pull it. That is an information-disclosure cost even when nothing in the bundle is a credential, and **credentials must not be in it at all**. - **Adding an environment means a rebuild.** A new stage cannot be created by supplying values; it has to be compiled in first. - **Operators cannot correct a value.** During an incident, the only lever is a build, which is the slowest lever available. - **The sets drift within the file.** Because all stages live in one document, a change made for one stage sits next to the others and is easy to apply to the wrong one — or to leave unapplied in a stage nobody was looking at. | | Settings bundled in the artifact | Settings supplied at deployment | |---|---|---| | Tested bytes reach production | yes | yes | | Cost of changing one value | a build and a new artifact | edit the value set and redeploy | | Who can read production's settings | anyone who can pull the artifact | whoever can read that environment's set | | Adding an environment | a rebuild | a new value set | | Fixing a value under incident pressure | slowest path available | the normal deployment path | ## The middle ground The usual resolution keeps the good half and drops the bad one: 1. **Defaults inside, deltas outside.** The artifact ships values that are safe in any environment — sizing that works, verbosity that is not chatty, features off. It ships **no** environment's endpoints, and no stage-specific set. 2. **Required where no safe default exists.** Endpoints and identities normally have none, so they are declared required and validated at start-up rather than defaulted to something plausible. 3. **Per-stage differences supplied by the deployment.** Small, readable, diffable, and changeable without a build. That combination keeps a single artifact, keeps the stage name as the deployment's input, and makes a value change what it should be: a value change. ## When bundling is defensible There are narrow cases. A delivery target that has no outside value source at all — software handed to someone who installs it in an environment you do not operate — has nowhere for supplied values to come from except the artifact and whatever the installer passes. A very small number of settings that are genuinely code-shaped, such as an internal tuning constant nobody should vary per environment, belongs inside the artifact and stops being configuration at all. What does not survive scrutiny is bundling *because it is easier than plumbing a value set through the deployment*, which is the reason most teams are actually there. ## How to talk about it in an interview Name the half it gets right first — one artifact, evidence preserved — then the axis it fails on, which is the cost of change rather than the correctness of the deployment. That ordering shows you are evaluating a design rather than matching it against a slogan, and it is also the way to raise it with the team that built it.

  • Is it acceptable for the artifact to carry any values at all?
    Yes — defaults that are safe in every environment. Sizing that works anywhere, quiet verbosity, new features off. What should not be inside are values that identify an environment, such as endpoints and accounts, and anything with no safe default at all; those are declared required and supplied per stage, so an omission fails loudly instead of resolving to a guess.
  • The team says bundling is safer because values cannot be tampered with after the build. How do you answer that?
    Immutability of the values is real but is not free, and it is not the only way to get it. The supplied set can be versioned and reviewed like code, rendered in the pipeline and pinned to the deployment, which gives you the same auditability while leaving a value change cheaper than a release — and it does not put production's endpoints into every copy of the artifact.

saying these in an interview costs you the question

  • Calls it a per-environment build because values are inside
  • Puts credentials in the bundled per-stage sets
  • Thinks a bundled set can be changed without a rebuild
  • Claims bundling removes the need for a supplied stage name
  • Treats an incident value fix as a routine deployment here