You attach an organization-level deny for every region outside the approved list - what does that deny not remove?
answer
- it governs calls, not state
- attached today, forward-looking only
- no region on the call, no condition
- the workload's own traffic is invisible to it
- it can refuse your own cleanup
basics
~20 sIt constrains management calls from the moment it is attached. Resources already running outside the approved regions keep running, surfaces with no region to test are untouched, and a workload copying data out itself is never evaluated by it.
solid answer
~40 sA region deny is evaluated on management API calls, so its reach ends where those calls end. Resources created before it was attached keep running - and the same deny may now refuse the calls you need to clean them up. Surfaces that present no region to test, such as identity and organization-level management itself, are not constrained by a condition on region. Nothing in it sees a service that legitimately runs inside an approved region and writes a copy to an endpoint elsewhere, because that is the workload's own traffic, not a management call. And it says nothing about the period before it was attached; that account lives in the audit trail. Treat it as a strong forward-looking control that needs a sweep of existing state and detection beside it.
go deeper
Recall that a policy above the account takes effect on calls made from then on. It does not tidy up what is already running, so someone still has to find and remove that.
Explain the boundary: the deny is a condition evaluated on management API calls, so it reaches exactly what those calls carry - and a region condition needs a region on the call to test.
Demonstrate the operating consequences: sequencing a clean-up against a deny that blocks its own remedy, checking which surfaces are region-scoped, and knowing that application traffic is a different control entirely.
Be clear about what you are willing to claim. Decide what the estate treats as proof of a geographic requirement, and where the residual risk sits once the ceiling has done everything it can.
## What the deny actually governs A **region deny** attached above the account is a condition on management API calls: when a principal in an account beneath it asks the platform to create or operate something, and the requested region is not on the approved list, the call is refused. That is a strong control, and it is the right one for the requirement. The senior question is what it leaves standing, because teams routinely mark the requirement closed the day it is attached. ## What it does not remove 1. **Resources that already exist.** The deny governs calls, not state. Anything created before it was attached keeps running exactly as before. Worse, if the deny covers all actions in that region rather than only creation, it can refuse the delete and reconfigure calls you now need - so the clean-up has to be sequenced, often by narrowing the deny temporarily or by acting from a principal the ceiling does not reach. 2. **Surfaces with no region to test.** A condition on region can only be evaluated where the call carries one. Estate-level and identity-level surfaces typically do not, so a policy written purely as a region condition passes them through. Providers differ in which of their surfaces are region-scoped, which is exactly why the coverage has to be checked rather than assumed. 3. **What a workload does with data it already holds.** A service running legitimately inside an approved region, reading the store and writing a copy to an endpoint somewhere else, makes no management API call at all. The deny never sees it. This is the gap that surprises people most, because the control looks like it is about *where data may be* and is actually about *where resources may be created and operated*. 4. **The period before it was attached.** A preventive control is evidence only from its attachment forward. Any question about the preceding months is answered from the recorded history of management calls and from a sweep of what exists now. 5. **Side effects of the resources you do allow.** Depending on configuration, logs, backups, replicas and support tooling associated with an approved-region resource may land somewhere else; providers differ in what follows the resource and what does not, so each of those has to be checked on its own rather than inferred from the deny. ## A coverage checklist | Risk | Covered by the region deny? | |---|---| | A team creating a store by hand in a denied region | Yes - the call is refused | | A delivery job launching capacity in a denied region | Yes - it is the same management call | | Resources already running there yesterday | No - and the deny may block cleaning them up | | A call on a surface that carries no region | No - there is no region for the condition to test | | An application copying documents to an external endpoint | No - it is the workload's own traffic | | What happened before attachment | No - only the recorded history answers that | ## How to close the gaps - **Sweep existing state before you claim coverage.** Inventory what exists in the denied regions, and plan the order of removal against the deny's own scope. - **Pair the deny with detection** over the recorded calls and over the resources that exist, so anything the condition cannot express still produces a finding. - **Handle the workload's own traffic as a separate control.** Where documents may not leave a geography, what stops that is the network path and the permissions available to the service, not a ceiling that reads management calls. - **Re-check coverage when the estate changes.** New accounts beneath the node inherit the ceiling, but a new surface, a new kind of resource or a new way of reaching the same data may not be region-conditioned at all. ## The direction to keep straight A deny **stops actions**; it does not clean up, it does not move anything, and it does not reach traffic that is not a management call. Saying "we denied the region, so nothing of ours is there" is the confident version of the mistake. The accurate statement is narrower and much more defensible: from the moment it was attached, no principal beneath it has been able to create or operate a region-scoped resource outside the approved list.
- The deny is attached and stores still exist in a denied region. How do you remove them?Check the deny's scope first: if it covers every action in that region, the delete call is refused too. Either narrow it to creation while the clean-up runs, act from a principal the ceiling does not reach if your design has one, or detach and re-attach around a planned window - and record what was removed.
- What stops a service inside an approved region from copying documents somewhere else?Not this ceiling. That is the workload's own traffic, so the controls are the network path available to it, the permissions it holds over the destination, and detection on what it actually sends. A region deny constrains where resources may be created and operated, not where bytes may travel.
saying these in an interview costs you the question
- Assumes attaching the deny removes or moves existing resources
- Claims the deny proves nothing was ever created outside the region
- Forgets that surfaces without a region are untouched by a region condition
- Thinks the deny sees an application copying data to an external endpoint
- Overlooks that the deny can refuse the cleanup calls it made necessary