What must a policy-as-code waiver record carry besides the rule id and a reason?
answer
- a reason string is not a waiver
- who, what, why, who said yes, until when
- narrow enough to name one workload
- owner is a team, not a person
- expiry is a field the engine reads
basics
~20 sA usable waiver names five things: who owns it, exactly what it covers, why the rule cannot be met, who approved it, and when it expires. A rule id plus free text is a note, not a waiver.
solid answer
~50 sA waiver is a record the engine reads while it decides, so it needs machine-usable fields, not prose. **Scope** is a selector narrow enough to name the one thing being excepted — this cluster, this namespace, this workload — so the rule stays live everywhere else. **Owner** is the team accountable for removing the need, recorded as a team, not a person who may leave. **Justification** says why the rule cannot be met and what compensates for it. **Approver** is an identity other than the requester. **Expiry** is a timestamp the rule itself compares against. Take a `no secrets in container environment variables` rule waived for one legacy vendor image that can only read its key from an env var: the record pins the exception to that workload, states that the key is rotated weekly and scoped to one endpoint, and dies on a date.
code
json · 12 lines{
"rule": "no-secrets-in-container-env",
"scope": {
"cluster": "prod-eu",
"namespace": "billing",
"workload": "vendor-statement-renderer"
},
"justification": "Vendor image reads its API key only from an env var; file-mounted secrets unsupported in this release. Key rotates weekly, scoped to one endpoint.",
"owner": "team-billing-platform",
"approved_by": "[email protected]",
"expires_at": "2026-10-15T00:00:00Z"
}go deeper
Be ready to list the fields from memory and say what each is for: scope, owner, justification, approver, expiry. Naming scope and expiry unprompted is what separates a real answer from "a rule id and a reason".
Explain why the record has to be data the engine reads during evaluation rather than a note elsewhere, and what a schema check on the record catches before it ever reaches a decision.
Show the judgment in the scope field: how narrow is narrow enough, and how you spot a waiver whose selector quietly covers far more than the change that triggered it.
Own the tradeoff between a record thorough enough to defend in an audit and light enough that a blocked engineer actually files one instead of routing around the gate.
## Why the record has a shape at all A policy engine decides by evaluating rules against an input document. An exception is only meaningful if it is part of that evaluation — data the engine loads and matches while deciding. The moment the exception lives somewhere the engine cannot read (a chat thread, a ticket, a person's memory), it stops being an exception and becomes a bypass that happens to be documented. That single constraint is what forces the field list. Every field exists because the engine, the approver, or the auditor needs to answer a specific question from the record alone. ## The five fields and what each one is for **Rule identity.** Which rule is being excepted. Obvious, and rarely the problem — the problem is that most teams stop here. **Scope.** A selector describing exactly what the exception covers. This is the field that decides whether your guardrail survives. Written as "rule: no-secrets-in-container-env" with nothing else, the record excepts every workload in the estate from a rule you presumably added for a reason. Written as cluster + namespace + workload name, or as one cloud account plus one resource-name prefix, it lets a single change through and leaves the rule enforcing everywhere else. The rule of thumb: the scope should be the narrowest selector that still lets the specific blocked change pass, and a reviewer should be able to read it and say out loud which resources it covers. **Owner.** Who is accountable for making the exception unnecessary. Record a team or a rotation, never an individual — waivers routinely outlive the engineer who filed them, and an orphaned waiver is one nobody will ever close. The owner is also who gets asked at renewal time. **Justification.** Two things, not one: why the rule genuinely cannot be met, and what reduces the risk in the meantime. "Needed for prod" is neither. "The vendor image reads its API key only from an environment variable and file-mounted secrets are not supported by that release; the key is rotated weekly and is scoped to a single endpoint" tells a reviewer what they are accepting and gives the renewal conversation something to check against. **Approver.** An identity distinct from the requester, ideally the same identity the change-control system already authenticates, so it cannot be self-attested by typing a name into a text field. If the record is stored as code, the approval is the review on that record's own change. **Expiry.** A timestamp, in UTC, that the rule compares against the time it is deciding. Without it the exception is permanent policy that nobody voted for. A missing or unparseable expiry should make the record invalid — the engine treats it as no exception at all, so the failure mode of a malformed waiver is a blocked change rather than an unlimited pass. ## The record is reviewed like the rule is Because the record is data the engine consumes, it deserves the same handling as the rule: a schema so that a waiver missing an owner or an expiry cannot be loaded, and a review step where a human reads the scope and the justification. Validating the waiver schema in the same place that validates the policies themselves is cheap and catches the two commonest defects — no expiry, and a scope that quietly covers the world. ## The chair this is usually asked from The honest version of this question is asked from the seat of the developer whose change was blocked at 17:00. They do not want to write a governance document; they want to ship. The design goal is that the record takes two minutes to fill in and still contains everything an auditor will want in nine months. That is achievable precisely because the fields are short: a selector, a team name, three sentences, an approver, a date. If your waiver process cannot be completed by a blocked engineer in a few minutes, they will find the path around it, and the path around it leaves no record at all. ## What a weak answer looks like A weak answer lists "a reason" and stops, or describes the waiver as a ticket. The tell of a strong one is that it names scope and expiry unprompted and explains why each is load-bearing: scope so the exception does not silently disable the control, expiry so the exception cannot outlive its own justification.
- How narrow should the scope selector be — the rule, the repository, or the single resource?The narrowest selector that still lets the blocked change through. For a data-residency rule, that is usually one account plus one resource-name prefix, not the rule globally. Broad scope is the quiet failure: the record looks like an exception but behaves like deleting the rule, and nobody notices because everything still goes green.
- Why keep the record where the engine reads it rather than in a ticketing system?Because the engine has to reach the same decision every time it runs, including on a rebuild months later. A ticket cannot be evaluated, cannot be matched against a scope, and cannot expire on its own. Keeping the record in the engine's data also means the exception appears in the decision output, so the evidence trail shows an approved exception rather than an unexplained pass.
- The engineer who filed a waiver has left the company. What breaks?Renewal and closure. Nobody is asked whether the condition still holds, so the waiver drifts on until its expiry — or forever, if it has none. That is why the owner field is a team or rotation identifier that survives staff changes, and why a periodic check for waivers whose owner no longer resolves is worth running.
It is a visitor badge, not a note left at reception: it names who vouched for you, which floor you may enter, and the hour it stops working.
saying these in an interview costs you the question
- Treats a free-text reason as sufficient justification
- Stores the waiver in a ticket the engine never reads
- Scopes the exception to the whole rule instead of one workload
- Records the owner as an individual rather than a team
- Omits expiry, or sets it years out for convenience
- Lets the requester approve their own waiver