The same rule runs as a PR check, a deploy job step and an admission controller — which still applies to a manual change?
answer
- one route versus every route
- who can act without the pipeline
- the API path a write must take
- on-path is a property of placement
basics
~20 sOnly the admission controller, and only for objects sent to the cluster API it fronts. A pull request check and a deploy job step both live inside a pipeline, so an engineer applying the change directly skips both.
solid answer
~50 sOnly the admission controller, and only for the surface it fronts. A pull request check and a deploy job step each sit on one particular route to the effect, so an engineer who applies the change directly with their own credentials skips both — the rule is fine, the placement is optional. An admission controller sits on the API path that every write to that cluster must take, so it sees the manual apply too. That is a property of placement, not of the rule. Two caveats matter: on-path is per surface, so a cloud resource created in the provider console never reaches a cluster admission controller at all; and a controller only enforces if a failed decision genuinely rejects the request rather than being configured to admit requests when the check is unreachable. A deploy job becomes enforcing only when its credentials are exclusive to it.
go deeper
Know that a check inside a pipeline runs only when the pipeline runs, so acting directly with credentials skips it entirely — nothing is overridden, the check is simply never asked.
Explain the difference between a check on one route to an effect and a check on the path every change to that surface must take, and say which of the three placements is which.
Bring the caveats: on-path is per surface, a controller that admits when unreachable is not reliably terminal, and a deploy step is enforcement only while its credentials are exclusive to it.
Be ready to argue where enforcement authority belongs for a given surface, accepting that the on-path placement is the slowest to change, the widest in blast radius and the worst at giving developers feedback.
### The question behind the question Interviewers ask this to find out whether you think of a gate as *a rule* or as *a rule at a position*. The rule text is identical in all three placements. What differs is how much of the traffic to the effect has to go past it. ### Placement one: the pull request check A check attached to a proposed change evaluates a document that a person chose to submit. Its authority comes entirely from the surrounding process — from the fact that the team agreed changes reach production by being merged. That agreement is real and usually holds, but it is a convention about *how people work*, not a constraint on *what the system permits*. An engineer at 5pm who has the credentials to apply the change directly does not need to defeat the check; they simply never invoke it. Nothing is bypassed, logged or overridden, because nothing was ever asked. ### Placement two: the deploy job step A check that runs inside the deploy job, just before the apply, looks stronger because the job is the thing that touches production. It is stronger — but conditionally. Its authority rests on one fact: *the job's credentials are the only credentials that can perform the action.* If the deploy role can be assumed by engineers, or if long-lived keys with the same permissions exist on laptops, then the job step is a check on one of several routes that all end in the same API call. The check did not fail; it did not run, because the step lives in the job and the human ran the command, not the job. This is why credential exclusivity, not rule quality, is what makes a deploy-time gate real. A useful diagnostic question: *who else can make this API call?* If the honest answer is more than one identity, the deploy step is advisory in practice. ### Placement three: the admission controller An admission controller is invoked by the API server as part of handling a write request. It does not care how the request was produced — a pipeline, a laptop, a script, a person typing — because it sits downstream of all of them, on the single path every write must take. This is the only one of the three that is on-path in the strict sense, and that is precisely why it is the most disruptive placement to operate and the slowest to change safely. ### The caveats that separate a good answer from a great one **On-path is per surface.** An admission controller is on-path for objects submitted to that cluster's API server, and for nothing else. A load balancer, a database or a virtual machine created through the cloud provider's own API never touches it. If the guardrail is about cloud resources, an admission controller is not a stronger placement — it is simply not on that path. **Terminal or not.** A controller that is configured to admit requests when it cannot be reached converts every outage of the controller into an open door. That configuration is a legitimate availability tradeoff, but it means the placement is on-path and not reliably terminal, and you should say so rather than describing it as unbypassable. **Scope of match.** A controller only decides on the request shapes it is configured to intercept. Objects or namespaces outside that scope pass without a decision, which is a coverage gap of the same kind as the one that lets the console click through. ### The general principle A gate enforces to the extent it is on the path the effect must take, and only if a denial actually terminates the action. Every other property — how good the rule is, how loudly it fails, who wrote it, how prominent the red X is — is downstream of that. This is why a mature answer to *is our guardrail enforced?* starts by enumerating principals and routes to the surface, not by reading the rule. ### Working the tradeoff None of this means every rule belongs at admission. The on-path placement is the hardest to iterate on, has the widest blast radius when wrong, and gives the worst feedback — a developer learns about the problem when the deploy fails rather than when they opened the change. The common pattern is to keep the fast, informative copy on the pull request for feedback, and put the copy you actually rely on at the on-path placement, being honest internally about which one is which.
- Does that admission controller cover a database created through the cloud console?No. It is invoked by the cluster API server, so it only ever sees requests sent to that API server. A cloud resource created through the provider's own API never reaches it. On-path is a property of a decision point relative to one surface, not a general strength ranking.
- The deploy job's role can also be assumed by four engineers. What have you actually got?An advisory check with extra steps. The job step is one route to an API call that four other identities can make directly, so the guardrail holds only while everyone chooses to use the pipeline. Either make the role assumable by the pipeline alone, or stop describing that step as enforcement.
- Why keep the pull request check at all if the on-path gate already denies?Feedback. The on-path denial arrives at deploy time, when the change is already merged and someone is waiting; the pull request check tells the author while they still have the change open. Keep both, but be explicit inside the team about which one is relied on and which one is guidance.
saying these in an interview costs you the question
- Says all three enforce equally because the rule is the same
- Thinks a deploy job blocks an engineer holding the same credentials
- Claims an admission controller sees cloud resources created outside the cluster
- Calls an on-path gate unbypassable without checking what happens when it is unreachable
- Confuses a check being required with a check being on the mutation path