skip to content

Should cross-team access to a shared resource be granted on the resource itself or on each consumer's identity?

level: principalimportance: nice to knowfreq 30%

answer

  1. both documents exist regardless
  2. choosing which side is authoritative
  3. one side enumerates, the other aggregates
  4. mirror questions, never both at once
  5. no convention is the real failure

basics

~20 s

Crossing an account boundary needs both sides anyway, so the real decision is where the authoritative record lives. The resource side is the only one that can enumerate its consumers, which is why shared resources are usually made authoritative there.

solid answer

~40 s

This is a standard, not a per-request choice, and it is worth setting deliberately. Grants kept on the **resource** answer the question incident response and audit actually ask — *who can reach this right now?* — in one place, and they leave exposure under the control of the team that owns the data. Grants kept on the **identity** answer the mirror question, *what may this team reach?*, keep a consumer's access inside its own review, and stop the resource owner becoming a bottleneck for every new consumer. Across an account boundary both documents must exist regardless, so what you are really choosing is which side is authoritative and reviewed. The failure to avoid is no convention at all, where neither side is complete and nobody can answer either question.

go deeper

for a junior

Know that access to a shared resource can be recorded on the resource or on the consumer, and that the two answer different questions.

for a middle

Be able to explain why enumerating the consumers of a resource is easy from one side and impractical from the other, and that a cross-boundary call needs a document on both.

for a senior

Argue the operational consequence: which side you would read during an incident, and how removal of a departing consumer actually happens under each convention.

for a principal

Set the standard and make it testable — name which question must be answerable quickly, who reviews which side, and how you stop the coordination cost being relieved by over-broad grants.

## What is actually being decided Every cross-boundary grant needs a document on both sides: the resource's owner names the outside principal, and the consumer's own account permits the action. So a house rule cannot remove a document. What it decides is **which side is authoritative** — which one is reviewed, which one a change request goes to, and which one you trust when the two disagree. That is a real and consequential standard, and most estates arrive at it by accident. ## The case for making the resource side authoritative - **It is the only side that can enumerate consumers.** "Who can currently write to this store?" is answerable by reading one document. Answered from the identity side, the same question means walking every principal in the estate and trusting that none was missed — which is not a review anyone completes honestly. - **Exposure stays with the owner of the data.** The team accountable for the data is the team that has to say yes, which is usually the accountability you want when the data is sensitive. - **Removal is one edit.** Ending a consumer's access does not depend on another team editing something in their own account. - **It matches how incidents are run.** During an investigation the question is always about the resource, and the answer needs to be immediate. ## The case for making the identity side authoritative - **It scales with consumers that use many resources.** A team touching thirty resources has one document to review rather than thirty documents to be named in. - **It lands in the right review.** A consumer's total access sits in one place and is reviewed alongside the rest of that team's permissions, joiner-mover-leaver included. - **It removes a bottleneck.** If every new consumer needs an edit by the resource owner, the owner becomes a queue, and queues get relieved by over-broad grants that name whole accounts instead of principals. - **It survives the resource being recreated**, which is a genuine operational nuisance when the authoritative grant lives on an object that infrastructure tooling replaces. ## A standard that works in practice 1. **Anything shared across a boundary is authoritative on the resource side.** The resource's document is the record of who may reach it, and it names principals, never whole accounts. 2. **Anything inside one team's own account is authoritative on the identity side.** One owner controls both ends, the union rule already makes a single grant sufficient, and a second document adds no control. 3. **The consumer's own side stays minimal and mirrors the request** — the actions it actually needs, nothing kept "in case". 4. **Write the rule down and make it checkable.** A convention nobody can test is not a convention. The cheap test is a periodic read of every shared resource's document, asking whether each named principal still exists and still needs it. ## The trade-off you are accepting either way Making the resource side authoritative buys the answer to *who can reach this* and pays for it in coordination — every new consumer is a request to another team. Making the identity side authoritative buys autonomy and pays for it in the one question you can no longer answer quickly. There is no option that gives both, because the two questions are mirror images and each side of the model answers exactly one of them. What is genuinely not defensible is the default state: some grants on each side, no rule, and both questions unanswerable. That estate is the one where a shared store is discovered to be reachable by a principal nobody recognises, and the investigation cannot even establish when that became true. ## What a lead is being assessed on Not a preference — either standard is defensible — but whether you framed it as *which question must be answerable quickly, and by whom*, whether you noticed that both documents exist regardless, and whether you proposed something reviewable rather than a principle. Naming the bottleneck the resource-side rule creates, and how you would keep it from being relieved by an account-wide grant, is the detail that shows it has been operated and not just specified.

  • What breaks first in an estate with no convention at all?
    The question 'who can currently reach this?'. Grants accumulate on both sides, neither is complete, and the honest answer becomes a survey rather than a lookup. The discovery usually happens during an incident, which is the worst moment to learn that the record is not authoritative anywhere.
  • How do you keep a resource-side standard from becoming a bottleneck?
    Make the request cheap and specific: a template naming one principal and the actions it needs, a short path to the owner, and an expiry so stale consumers fall off by default. Bottlenecks are relieved by broad grants precisely when the narrow request is slow to obtain.
  • Does the same reasoning apply inside a single account?
    Much less. One owner controls both ends and a single allow from either side is normally sufficient, so a second document adds paperwork rather than control. The resource-side discipline earns its cost where two different owners must agree and where the consumer list is the thing you need to read.

saying these in an interview costs you the question

  • Argues one side is correct without naming which question it answers
  • Forgets that a cross-boundary call needs both documents anyway
  • Proposes a principle with no periodic check behind it
  • Relieves the resource owner's queue by granting to a whole account
  • Cannot say how they would answer who can currently reach a shared resource