What runtime defaults does an image's configuration blob carry, and what happens when a workload spec sets the same fields?
answer
- read, not unpacked
- what to run, as whom, from where
- the image proposes, the spec disposes
- an override leaves the digest alone
- declared ports are documentation
basics
~20 sThe configuration blob declares defaults for the process: the command and its arguments, the user, the working directory, environment entries, and declared ports as metadata. A workload spec that sets the same field wins at start-up, and the image is unchanged — same digest, same defaults for the next caller.
solid answer
~40 sThe configuration blob is the document a manifest names alongside its layers, and it holds what the image says about running itself: the default command and arguments, the default user, the working directory, default environment entries, declared ports and volume paths as metadata, plus the platform it targets and the identities of its unpacked layers. These are **defaults, not policy**. Whatever starts the workload — a single-host runtime or a cluster scheduler — reads them and may override any of them from its own spec, and an override changes nothing in the image: the digest is the same afterwards and the next host gets the same defaults. Only where neither the image nor the spec states a value does the platform's own fallback apply.
code
json · 16 lines{
"architecture": "fleet-arch",
"os": "server-os",
"defaults": {
"command": ["/app/ingester", "--mode=stream"],
"user": "10001",
"workingDirectory": "/app",
"environment": ["LOG_FORMAT=structured"],
"declaredPorts": [8080]
},
"unpackedLayerIds": [
"id-of-the-base-layer",
"id-of-the-dependency-layer",
"id-of-the-application-layer"
]
}go deeper
Recall what the configuration blob holds — the default command, user, working directory and environment — and that it is read rather than unpacked into the filesystem.
Explain the precedence: the spec overrides the image's defaults, the platform's fallback applies only where neither said anything, and an override never changes the artifact's digest.
Show the publishing judgment: ship a default command that is the real entry point and a non-root default user, so the safe behaviour is what happens when a consumer's spec is silent.
The standard you set is what every image an organisation publishes must declare about itself, so that consumers across teams can rely on the artifact rather than on tribal knowledge about how to start it.
## Where the defaults live A manifest names two kinds of blob: the layers, which are unpacked into the filesystem the process will see, and one **configuration blob**, which is read rather than unpacked. That configuration is the image's own statement about how it expects to be run. Its contents divide into three groups: - **Start-up defaults** — the command and its arguments, the user (and group) to run as, the working directory, default environment entries, and, as pure metadata, the ports the image expects to serve on and the paths it expects to be given storage for. - **Identity of the image** — the processor architecture and operating system the binaries target. - **Ties to the layers** — the identities of the unpacked layers in stacking order, which let a runtime confirm that the layers it has expanded are the ones this configuration belongs to. Only the first group is what most people mean by "the image config". ## Defaults, not policy The important property is that every start-up default is **overridable by whatever starts the container**, and that overriding it is a run-time act with no effect on the artifact. - Set a different command in the workload spec, and that command runs; the image's default is simply not used this time. - Set a different user, and the process runs as that user; the image still declares its own. - Add environment entries in the spec, and the process sees the union, with the spec's value winning on a collision. - The image's declared ports do not open anything. They are documentation for whoever wires up the network. After all of that the image's digest is unchanged, because nothing was written to it. The next team pulling the same reference gets the same defaults and can make entirely different choices. ## Three layers of decision | what decides | example | changes the image | |---|---|---| | the image's configuration blob | the default command the publisher shipped | it *is* the image | | the workload spec that starts it | a command override for a one-off maintenance run | no | | the platform's own fallback | what user to assume when nothing states one | no | Read the table top-down as *most specific wins*: the spec overrides the image, and the platform's fallback applies only where neither said anything. Where designs genuinely differ is in that bottom row — platforms choose different fallbacks and different strictness about missing values — which is exactly why a workload that relies on a fallback behaves differently when it moves. ## Why publishers should still set them carefully 1. **The default command is the contract.** An image whose default command is a shell, or is absent, forces every consumer to know something extra about it, and that knowledge lives in a wiki rather than in the artifact. 2. **A declared non-root user is a default worth shipping.** It means the safe behaviour happens even when the spec says nothing, and the spec can still escalate deliberately if it must. 3. **The working directory and environment entries carry assumptions** that would otherwise be rediscovered by whoever tries to run the image on a different platform. 4. **Declared ports and volume paths are the image documenting itself**, and consumers read them to wire things up correctly the first time. ## Common misreadings - **"Overriding the command rebuilt the image."** It did not. The override lives in the spec and the artifact is byte-identical before and after. - **"The declared port publishes the service."** It does not. Publishing is done by whatever routes traffic; the declaration is metadata. - **"The environment entries in the image are where configuration belongs."** They are defaults baked into a public artifact; per-environment values and credentials are delivered by the platform at start-up instead, and anything sensitive written here ships to everyone who pulls it. - **"The configuration blob is another layer."** It is a blob named by the manifest, fetched like a layer, but read as a document and never merged into the filesystem view. - **"If the spec sets nothing, nothing runs."** If the image declares a default command, it runs. That is what the default is for.
- If a spec overrides the default command, what does the image look like afterwards?Exactly as before. The override is applied by whatever starts the container and is recorded in the spec, not in the artifact. The manifest, the configuration blob and every layer keep their digests, and another consumer pulling the same reference still gets the publisher's default.
- Why is a declared non-root default user worth shipping even when specs usually set one?Because it makes the safe outcome the one that happens when nobody said anything. Specs written in a hurry, one-off debugging runs and unfamiliar platforms all fall back to the image's declaration, and an image that declares a privileged default hands them the worst case silently.
- Do the declared ports in the configuration open anything?No. They are metadata stating which ports the image expects to serve on. Whether anything reaches those ports is decided by the networking configuration around the container, which is a separate concern with its own rules.
- Where do per-platform differences show up in these defaults?Mostly in the fallback layer. When neither the image nor the spec states a value, platforms differ in what they assume and in how strict they are about missing values, so a workload leaning on a fallback rather than an explicit declaration is the one that behaves differently after a move.
saying these in an interview costs you the question
- Thinks overriding the command in the spec modifies the image.
- Believes a declared port makes the service reachable by itself.
- Treats the configuration blob as a layer merged into the filesystem.
- Says the image's defaults cannot be changed at start-up.
- Puts environment-specific values or credentials into the image's defaults.