You are asked a third time to add an admission rule for a fact the request never carries — what do you say?
answer
- yes to the requirement, no to the placement
- name the missing input, not the general limit
- find who is asking and why
- record the absence explicitly
- refuse the proxy and the warn-only patch
basics
~20 sAccept the requirement and refuse the placement. Name the fact that is missing from the request, name where it exists and who owns the check there, get the requirement recorded against that owner, and state on the coverage map that admission enforces nothing for it.
solid answer
~50 sSeparate the requirement from the mechanism: yes to the requirement, no to admission. Say concretely which fact the request does not carry, because 'admission cannot do that' has clearly not landed twice already. Then do the part that actually ends the loop — find who is asking and why. Usually someone needs to show a control exists, so give them evidence from the place that has the fact rather than a green admission log. Get the requirement written against a named owner with a date, and record on the coverage map that admission deliberately enforces nothing here, so the absence is a stated decision rather than a silence someone rediscovers. Refuse the two patches that end the meeting and damage the estate: a proxy rule that decides a different question, and a warn-only rule over unverified input that manufactures the appearance of coverage.
go deeper
Understand that the right response to an impossible rule is not to write a weak version of it. Say which piece of information is missing and ask where that information does exist.
Practise stating the limitation concretely — the specific input the request lacks — rather than as a general claim about what admission can do. Concrete refusals get accepted; general ones get re-litigated.
Show you would land the requirement somewhere real, with an owner and a date, and would explicitly record that admission enforces nothing for it rather than leaving a silence.
Own the trade behind the refusal: the shared gate's latency budget and, more importantly, its credibility with delivery teams, both of which are spent by rules that decide nothing.
### Why it came back a third time A technically correct refusal that gets repeated three times is not working. Something else is driving the ask, and it is almost never a disagreement about the payload of an API request. Common drivers: - Someone owes an answer to an auditor or a customer questionnaire and knows how to point at a cluster gate but not at anything upstream. - A previous incident is being closed, and 'blocked at deploy' is the closure everyone recognises. - The control genuinely does exist upstream, and nobody outside that team can see it. The third is the most common and the most fixable. If the requirement is already honoured somewhere and simply invisible, the fix is visibility, not a rule. ### The answer, in order **1. Grant the requirement.** Do not spend the meeting arguing about whether the risk matters. It does; that is not the disagreement. **2. Be concrete about what is missing.** Not 'admission cannot see that', but 'the create request contains the object and the requester's identity, and the fact you need is established at build time and never appears in the request'. A general statement about limits is what people argue with; a specific missing input is what they accept. **3. Name the home and the owner.** A refusal that ends there gets reheard as obstruction. Say where the fact exists, who owns the check there, and what it would take to make it enforce. **4. Get it written down against that owner.** With a date. The failure mode of a correct refusal is that the requirement evaporates and reappears as the same ask next quarter. **5. Record the absence.** State on the coverage map that admission enforces nothing for this requirement and will record nothing about it. That sentence is the deliverable of this whole conversation. An estate where every uncovered requirement is a silence is an estate where nobody can tell refusal apart from oversight. **6. Serve the real need.** If the driver is evidence, produce evidence from the control that exists — a report from the place that holds the fact, with the same regularity and the same audience the requester expected from the gate. ### The two patches to refuse, and why they are worse than nothing **The proxy rule.** Enforce something admission *can* see that correlates with the requirement — only images from the repository the compliant pipeline writes to, only workloads submitted by the deploy identity. These are often good rules on their own merits. As an answer to this requirement they are a category error, and the damage is that they will be *reported* as covering it. Six months later someone finds the requirement listed as enforced, traces it to a rule that decides a different question, and now every other line on that map is in doubt. **The warn-only rule over unverified input.** It costs nothing today and it is the more seductive of the two, because it feels like a stepping stone. It decides on data the person being checked controls, it produces warnings that teams learn to scroll past, and it puts a line in a report that cannot be defended when someone asks what it actually verified. Enforcement staging is a legitimate technique when the rule can eventually be right; it is not a way to stage a rule that can never be right. ### The organisational judgment underneath The deeper call is about what the cluster gate is *for*. Every rule placed there costs a shared latency and availability budget, and every rule teams cannot reason about costs credibility — the currency that makes the rules that matter survive contact with a deadline. Spending both on a rule that decides nothing is a poor trade twice over. There is also a scaling argument worth making out loud. Admission is the most visible enforcement point in the platform, so it attracts every requirement anyone can phrase as 'block it at deploy'. If the team says yes to the ones that do not fit, the gate accretes rules built on assertions, and the first time one of them blocks an urgent fix for a reason unrelated to the risk, the organisation learns that the gate is arbitrary. Protecting the gate's legitimacy is part of the job. ### What good sounds like *The requirement stands and I will help land it. It cannot land at admission, because the fact is established at build and the deployment request never carries it. It belongs with the team that owns the build inventory; I will write it against them with a date, and I will mark on the coverage map that admission enforces nothing here so nobody reads silence as coverage. What I will not do is add a rule over metadata the submitter writes — that gives you a line in a report and no control.*
- What if the compliance owner insists the control must exist at deploy time?Ask what deploy-time buys them. If the answer is that it cannot be skipped, that property can be arranged where the fact exists. If the answer is that a report needs a line under deploy, that is a reporting problem and should be solved by reporting the real control, not by inventing one that decides on data the submitter controls.
- How do you stop the same request arriving a fourth time?Write the decision where the next person looks, not in a thread: the rule that was asked for, the specific fact the request cannot carry, where the control lives now, and its owner. Repeat asks are usually a symptom that nobody outside one team can see the existing control, so publishing its evidence often does more than the refusal did.
- Is a warn-only rule really that harmful if it costs nothing to run?It costs the thing you cannot buy back. It reports a control that decides on unverified input, so the coverage map becomes untrustworthy, and warnings nobody can act on train teams to ignore the gate's output generally. Staged enforcement is for rules that will eventually be correct, not for rules that never can be.
saying these in an interview costs you the question
- Adds the rule to end the argument
- Refuses without naming where the control belongs
- Lets a proxy rule be reported as covering the requirement
- Leaves the uncovered requirement as an unrecorded silence
- Treats a warn-only rule over self-asserted data as a first step