An organization-level deny keeps your document store out of unapproved geographies - what does it buy that an audit-trail alert does not?
answer
- two controls, two different moments
- one changes what is possible
- the other changes what is known
- the gap between them is exposure time
- prevention costs flexibility, detection costs time
basics
~10 sA preventive control refuses the call, so the disallowed state never exists. A detective control only records that it happened, leaving an exposure window and someone who must notice and undo it.
solid answer
~50 sThe deny is a **preventive control**: it is evaluated when the creation call is made, the call fails, and no store is ever created outside the approved geographies. The alert is a **detective control**: the store exists, the action lands in the audit trail, a rule matches it and a human is told - so the gap between the action and the response is real exposure, and someone still has to remove what was created. Prevention costs flexibility, because a legitimate exception now fails at the API with an opaque refusal that the account cannot resolve. Detection costs exposure time, and it depends on someone acting on the finding. A regulated estate normally runs both: the deny for what must never exist, detection for the rules the deny cannot express and for evidence of what happened before it was attached.
go deeper
Recall the difference in one line: a preventive control stops the action, a detective control reports it after the fact. Never describe an alert as something that stopped anything happening.
Explain the mechanics of each: where the deny is evaluated, what the detective rule reads, and what remains after each one fires. Be able to name the exposure window and who has to close it.
Show the operating reality: opaque refusals landing in a deploy, findings nobody works, and a ceiling attached after resources already existed. Say which risks you would prevent and which you would knowingly only detect.
Frame it as an allocation. Every rule you make preventive is flexibility you take from every team beneath the ceiling; every rule you leave detective is an exposure window you accepted and must staff.
## Two different promises A **preventive control** changes what is possible. A **detective control** changes what is known. Both can be written against the same rule - "documents for this business must not sit outside the approved geographies" - and they are not interchangeable, because they act at different moments and leave different things behind. The preventive form here is a policy above the account that denies the creation call when the requested region is not on the approved list. It is evaluated by the platform before anything is created, and the caller gets a refusal. The detective form is a rule reading the **audit trail of management API calls** - or a periodic sweep of what exists - that matches a store outside the approved list and raises a finding. ## What each one actually gives you | | Preventive ceiling above the account | Detective rule over the record | |---|---|---| | When it acts | Before the state exists | After the state exists | | What it leaves behind | A refused call, normally recorded in the audit trail | The created resource, plus a finding | | Who it interrupts | The engineer or job making the change, immediately | Whoever owns the alert, later | | What it needs | The rule expressible as a condition on the request | A recorded action, and someone who acts on it | | Its failure mode | Refusing legitimate work, opaquely | An exposure window, and alert fatigue | | Evidence it gives | That nothing got through after it was attached | What did get through, and when | ## What prevention costs - **A legitimate exception now fails at the API.** The team affected cannot resolve it, because the ceiling is above their account; the fix has to come from whoever administers that level. - **The refusal is opaque.** The caller usually sees only that the action is not authorised, not that a policy above their account removed it. - **It can deny repair.** A deny scoped to every action in a region can refuse the very calls you need to clean up what is already there. - **It only covers what can be expressed as a condition on the request.** A rule that depends on a fact the platform does not carry on that call cannot be written as a ceiling at all. ## What detection costs - **The exposure window is real.** Between the action and the response, the disallowed state exists - and for data landing somewhere it may not be, existing for an hour may already be the harm. - **It needs a responder.** A finding that nobody works is a control on paper. The measure of a detective control is time-to-action, not the number of rules. - **It is judged by the estate, not by the rule.** Detection over an account nobody enrolled sees nothing, and silence looks identical to compliance. ## Why a regulated estate runs both 1. **Prevent what must never exist even briefly** - the actions whose harm is immediate and hard to undo. 2. **Detect what the ceiling cannot express** - the rules that depend on facts outside the request, and everything about the life of a resource after it was created. 3. **Detect what happened before the ceiling was attached.** A deny constrains calls from the moment it is in place; the record is the only account of the period before that. ## The trap this question exists to catch The common error is describing a detective control as though it prevented something: "we alert on stores created outside the approved regions, so that cannot happen". It can happen - the alert is proof that it did. The inverse error is quieter: treating a newly attached deny as if it had cleaned anything up. It refuses future calls; what already exists is untouched by it, and may now be harder to remove.
- If the deny refuses the call, is there anything left in the audit trail?Normally yes - a denied management call is usually recorded like any other, with the principal and the requested action. That record is what tells you a team is repeatedly attempting something the ceiling removes, which is often a sign the ceiling is misplaced rather than that anyone is misbehaving.
- Your deny was attached last month. What can it tell an auditor about the six months before that?Nothing. A preventive control constrains calls from the moment it is in place, so the only account of the earlier period is the recorded history and whatever a sweep of existing resources finds now. That is one reason detection is kept even where prevention works.
- A rule depends on whether the team owning the store has completed a review. Preventive or detective?Detective, in practice. The creation call carries what the platform knows about the request, and a review status held in another system is not part of it. Detection can join the recorded action with that fact afterwards, which prevention at the API cannot.
A locked gate stops a visitor entering; a visitor book records that they came in. Both are controls, but only one of them means the room was never entered.
saying these in an interview costs you the question
- Describes an alert as if it had prevented the action
- Says a newly attached deny removes resources that already exist
- Treats a finding nobody works as an effective control
- Assumes a refused call leaves no record at all
- Claims prevention is always preferable regardless of the false-refusal cost
- Thinks detection over unenrolled accounts still proves compliance