skip to content

What does an explicit deny in a platform permission model do that simply not granting the permission does not?

level: middleimportance: should knowfreq 48%

answer

  1. absence already means no
  2. the question is who can reverse it
  3. any deny wins over every allow
  4. not first-match, not most-specific
  5. invisible to whoever grants next

basics

~20 s

Not granting produces an implicit deny, which any later allow overturns. An explicit deny is a rule that outranks every allow on either side, so it survives someone else adding a grant — and only editing or removing the deny itself undoes it.

solid answer

~40 s

The default answer to any call is no: with no matching allow anywhere, the platform refuses, and that refusal is an **implicit deny** that the very next allow removes. An **explicit deny** is a rule whose effect is deny, and on platforms that offer one it outranks every allow on the identity side and the resource side alike. That difference is about *who can undo it*. An implicit deny is undone by anyone who may write a grant; an explicit deny is undone only by editing or deleting the deny rule, which is normally in someone else's hands. That makes it the right tool for a rule that must survive delegated administration, and the wrong tool for everyday narrowing — where the honest answer is to grant less in the first place.

code

pseudocode · 11 lines
pseudocode
decision = DENY_BY_DEFAULT

for each rule in (rules attached to caller) + (rules attached to resource):
    if not rule.matches(principal, action, resource):
        continue
    if rule.effect == "deny":
        return DENY_EXPLICIT          // returns immediately: no later allow is read
    if rule.effect == "allow":
        decision = ALLOW              // keeps scanning, so a later deny still wins

return decision

go deeper

for a junior

Know that a principal with no grant is already denied, and that an explicit deny is a written rule rather than the absence of one.

for a middle

State the evaluation order confidently — any matching deny wins, otherwise any matching allow, otherwise refuse by default — and say why that is not the same as first-match or most-specific-wins.

for a senior

Recognise the fingerprint in production: correct grants that change nothing mean a deny somewhere, and know it may sit on either side of the call. Reserve denies for rules that must survive somebody else's grant.

for a principal

Decide who in the estate may write a deny and where denies are allowed to live, because an undocumented one is a permission failure with no local explanation — and check whether your platform offers the mechanism at all before a control depends on it.

## Two refusals that look identical to the caller A denied call is a denied call. Inside the model, though, there are two very different reasons for it. - **Implicit deny** — nothing granted this. The platform's default is refusal, so a principal with no matching allow is denied simply by absence. Adding any matching allow ends it. - **Explicit deny** — a rule was written whose effect is *deny*, and it matched. Where a platform supports this, the deny outranks every allow that also matched, on either side of the call. Adding more allows changes nothing. The practical difference is not strength of refusal but **who is able to reverse it**, and that is the whole reason the second one exists. ## Evaluation order in one line Collect every rule that matches the principal, the action and the resource, from the identity side and the resource side. If any of them denies, the answer is no. Otherwise, if any of them allows, the answer is yes. Otherwise the answer is no by default. Note what that ordering is *not*: it is not first-match, and it is not most-specific-wins. Engineers who learned packet filtering expect a narrow allow to carve an exception out of a broad deny, and in this model it cannot — the deny still wins, however precise the allow. ## What an explicit deny is genuinely for 1. **A rule that must survive delegated administration.** If account administrators can write grants, an implicit deny is worth nothing against them: they simply grant. A deny holds unless they can edit the deny itself. 2. **Carving an exception out of a grant you must keep broad.** Where a role genuinely needs wide reach, a narrow deny over the few resources it must never touch expresses the exception in one place instead of enumerating everything else. 3. **A fast, reversible stop during an incident.** A deny attached while an investigation runs stops a principal without unpicking the grants that may have to be restored afterwards. ## Why it is a poor everyday tool A deny is **invisible from where the next engineer is standing**. Someone adds a perfectly correct grant, the call still fails, and nothing in their own document explains why. Because a matching deny can sit on either side of the call — and on some platforms in a separate layer again — finding it means knowing it might exist. The result is a well-known failure mode: permission is "granted" three times by three people and the call never works. So the discipline is: express *what a principal may do* by granting less, and reserve deny for *what nobody may do here, whatever anyone grants later*. If a team is writing denies to trim the shape of a single principal's access, that shape should have been written as a narrower allow. ## Not every platform has one This is a real design difference. Some platforms provide a deny effect in the same documents as allows; some provide prohibition only through a separate policy layer with different semantics; and some express it only as absence, so the strongest statement available is "nobody granted it". If a candidate assumes an explicit deny is universally available, that is a portability assumption worth challenging — the mechanism to reason about is *whether this platform has a rule that outranks allows at all*, and if it does not, the protection has to come from controlling who may write grants. ## The interview answer Say that absence of a grant is already a deny, that the explicit kind exists to be *unoverridable by a later allow*, and give the ordering: any deny wins, otherwise any allow wins, otherwise no. Then name the cost — an invisible rule that turns a permission problem into a hunt — and say when you would still accept it.

  • If an explicit deny is so hard to debug, why not ban it outright?
    Because some rules have to hold against people who are allowed to write grants. Where an administrator can grant, absence protects nothing, and only a rule that outranks their allow does. The answer is to use it rarely, document where the few live, and keep everyday narrowing in the grants themselves.
  • A narrow allow and a broad deny both match the same call. Which wins?
    The deny. The model is not first-match and not most-specific-wins: every matching rule is collected, and a single deny settles it regardless of how precisely the allow was written. Expecting the narrow rule to carve an exception is the habit people bring from packet filtering.
  • How do you find the deny that is refusing a call?
    Start from the denial message, which on many platforms distinguishes an explicit refusal from the default one. Then check both sides of the call and any layer above the account, since a matching deny can sit in any of them. The behavioural tell is that adding grants changes nothing at all.

saying these in an interview costs you the question

  • Treats removing an allow and adding a deny as the same thing
  • Says the most specific rule wins, as in a packet filter
  • Believes an allow on the resource side overrides a deny on the identity side
  • Uses explicit denies to shape one team's everyday permissions
  • Assumes every cloud platform offers an explicit deny effect