A grant can sit on the calling identity or on the resource being called — which side has to allow the call?
answer
- same decision, written from both ends
- one side cannot name a principal
- the resource side enumerates its callers
- inside an account, either side may grant
- across accounts, both owners must agree
basics
~20 sAn identity-attached grant travels with the caller and cannot name a principal, because the principal is whatever it is attached to. A resource-attached grant lives with the thing being called and names the principal explicitly. Inside one account either side may allow; across an account boundary both normally must.
solid answer
~40 sThe two sides are the same decision written from opposite ends. An **identity-attached** permission is stored against a principal and says what that principal may do; it has no principal element, because the attachment already answers that. A **resource-attached** permission is stored with the resource and must name the principal it applies to — which is exactly what lets a resource's owner grant access to an identity it does not administer. Within one account, platforms that have both sides typically treat an allow from either as sufficient. Across an account boundary the two owners are different people, so both sides normally have to allow: the resource owner names the outside principal, and the caller's own account permits the action. Neither owner can grant on the other's behalf, and that is deliberate.
code
json · 10 lines{
"attachedTo": "identity:nightly-reconciliation",
"rules": [
{
"effect": "allow",
"action": "object.write",
"resource": "store/reconciliation-output/*"
}
]
}go deeper
Remember that a permission can live on the caller or on the thing being called, and that only the one living on the resource names who may use it.
Explain the combining rule properly: inside one account an allow from either side is usually enough, while a call across an account boundary needs both owners to allow, and nothing anywhere beats an explicit deny.
Demonstrate the diagnosis — identify which side is missing before editing anything, and resist the reflex to widen the side you control, which can never supply the other owner's grant.
Decide where cross-boundary grants are authoritative for the whole estate and get it written down, because a mixed convention leaves nobody able to answer who can currently reach a shared resource.
## Two ends of one decision A platform decides a call by gathering every permission that could apply to it. Those permissions live in two places, and the difference is not cosmetic. An **identity-attached permission** is stored against a principal — a person, a group or a workload identity. It reads "this principal may perform these actions on these resources". It carries no principal element at all, because attaching it to the identity is how the principal is named. A **resource-attached permission** is stored with the resource — an object store, a queue, a key, a managed database. It reads "these principals may perform these actions on me". It *must* carry a principal element, and that element is the whole point of the mechanism. | | Identity-attached | Resource-attached | |---|---|---| | Stored with | The principal | The resource | | Names a principal? | No — attachment names it | Yes, explicitly | | Written by | The team that owns the identity | The team that owns the resource | | Answers | "What may this caller reach?" | "Who can reach this thing?" | | Works across an account boundary | Only together with the other side | Only together with the other side | ## Why the resource side exists at all If identity-attached permissions were the only kind, a team could grant itself access to anything simply by writing a document in its own account. The resource side is what stops that: a permission that lets an outside principal in has to be written by whoever owns the resource. It is the mechanism by which an owner controls its own exposure, and it is why the question "who can reach this?" is answerable at all — the resource-attached document enumerates its callers, whereas answering the same question from the identity side means inspecting every principal in the estate. ## How the two combine This is the part interviewers actually probe, and it has two cases that behave differently. 1. **Inside one account.** Both sides are administered by the same owner, so the platform can safely treat the grants as a union: an allow from either side is normally enough, and a resource with no permission of its own is still reachable by a principal whose identity-attached permission allows it. Some platforms do not model a separate resource-attached layer at all and express everything as grants on nodes of a resource hierarchy, inherited downward — where that is the design, the "which side" question collapses, because there is only one side. 2. **Across an account boundary.** The two owners are different parties. The platform will not let one account's administrator hand out access to another account's resources, and it will not let a resource owner quietly enlarge what a foreign principal's own account has authorised it to do. So both sides must allow: the resource names the foreign principal, and the principal's own account permits the action. Remove either and the call fails. On top of both cases sits the default: with no matching allow anywhere, the answer is no. And an **explicit deny**, where the platform offers one, outranks every allow on either side. ## The diagnostic value of knowing which side you are looking at When a cross-boundary call is denied, engineers reflexively widen the side they own, because it is the side they can edit. Widening an identity-attached permission all the way to every action cannot fix a missing resource-side grant, and widening a resource-attached one cannot fix a caller whose own account never permitted the action. Knowing which document you are missing turns a day of escalating permissions into one request to the right team — and it stops the far worse outcome, where someone eventually "fixes" it by handing out a grant far broader than the one that was actually needed. ## What to say in an interview Name the two sides, say that only the resource side can name a principal, and give the combining rule with its two cases. If you are asked for the single sentence: *an identity-attached grant says what a caller may reach, a resource-attached grant says who may reach a thing, and across an account boundary you need both because two different owners have to agree.*
- Why can't the resource owner simply grant access and be done with it, without the caller's account doing anything?Because then one account's administrator would decide what another account's principals may do, and a compromised or careless owner could pull foreign identities into work they were never authorised for. Requiring the caller's own account to permit the action keeps each owner in control of its own identities.
- If a platform has no resource-attached layer at all, how does cross-team access work?Grants are written on nodes of the resource hierarchy and inherited downward, so the grant still sits with the thing being called — it just is not a separate document type. The outside principal is named on that node. The mechanism differs; the property that the resource's owner must name the caller does not.
- Which side should you read first when asked 'who can currently write to this store?'The resource side, because it enumerates its callers in one place. The identity side can only answer the mirror-image question — what one caller may reach — so answering from it means walking every principal in the estate and hoping none was missed.
Reaching a desk inside another company's office needs two permissions that neither party can issue for the other: the building lobby has to admit you, and the tenant has to unlock their own door. On your own company's floor, one of the two is usually enough.
saying these in an interview costs you the question
- Says an identity-attached allow is sufficient anywhere, including another account
- Thinks a resource-attached permission overrides the caller's own account
- Cannot say which of the two carries a principal element
- Believes a resource with no permission of its own is unreachable
- Fixes a cross-account denial by widening the side they happen to own