Your deploy renders the reporting warehouse password into a configuration file on each host — what is true of that file once the service has started?

## What injection settled Injecting a credential at deploy time settles two things: **where** the value comes from — a secret store rather than the source tree — and **when** it arrives, at release rather than at build. It settles nothing about what happens to the copy after it lands. A rendered configuration file is a **delivered copy at rest**: an ordinary file, owned by whichever identity the deploy ran as, carrying whatever mode the rendering step gave it, sitting in whatever directory the release layout uses. To the host it is not a secret; it is bytes on a disk. That is the point of this subject. A *control* bounds who may use a value and for how long. *Delivery* moves where the value comes from, and in doing so it creates a new resting place. Teams routinely report the first as though it were the second. ## Four properties the file inherits from the host - **An audience the deploy did not choose.** Every other process running as the same identity, any superuser on the box, an operator with shell access, a backup agent, a monitoring collector and any diagnostic tool that sweeps a directory. Mode and ownership narrow the first group; they do nothing about the rest. - **A lifetime nobody set.** No part of the system deletes it. It outlives the process, and it usually outlives the release, because release layouts commonly keep previous release directories on the host so a rollback is cheap. A file written eleven releases ago is still a file. - **Copies that were never written deliberately.** Host images, volume snapshots and backups taken while the file existed all contain it, and those artifacts routinely outlive the host and land in places with a wider audience than the host had. - **Staleness that is still usable.** Rotation puts a *new* value in the store. It does not reach back into a rendered file, and it does not stop the old value working. The previous value keeps being accepted by the warehouse until it is explicitly **withdrawn** there. ## What each common move actually buys | Move | What it stops | What it does not stop | |---|---|---| | Injecting instead of committing | The value sitting in the source tree, and in every clone of it | A readable copy resting on every host that ran the release | | Narrowing ownership and mode | Casual reads by other identities on the host | A superuser, a backup agent, a tool that collects files | | Encrypting the volume at rest | A stolen disk or a stolen backup being read | Any caller on the *running* host reading it in cleartext | | Rotating the value in the store | The next delivery carrying the old value | The previous value working until it is withdrawn | The last two rows are where candidates most often over-claim. Encryption at rest defends against the disk leaving the building; it is transparent to everything running on the machine. Rotation bounds what happens next; it is not a cleanup of what already escaped. ## Shrinking the resting copy 1. **Render to a path backed by memory that does not survive a reboot**, rather than into a durable release directory, so a power cycle is also a cleanup. 2. **Set ownership and mode to the one identity that reads it**, at render time rather than afterwards, so there is no window where it is world-readable. 3. **Delete it immediately after start-up** where the process reads its configuration once, and re-render on the next start. A file that exists for two seconds has a much smaller audience than one that exists for two years. 4. **Keep the path out of anything that collects files** — backup selections, image builds, support-bundle collectors. 5. **Clean previous release directories as part of the deploy**, not "eventually", so rollback convenience does not quietly become a credential archive. 6. **Prefer a credential whose scope is narrow**, so that the copy that does survive reaches less than the whole warehouse. ## Why this is a first-screen question It separates a candidate who has learned a slogan — *inject at runtime, never hardcode* — from one who can follow the value to where it comes to rest. The slogan is true and insufficient: it names the origin of the value, and the interviewer is asking about its destination. A good answer describes a specific file, names who on that host can read it, says what removes it and when, and states plainly that a rotation in the store changes nothing about the copy already on disk.