Where can a policy check run between a developer's editor and a running container, and what does each point see?
answer
- one change, several chances to judge it
- each point is handed a different document
- source text, rendered object, live process
- earlier is faster, later sees more
basics
~20 sA change passes several decision points: editor and pre-commit, pull request, build, artifact promotion, admission, and runtime. Each is handed a different document — raw source early, the fully rendered object at admission, the live workload last — so each can decide different rules.
solid answer
~50 sThe same change is judgeable in several places, and the useful way to tell them apart is by what each one is handed. An editor or pre-commit check reads the file as typed. A pull-request check reads the diff and the repository at that revision. A build check adds whatever the build resolves — dependencies, generated files, rendered templates. A promotion check sees a finished artifact plus the environment it is heading to. An admission check sees the fully rendered object the platform is being asked to accept, including anything a pipeline or a templating step injected. A runtime check sees the workload as it actually exists: resolved environment variables, mounted files, the running process. Earlier points give faster, cheaper feedback; later points see a more complete picture. That trade is the whole placement decision.
go deeper
Be ready to name the points a change passes through — editor and pre-commit, pull request, build, promotion, admission, runtime — and say in one line what each one is handed to judge.
Explain why the input differs at each point: source text before templating, a rendered object at admission, a resolved environment at runtime. Expect to name a violation that only appears after rendering.
Show how you pick a home for a new rule: the earliest point whose input can decide it, plus a later one when a later input can create the violation. Be ready to justify running both.
Own the trade across an estate. Every extra decision point costs engineering time to run and keep correct; every point you skip lengthens the gap between the mistake and the feedback, and someone has to own that number.
## The path a change travels Between the moment an engineer types a line and the moment a process is serving traffic, the change passes through a sequence of places where a policy engine can be handed something and asked for a decision. The standard list, in order: | Decision point | What it is handed | |---|---| | Editor / pre-commit | The file as typed, before any templating or substitution | | Pull request | The diff and the repository at that revision | | Build | Source plus what the build resolves: dependencies, generated files, rendered templates | | Artifact promotion | The finished artifact and its metadata, plus the environment it is being promoted into | | Admission | The fully rendered object the platform is asked to accept | | Runtime | The workload as it actually exists: resolved environment, mounted files, the process | The list is not a maturity ladder where later is better. It is a list of **different inputs**. A rule can only be decided where its input is visible, and a rule is only *useful* where the feedback lands on someone who can act on it. ## Two axes: latency and visibility Every placement trades these against each other. **Latency** is how long after the mistake the author hears about it. An editor check answers in under a second, while the engineer still has the file open and the intent in their head. A pull-request check answers in minutes, to someone still working on that change. An admission check answers on deploy day — possibly days later, often to a different person, in an error message that has to travel back through a pipeline log. **Visibility** runs the other way. The earliest points see the least. Source text is what a human wrote; it is not what the platform will run. By the time you reach admission, templating has expanded, variables have been substituted, defaults have been applied and the pipeline has injected whatever it injects — the object in front of you is much closer to reality, and correspondingly later. ## A worked example: secrets as plain environment variables Take a standard that says a workload must not receive secret material as a plain environment variable. Where does that rule live? At **pre-commit**, the rule reads source text and can catch the obvious case: someone typed a password directly into a manifest or a compose file. That is a real catch, it costs nothing, and it lands on the author immediately. But a secret can reach a container's environment without ever being written literally in the repository — a reference in the manifest that the platform expands into a plaintext variable, a value the deployment pipeline supplies, or an injector, init container or operator that adds environment entries as the workload starts. None of that exists in the source text, so no source-text rule can see it. Only a check over the **resolved environment** observes the condition the standard is actually about. Same standard, two inputs, two homes. ## What each point structurally cannot see This is the map worth memorising, because it is what an interviewer is testing: - **Pre-commit** cannot see rendered values. Templating, variable substitution and platform defaulting all happen after it. - **A pull-request check** reads what is in the repository. It cannot see what the pipeline will inject at deploy time, because that is configured elsewhere. - **A build check** has no environment context. It does not know which cluster, namespace or account the artifact will land in, or what is already deployed there. - **An admission check** sees one submitted object. It does not see the process that will result from it, nor anything about how the workload behaves once it is running. - **A runtime check** sees the truth and sees it too late to prevent the change; by definition the thing already exists. ## How you choose A workable default: put the rule at the **earliest point whose input can actually decide it**, so feedback is cheap and lands on the author. Then add a later home only when a later input can produce a violation the earlier one structurally could not see — as with the injected secret above. That second home is not redundancy; it is a different question over a different document. The failure mode this framing prevents is the confident claim that because a scan of the repository is green, nothing bad can reach production. The repository is one of six documents, and it is the one furthest from what actually runs.
- If later points see more, why bother running checks at the earliest ones at all?Because feedback latency is a real cost. A check in the editor answers while the author still has the file open and the intent fresh; the same violation caught on deploy day reaches a different person, days later, through a pipeline log. Early checks also keep obviously broken changes out of shared branches, so the expensive points spend their time on the cases only they can decide.
- Why check an artifact again at promotion when the build already checked it?Because promotion is the first point that knows where the artifact is going. Rules conditioned on the target environment — stricter requirements for production than for a sandbox — are undecidable at build time, when the destination is not yet chosen. The artifact has not changed; the input has grown by one fact that the rule needs.
- What does an editor or pre-commit check see that a runtime check never can?Intent and origin. Early points see the file, the diff, the surrounding comments and the person at the keyboard, so they can say which line to change and why it was written. A runtime check sees a resolved value with no history — it can tell you the container holds a plaintext secret, but not which file, template or injector put it there.
It is the difference between proofreading a recipe, tasting the batter and tasting the finished cake. Each catches mistakes the others cannot, and only the first one is cheap to fix.
saying these in an interview costs you the question
- Claims the earliest check makes later ones unnecessary
- Treats every decision point as seeing the same input
- Assumes a check on source text sees the rendered result
- Calls runtime checks pointless because the build passed
- Describes the points as a maturity ladder rather than different inputs