Why is a pull-request policy check advisory when an in-cluster reconciler is the only thing that applies manifests?
answer
- who actually writes to the cluster?
- the applier never reads CI status
- gates merging, not applying
- the reconciler trusts the branch
- authority sits at the write
basics
~20 sMerging is not deploying. The reconciler reads whatever sits on the tracked branch and applies it, without consulting the check that ran on the pull request. The check informs humans; it has no authority over the applier.
solid answer
~40 sIn push-based delivery the deploy step runs after the checks in the same pipeline, so ordering gives the check its authority: red check, no apply. In pull-based delivery the applier is an agent inside the cluster that watches a branch and writes the difference between the branch and the live objects. Its input is the branch content, not a CI result, so a policy check on the pull request cannot stop it. The check's only real lever is on merging: making it a required check keeps a violating commit off the branch in the first place. Once a commit is on that branch it will be applied. So if a rule genuinely has to be prevented rather than reported, something must sit in front of the reconciler's writes to the API server.
go deeper
Be ready to say plainly that merging and deploying are two separate events here, and that the agent applying the manifests reads the branch rather than the build result.
Explain the mechanism: the applier lives in the cluster, takes the branch as its only input, and the required-check lever acts on merging rather than on applying.
Show that you can name the routes around the pull-request path, and place the only preventive control at the point the reconciler writes to the API server.
Own the trade: you keep the early check for feedback while accepting it enforces nothing, and you fund the control at the write. Argue why paying for both is cheaper than pretending one is the other.
## Two shapes of delivery, two places the authority lives In **push-based** delivery a pipeline holds cluster credentials and runs the apply as one of its own steps. The policy check is an earlier step in the same run, so the ordering itself is the enforcement: if the check fails, the run stops and the apply step never executes. The gate has authority because it is upstream of the only thing that writes to the cluster. In **pull-based** delivery nobody outside the cluster holds those credentials. An agent runs inside the cluster, watches a branch (or a path within it), compares what it finds there to the live objects, and writes the difference. That loop takes exactly one input: the content of the branch. It does not query the forge for the status of the commit, and it has no notion of a run being green or red. ## Advisory by construction, not by misconfiguration This is the phrase worth carrying into an interview. The pull-request check is not advisory because someone forgot to mark it required or wired it up badly. Even perfectly configured, its result is simply not an input to the thing that applies. The only lever the repository side has is over **merging**: a required status check stops a violating commit from landing on the tracked branch at all. That is a real and useful lever, but notice what it protects. It protects the branch, not the cluster. ## Why protecting the branch is weaker than protecting the cluster Suppose the rule is that every workload must declare resource requests and limits, and every namespace must come with a NetworkPolicy. If the pull-request check is your only control, the guarantee you actually have is: *no commit that this check evaluated and failed was merged through the pull-request path*. Several things live outside that sentence. - Commits reach a branch by other routes: a direct push by someone with elevated repository permissions, an automated bump from a bot, an emergency merge. - The reconciler may track more than the one repository or path your check runs on. A second path, a chart pulled in as a dependency, or a manifest generated at apply time is desired state that your check never saw. - The thing the check reads and the thing the cluster receives may not be identical. Anything expanded, defaulted or filled in after the check ran is unevaluated. - Objects created by controllers from what was applied are never in the repository at all. Nothing in git describes them, so no repository check can inspect them. Each of these is a path from a non-compliant object to a live cluster that runs entirely around the pull-request check. ## Where the authority actually sits The authority sits at the write. The reconciler's changes reach the cluster as ordinary API requests, and the only control that can refuse one is the one the request must pass through on its way in: an admission gate. In a pull-based pipeline that is the sole preventive control that covers the applier, because it is the sole control the applier cannot go around. Everything upstream of the merge is feedback. ## So why run the pull-request check at all Because feedback is worth a great deal, and it is worth it for reasons that have nothing to do with enforcement. The check runs in the author's own context, in seconds, on the change they are still holding in their head, and before the change becomes the cluster's desired state. It will catch the overwhelming majority of violations cheaply, it gives reviewers a signal, and it keeps the cluster gate for the residue. Losing that would be a bad trade. Confusing it for enforcement is the mistake. ## The shape of the failure it leaves behind The combination produces a distinctive failure that is worth recognising: a change merges with everything green, and then simply does not appear. The refusal happened somewhere the author was not looking, at a time after the pull request was already closed, and it is reported by a component the author does not own. Understanding that the repository check has no authority is the first half of understanding why that failure looks the way it does. ## What a weak answer sounds like A weak answer says the check is advisory because it was not marked required, or claims that the reconciler waits for CI to go green before syncing. Both invert the direction of control. In pull-based delivery, control over merging and control over applying are two different powers held in two different places, and only one of them touches the cluster.
- If the pull-request check cannot block the apply, what is it still worth running for?Feedback speed and volume. It runs in the author context, in seconds, on the change they are still working on, and before that change becomes the cluster desired state. It catches the large majority of violations cheaply and gives reviewers a signal, which leaves the cluster gate handling a small residue rather than being the first line.
- What is the one thing the repository side can genuinely prevent here?The merge. Marking the check required means a violating commit never lands on the branch the reconciler watches, so it is never desired state in the first place. That is real authority, but it is authority over the branch, not over the cluster.
- Does making the check required make the in-cluster gate unnecessary?No. Commits reach a tracked branch by routes the pull-request path does not cover, the reconciler may watch more paths than you gate, and objects created by controllers from what was applied never appear in git at all. The reconciler applies whatever it finds, so the write still needs a control in front of it.
The check is a proofreader who can refuse to let a page into the printing queue. The press operator prints whatever is in the queue and has never met the proofreader.
saying these in an interview costs you the question
- Thinks a green pull-request check means the change deployed
- Assumes the reconciler reads CI status before applying
- Says the CI job is what applies the manifests
- Claims a required check alone keeps the cluster compliant
- Calls the check advisory only because it was configured wrong