Your team must make a public grant on any store impossible rather than merely reviewed — what does an account-level override give you?

seniorshould knowfreq 44%

answer

above the store, not in it
stopping differs from noticing
a different owner holds the pen
aimed at one caller: anyone
the public case needs its own home

basics

~20 s

A preventive control. An account-level override refusing public grants sits above every store in the account, so a rule naming an unrestricted caller is rejected when written or ignored when evaluated, whatever a project team puts in a store's policy.

solid answer

~40 s

An override set at account level says that no store in this account may grant access to an unrestricted caller, and it is enforced by the platform rather than by review. A team can still write such a rule; it is either refused at write time or has no effect at request time, so the outcome no longer depends on anyone noticing. That makes it preventive, which is a different class from a scanner or an alert — those are detective controls that tell you the exposure already happened. The cost is that genuinely public assets now need a deliberate exception, owned above the team. It also targets exactly one thing: grants to anyone, not an over-broad grant to a named external account, and not links already signed.

An override set at account level says that no store in this account may grant access to an unrestricted caller, and it is enforced by the platform rather than by review. A team can still write such a rule; it is either refused at write time or has no effect at request time, so the outcome no longer depends on anyone noticing. That makes it **preventive**, which is a different class from a scanner or an alert — those are detective controls that tell you the exposure already happened. The cost is that genuinely public assets now need a deliberate exception, owned above the team. It also targets exactly one thing: grants to anyone, not an over-broad grant to a named external account, and not links already signed.

code

json · 22 lines

json

{
  "accountOverride": {
    "scope": "account:412",
    "forbid": "anyGrantNamingAnUnrestrictedCaller",
    "appliesTo": ["everyStoreInAccount", "everyObjectInThoseStores"],
    "editableBy": "organizationOwner"
  },

  "policyWrittenByTheTeam": {
    "policyAttachedTo": "store/receipts",
    "rules": [
      {
        "effect": "allow",
        "principal": "anonymous",
        "action": ["readObject"],
        "resource": "store/receipts/*"
      }
    ]
  },

  "outcomeAtRequestTime": "anonymous read refused: the override is evaluated above the store"
}

go deeper

for a junior

Know that some controls sit above an individual store and refuse settings a team writes inside it, and that stopping an action is different from being told it happened.

for a middle

Explain the mechanism: the override is evaluated above the store's own policy, so a grant to an unrestricted caller is refused or ignored no matter who wrote it.

for a senior

Show the rollout and the limits: inventory, warn, enforce at the right boundary, keep detection, and name what the override does not cover — named external grants, broad internal permissions, live signed links.

for a principal

Decide who holds the pen and what the exception path costs. A control nobody can get an exception from in a day is routed around, and the durable fix is separating public and private data into different stores.

Preventive is a different class from detective

Control	What it does	When you learn about the exposure
Account-level override refusing public grants	the grant never takes effect	never — there was nothing to learn
Scanner or configuration alert	reports a store that is already open	after it has been open for some window
Policy review before merge	catches what the reviewer notices	before, when it works; silently not at all when it does not

The distinction is worth being precise about in an interview, because the two are routinely confused. An alert never prevented anything. It shortens exposure, which is valuable, but the store was public for as long as the detection loop took. The override removes the outcome rather than the delay.

Where it sits and who holds it

The point of putting it at account level is that it is not editable by the team that owns the store. A store's policy is normally written by whoever runs the workload; the override is held by whoever owns the account or the grouping above it. So the two answers to "can this store be public" come from two different owners, and the more restrictive one wins. Platforms differ in the details — some refuse the write outright, some accept the rule and ignore it at request time, and some offer both a warning mode and an enforcing mode — but the model is the same: a decision above the resource that no local administrator can grant past.

What it stops, and what it very much does not

It is a narrow instrument aimed at one failure mode. It stops:

a store policy naming an unrestricted caller;
a per-object grant to an unrestricted caller, which is the variant a store-level policy review misses.

It does not stop:

an over-broad grant to a named external account, which is not a public grant at all and can be just as much of an exposure;
an over-broad identity permission letting any internal caller read the receipts;
a signed time-limited link already issued, which is a legitimate delegation of an existing authority and keeps working until it expires;
the workload itself copying objects somewhere with a looser policy, or serving them onward from its own endpoint.

Treating the override as "we are now safe" is the failure mode to avoid: it closes one specific, extremely common hole completely, and leaves the rest of the access model exactly where it was.

The cost you are accepting

Some objects genuinely should be public — a website's static assets, a public data set, a logo served to an unauthenticated page. Under a blanket override those cases need a route:

Separate the stores. Public assets live in stores whose whole purpose is public, and private user data never shares a store with them. This is the change that makes the override cheap to live with.
Carve the exception at the boundary you can supervise — an account, or a grouping of accounts, whose stores are allowed to be public — rather than poking a hole per store.
Serve public content through an edge tier in front of a private store where the platform supports it, so the store itself never needs a public grant.

The second cost is process: somebody must own the exception path and answer requests for it quickly, or teams route around the control in ways that are worse than the control.

Rolling it out without breaking production

