A policy set above the account refuses your action although you hold full administrative permissions inside it - how does that work?
answer
- two layers decide, not one
- above the account, not inside it
- intersection, not union
- it subtracts; it never grants
- administrator can only grant beneath it
basics
~20 sA permission ceiling above the account subtracts from everything inside it. The effective permission is the intersection of the ceiling and the account's own grants, so an administrator can only grant within what the ceiling still leaves.
solid answer
~40 sA provider lets you attach a restrictive policy above the account, at a node of the organization hierarchy, and every account beneath inherits it. On each management API call the platform evaluates both that ceiling and the grants written inside the account, and the call succeeds only if both permit it. The ceiling itself grants nothing - it is a bound on what may be granted, so a principal with only the ceiling and no account grant can do nothing at all. Because an administrator's own broad policy lives inside the account, widening it cannot recover what the ceiling removed; an explicit deny above the account normally wins over any allow below it. The change has to be made where the ceiling is attached, by whoever administers that level.
code
json · 16 lines{
"attachedAt": "organization-node/regulated-unit",
"appliesTo": "every principal in every account beneath this node",
"rules": [
{
"effect": "deny",
"action": "documentStore.create",
"condition": { "regionNotIn": ["approved-north", "approved-south"] }
},
{
"effect": "deny",
"action": "documentStore.create",
"condition": { "encryptionAtRest": false }
}
]
}go deeper
Recall that some permissions are decided outside your account. If a call is refused while your permissions look complete, ask whether a policy above the account removes that action rather than adding another allow.
Explain the evaluation: both the ceiling above and the grants inside are consulted, the call needs both, and the ceiling can only remove. Be able to say why widening a policy inside the account changes nothing.
Show that you have operated this. Talk about opaque refusals surfacing mid-deploy, about a ceiling that denies the very call needed to clean up, and about which principals the ceiling does and does not reach.
Own the trade-off: a ceiling bounds the damage any account administrator can do, at the price of a refusal path your teams cannot resolve themselves. Decide how much of the estate's safety depends on a control they cannot see.
## What sits above the account An **account** is the unit that isolation, billing and quota attach to, and an administrator inside one normally has the last word about what happens there. A **permission ceiling** - often called a **guardrail policy** or an **organization-level deny policy** - breaks that assumption. It is a policy document attached *above* the account, at a node of the organization hierarchy, and every account beneath that node inherits it. Its author is not the account team; it is whoever administers that level of the estate. The ceiling is evaluated by the platform on management API calls made by principals in those accounts. That includes human administrators, workload identities and anything a delivery job runs - the ceiling does not distinguish between them, because it applies to the account, not to a class of caller. ## Why an administrator inside cannot grant past it The rule that matters is that **effective permission is an intersection, not a union**: 1. The platform asks whether the ceiling removes this action. If it does, the call is refused and nothing inside the account is consulted further. 2. If the ceiling leaves the action available, the platform asks whether a grant inside the account permits it. 3. Only if both are satisfied does the call proceed. Two consequences follow. First, **a ceiling permits nothing by itself** - a principal that is covered by a permissive ceiling but has no grant inside the account still cannot act, because the ceiling only bounds what may be granted. Second, **an administrator cannot exempt their own account**, because every document they can write - an identity-attached policy on a principal, a resource-attached policy on the thing being called - is inside the account, beneath the bound. An explicit deny above the account normally wins over any allow below it. ## Ceiling against grant, side by side | | Permission ceiling above the account | Grant written inside the account | |---|---|---| | What it can do | Remove permission only | Give permission | | Effect on its own | Nothing becomes possible | Names what a principal may do | | Who can change it | Whoever administers the level it is attached to | An administrator of the account | | Typical shape | Deny an action, or deny it unless a condition holds | Allow an action on named resources | | Who it reaches | Every principal in every account beneath | The principals and resources it names | ## What this buys, and what it costs - It **bounds the blast radius of a compromised or mistaken account administrator**. Whatever credentials leak inside the account, they cannot reach past the ceiling. - It **fails at the API, not in a review**. The refusal arrives when the call is made, which is the whole point of a preventive control - but it means an unexpected refusal surfaces during a deploy. - The refusal is often **opaque**: the caller sees that they are not authorised, not that a policy two levels above their account removed the action. Teams lose hours to this, and it is worth documenting which ceilings exist even though the accounts cannot change them. - A ceiling can **deny the call you need in order to repair something**, including a delete or a reconfiguration on a resource that is now out of policy. - Designs differ on whether the identity that manages the organization itself is subject to the ceilings it attaches; assume it may not be, and do not build a claim of universal coverage on it without checking. ## The mistakes this question is asked to catch Interviewers ask this to separate a candidate who has only written permissions inside one account from one who has operated an estate. The classic wrong answers are that the ceiling *grants* something, that it is simply a stronger version of a policy inside the account, or that an administrator can write a broad enough allow to get past it. The correct model is a ceiling and a floor: the ceiling is set above and subtracts, the grants are written below and add, and the call needs both.
- If the ceiling only subtracts, what still has to exist before a principal can do anything?An explicit grant inside the account, attached to the principal or to the resource being called. A permissive ceiling authorises nothing on its own; it only describes the largest set of actions that a grant inside the account is allowed to reach.
- A team needs an action the ceiling removes. What actually has to change, and who can change it?The ceiling itself, at the node of the organization hierarchy where it is attached, by whoever administers that node - or the account moves to a node with a different ceiling. Nothing written inside the account changes the outcome, including a broader identity-attached or resource-attached policy.
- Does a ceiling apply to workload identities as well as to people?Yes. It is evaluated on management API calls from any principal in the accounts beneath it, so a delivery job or a service using short-lived credentials is bounded exactly as a human administrator is. That is usually the point, since most estate changes are made by automation.
saying these in an interview costs you the question
- Says the ceiling grants permissions the account did not otherwise have
- Thinks an account administrator can write a broad enough allow to get past it
- Treats it as just a stronger identity-attached policy written inside the account
- Expects an allow inside the account to beat an explicit deny above it
- Assumes it applies only to human users and not to workload identities
- Believes the ceiling replaces the grants inside the account rather than bounding them