You are introducing automated policy checks to teams that already ship infrastructure changes daily. What enforcement levels sit between "record the finding" and "block the apply", and how would you sequence the rollout so the guardrails survive contact with delivery pressure?
answer
- enforcement is not a binary switch
- advisory, soft-mandatory, hard-mandatory
- measure your own false positives first
- ratchet: gate new, backlog the old
- day-one hard-fail creates evasion, not compliance
basics
~20 sThree levels are standard: advisory reports only, soft-mandatory fails but a named owner can override with the override recorded, and hard-mandatory cannot be overridden at all. Roll out advisory first to find false positives and the real violation rate, then promote rules one at a time.
solid answer
~50 sHashiCorp's Sentinel names the three levels that most programmes end up with: **advisory** — the rule reports but never blocks; **soft-mandatory** — it fails the run, but a designated owner can override, and the override is recorded with who and why; and **hard-mandatory** — no override exists, so the only ways past are changing the code or changing the policy. The sequencing matters more than the taxonomy. Run everything advisory first across the whole estate: that tells you the true violation rate and, more importantly, exposes your own false positives before they cost anyone a deploy. Baseline the existing violations so the rules gate new changes rather than blocking every team behind a backlog they did not create. Then promote rule by rule, starting with the ones that are unambiguous and consequential. A day-one hard-fail on everything does not produce compliance; it produces people applying from laptops.
go deeper
Know that a policy check does not have to block. It can report only, fail with an override, or fail outright — and which one applies is a deliberate choice per rule.
Be able to name the three levels and give a rule that belongs at each, explaining what makes a rule safe to hard-fail: unambiguous, consequential, and with no legitimate exception.
Show the rollout judgment — advisory first to measure your own false positives, baseline the existing violations, promote rule by rule with notice — and explain why the alternative produces evasion rather than compliance.
Own the operating metrics of the programme: override rate as a rule-quality signal, backlog trend, and the volume of changes going around the gated path entirely. Be ready to argue for the fast override path that keeps the control legitimate under pressure.
## The levels Enforcement is not binary, and treating it as binary is the most common way a policy programme fails. The three-level model most organisations converge on — and the one HashiCorp's Sentinel names explicitly — is: **Advisory.** The rule is evaluated and the result is reported, but the run proceeds. Its purpose is information: it tells you how often the rule would fire, on whose changes, and whether it fires on things that are actually fine. An advisory rule costs a team nothing, which is exactly why it is safe to switch on everywhere at once. **Soft-mandatory.** The rule fails the run, and a specific, named authority can override the failure. The override is the interesting part: it is an event, attributable to a person, with a reason, recorded next to the change it unblocked. This is the level for rules that are right the great majority of the time but have legitimate exceptions you cannot express in the rule itself. **Hard-mandatory.** The rule fails and there is no override path. The only ways forward are to change the code so it complies, or to change the policy — which is itself a reviewed change to a version-controlled file. Reserve this for a small set: things that are unambiguous, consequential, and where no legitimate exception exists. If you find yourself editing the policy repeatedly to let changes through, the rule was not hard-mandatory material. ## Why the sequence, not the taxonomy, decides the outcome **Start advisory, everywhere.** You are measuring two things. The first is the real violation rate, which is almost always higher than anyone expects. The second — and this is the one that saves the programme — is your own false-positive rate. Every rule you write is a hypothesis about what is bad, and some of those hypotheses are wrong in ways that only real changes reveal. Discovering that in advisory mode costs a conversation. Discovering it after you have hard-failed a release costs you the team's willingness to be governed at all. **Baseline what already exists.** If a rule blocks every change touching a resource that has violated it for two years, you have made the rule the enemy of every unrelated piece of work. The ratchet approach is better: existing violations are recorded as a known backlog, new violations are blocked. The number that matters is that the backlog goes down and does not grow. **Promote rule by rule, not level by level.** "We are moving to enforcement in Q3" is not a plan. Promote one rule when its advisory data shows near-zero false positives and the teams have had notice. Publish which rule is being promoted and when. **Make failures actionable.** A failure message that names the rule, the offending resource, the reason, and the fix is the difference between a two-minute correction and an afternoon in a support channel. This is not cosmetic — perceived arbitrariness is what makes people route around a control. **Fail fast and early.** The check should give its verdict at the earliest point the change is reviewable, not at the moment of apply. A rule that only speaks up after an engineer has waited for a slow pipeline is technically the same rule and practically a much worse one. ## The pressure test Every guardrail eventually meets an urgent change. Design for that before it happens: know which rules have an override path, who holds it, and how quickly it can be exercised at 2am. A control with no legitimate fast path will be bypassed illegitimately — someone will run the tool locally, disable the check, or apply through a route that has no check at all. When that happens, the finding is not that the engineer was reckless; it is that the control had no design for the situation everyone knew would arrive. ## Signals the rollout is working - Advisory findings on new changes trending to zero *before* a rule is promoted. - Override rate low and, more importantly, stable — a rising override rate means the rule is wrong. - The pre-existing backlog shrinking. - No growth in changes applied outside the gated path. If that number is rising, your enforcement did not increase compliance; it increased evasion.
- How do you decide that a rule is ready to be promoted from advisory to blocking?By its advisory data. You want near-zero firings on new changes over a meaningful period, and every historical firing explained as either a real violation or a rule defect you have since fixed. On top of that: the failure message is actionable, the backlog of pre-existing violations is baselined so the rule does not block unrelated work, and the teams have had notice with a date. Promote one rule at a time so you can attribute any fallout.
- Your override rate on a soft-mandatory rule keeps climbing. What does that tell you?That the rule is wrong, not that the teams are undisciplined. A rule overridden routinely is either too broad, missing a legitimate case it cannot express, or attached to the wrong scope. Fix the rule — narrow it, add the missing condition, or split it into a strict version for sensitive environments and an advisory one elsewhere. Leaving it as-is trains everyone that overriding is normal, which is worse than not having the rule.
- Why is the volume of changes applied outside the gated path a rollout metric?Because it measures evasion, which is the failure mode enforcement creates. If blocking checks make the sanctioned path slower or less predictable than an unsanctioned one, work migrates to the unsanctioned one and your compliance numbers improve while your actual risk rises. Watching that number keeps you honest about whether the guardrail increased safety or just moved the traffic.
saying these in an interview costs you the question
- Switching every rule to hard-fail on day one to show commitment
- Treating a rising override rate as a discipline problem rather than a rule defect
- Blocking changes on violations that predate the rule
- Emitting failures like "policy violation: rule 47" with no resource or fix
- Having no override path at all for genuinely urgent changes