Inventory first. Find every existing public grant, including per-object ones, before enforcing anything — otherwise you take down a working page.
Warn before you enforce, where the platform offers a reporting mode, and give owners a deadline.
Enforce at the highest boundary that is honest, so a new account created next quarter inherits it rather than being remembered.
Keep the detective control anyway. An override plus a scanner is not redundant: the scanner now checks that the override is actually in force everywhere you believe it is, which is a different question from whether a store is public.

After a store of user receipts turns out to be world-readable, the instruction from leadership is usually some version of "make this impossible, not merely reviewed". On every large platform the mechanism that answers that is an **account-level override**: a setting above the individual stores which refuses grants to unrestricted callers regardless of what any store's own policy says. ## Preventive is a different class from detective | Control | What it does | When you learn about the exposure | |---|---|---| | Account-level override refusing public grants | the grant never takes effect | never — there was nothing to learn | | Scanner or configuration alert | reports a store that is already open | after it has been open for some window | | Policy review before merge | catches what the reviewer notices | before, when it works; silently not at all when it does not | The distinction is worth being precise about in an interview, because the two are routinely confused. **An alert never prevented anything.** It shortens exposure, which is valuable, but the store was public for as long as the detection loop took. The override removes the outcome rather than the delay. ## Where it sits and who holds it The point of putting it at account level is that it is **not editable by the team that owns the store**. A store's policy is normally written by whoever runs the workload; the override is held by whoever owns the account or the grouping above it. So the two answers to "can this store be public" come from two different owners, and the more restrictive one wins. Platforms differ in the details — some refuse the write outright, some accept the rule and ignore it at request time, and some offer both a warning mode and an enforcing mode — but the model is the same: a decision above the resource that no local administrator can grant past. ## What it stops, and what it very much does not It is a narrow instrument aimed at one failure mode. It stops: - a store policy naming an unrestricted caller; - a per-object grant to an unrestricted caller, which is the variant a store-level policy review misses. It does **not** stop: - an over-broad grant to a **named** external account, which is not a public grant at all and can be just as much of an exposure; - an over-broad identity permission letting any internal caller read the receipts; - a **signed time-limited link** already issued, which is a legitimate delegation of an existing authority and keeps working until it expires; - the workload itself copying objects somewhere with a looser policy, or serving them onward from its own endpoint. Treating the override as "we are now safe" is the failure mode to avoid: it closes one specific, extremely common hole completely, and leaves the rest of the access model exactly where it was. ## The cost you are accepting Some objects genuinely should be public — a website's static assets, a public data set, a logo served to an unauthenticated page. Under a blanket override those cases need a route: 1. **Separate the stores.** Public assets live in stores whose whole purpose is public, and private user data never shares a store with them. This is the change that makes the override cheap to live with. 2. **Carve the exception at the boundary you can supervise** — an account, or a grouping of accounts, whose stores are allowed to be public — rather than poking a hole per store. 3. **Serve public content through an edge tier** in front of a private store where the platform supports it, so the store itself never needs a public grant. The second cost is process: somebody must own the exception path and answer requests for it quickly, or teams route around the control in ways that are worse than the control. ## Rolling it out without breaking production 1. **Inventory first.** Find every existing public grant, including per-object ones, before enforcing anything — otherwise you take down a working page. 2. **Warn before you enforce**, where the platform offers a reporting mode, and give owners a deadline. 3. **Enforce at the highest boundary that is honest**, so a new account created next quarter inherits it rather than being remembered. 4. **Keep the detective control anyway.** An override plus a scanner is not redundant: the scanner now checks that the override is actually in force everywhere you believe it is, which is a different question from whether a store is public.

A scanner already alerts within minutes of a store going public. Why add the override?
Because minutes of world-readable user documents is still an exposure, and the alert only shortens it. A preventive control removes the outcome rather than the delay. Keep the scanner too — once the override exists, its useful job changes to verifying that the override is in force everywhere you think it is.
The override is on, and the receipts are still being read by an external party. What are the candidate explanations?
Grants it does not target: a store-side allow naming a specific external account, an over-broad internal identity permission being used by a compromised caller, a signed link still inside its lifetime, or your own service serving the bytes onward. The override forbids grants to anyone in particular, not every path to the data.
Where should the exception for genuinely public assets live?
In a separate store, ideally in an account whose purpose is public content, rather than as a hole punched in the override for a store that also holds private data. Mixing exposure classes in one store is what makes a blanket control feel expensive and what produced the original incident.

saying these in an interview costs you the question

Calls an alert on public stores a preventive control
Believes the override also revokes links already signed
Leaves the override editable by the team owning the store
Enforces it without inventorying existing public grants
Assumes it blocks an over-broad grant to a named account
Drops configuration scanning once the override is enabled

Your team must make a public grant on any store impossible rather than merely reviewed — what does an account-level override give you?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Preventive is a different class from detective

Where it sits and who holds it

What it stops, and what it very much does not

The cost you are accepting

Rolling it out without breaking production

▾common follow-ups3 questions

▾red flags6 flags

Preventive is a different class from detective

Where it sits and who holds it

What it stops, and what it very much does not

The cost you are accepting

Rolling it out without breaking production

answer

go deeper