How does a guardrail demanding encryption at rest on every new store differ from one that denies an action outright?
answer
- same mechanism, different condition
- one removes, the other shapes
- the condition sees only the request
- creation is not the whole life
- it refuses; it never reports
basics
~20 sA deny removes an action entirely; a required-property constraint leaves the action available but refuses any request that omits the property. Both are evaluated on the call, so neither can see what happens to the resource afterwards.
solid answer
~50 sThe two are the same mechanism with different conditions. A plain deny removes the action for every principal beneath the ceiling - the store cannot be created in that region at all. A required-property constraint denies the same action *unless* the request carries the property, so the action survives and only the non-conforming shape of it is refused. That is usually the friendlier control, because teams can still do their work by asking correctly. What both share is their evaluation point: the call. A constraint can insist that a new store declares encryption at rest; it cannot insist that the key is rotated a year later, that the contents are what you expect, or that a setting is not changed by some later call unless that call is constrained too. Everything about the life of the resource after creation needs a different control.
code
pseudocode · 10 lines# evaluated on the constrained call
on call "documentStore.create":
if request.encryptionAtRest is not true:
return REFUSED
return ALLOWED
# never evaluated afterwards, unless that call is constrained too
# key rotated a year later -> not seen by this constraint
# documents written to the store -> not seen by this constraint
# setting changed by a later call -> seen only if that call is constrainedgo deeper
Recall the two shapes: one removes an action completely, the other allows it only when the request declares something. Both refuse the call rather than reporting on it afterwards.
Explain what the condition can actually test - the parameters of the call and the facts the platform attaches to it - and why that is the limit on which rules can live in a ceiling.
Show the gap you would close in practice: creation constrained but modification not, drift after the fact, and detection over existing state to answer what the constraint never could.
Decide what the estate insists on by default and what it merely observes. A required property is a standard imposed on every team beneath it, so pick the few where a bad default is genuinely unacceptable.
## Two shapes of the same ceiling A guardrail above the account is a set of removals evaluated against a management API call. There are two useful shapes: - **Deny the action.** "No principal beneath this node may create a document store in a region outside the approved list." The action disappears; there is no conforming way to perform it. - **Deny the action unless a property holds.** "No principal beneath this node may create a document store unless the request declares encryption at rest." The action remains available, and only the shape of the request that omits the property is refused. | | Deny the action | Require a property | |---|---|---| | What a team can still do | Nothing in that shape | The same work, expressed correctly | | What the refusal teaches | This is not available here | Add this to your request | | Typical use | An action with no acceptable form in this estate | A default the estate insists on | | What it is evaluated against | The call | The call, plus the property in it | | What it sees afterwards | Nothing | Nothing | The second shape is what people usually mean by a **guardrail** rather than a wall: the point is not to stop work but to stop one bad default. It also produces a far better failure, because the message points at the missing property rather than at an action the team simply cannot have. ## What the constraint can see A condition can only test what the call carries. That is a genuinely narrow surface, and it is the key to knowing which rules can live in a ceiling at all: - Parameters of the request - the region, the declared properties, the shape of what is being created. - Facts the platform attaches to the call, such as which principal is making it. It does not see the contents of the resource, the state of another system, or anything that happens later. ## What a ceiling cannot express - **The life of the resource after creation.** Whether a key is rotated, whether the encryption setting is changed by a later call that is not itself constrained, whether the data inside is what the classification claims. - **Anything the platform does not carry on the call.** Whether the owning team completed a review, whether the change has a ticket, whether the store is named in a data map. - **Intent.** A perfectly conforming request can still be the wrong thing to do; the constraint checks the shape, not the purpose. - **What already exists.** A constraint attached today evaluates the calls that come after it. It produces no inventory and no finding about the stores created last year. ## Where the rest of the control comes from 1. **Detection over what exists**, to answer the questions the constraint cannot: which stores lack the property, and since when. 2. **Constraining the calls that change the property later**, not just the call that creates the resource - otherwise the ceiling secures creation and nothing else. 3. **The grants inside the account**, which decide who may make those later calls at all. ## The direction to keep straight A required-property constraint is still a **preventive** control: it refuses a call, it does not report one. And its evaluation is at the call, not over the estate - so "every store has encryption at rest" is not something it proves. What it proves is narrower and worth stating precisely: since it was attached, no *conforming* creation call beneath it has omitted the property, and no non-conforming one succeeded.
- Your constraint covers creation only. What is the obvious way around it?Create the store conforming, then make a second call that changes the property. If that call is not constrained too, the ceiling secured one moment rather than a state. Constraining the modifying calls, and detecting resources whose property drifted, is what closes it.
- When would you prefer a plain deny over a required property?When there is no acceptable form of the action in this part of the estate - a region that may not be used at all, a surface with no legitimate use here. If a conforming version exists and you want teams to reach it, a required property refuses less and teaches more.
- Does the constraint prove that every store has the property?No. It proves that after it was attached, no creation call beneath it succeeded without declaring the property. Stores created earlier, and anything changed by a call the ceiling does not constrain, are outside what it can claim - those need a sweep of what actually exists.
saying these in an interview costs you the question
- Says the constraint scans existing resources and flags the non-conforming ones
- Assumes constraining creation also constrains later changes to the same setting
- Claims a condition can test a fact held in another system
- Treats a required-property constraint as a detective control that reports
- Believes a conforming request is by definition the right change to make