An API request is made by an IAM role in an account that is part of an AWS Organization, against a resource that has its own resource-based policy. Walk through how AWS decides whether to allow the request when identity policies, that resource policy, an SCP, a permissions boundary and a session policy all apply.

middlemust knowfreq 68%

answer

assemble everything, then combine
deny short-circuits the whole thing
three of them can only subtract
two of them actually grant
in-account union, cross-account both sides

basics

~20 s

AWS gathers every applicable policy, then denies if any of them contains a matching explicit Deny. Otherwise the request must survive each guardrail that applies — SCP, permissions boundary, session policy — and be allowed by an identity-based or resource-based policy; anything else is an implicit deny.

solid answer

~40 s

AWS collects all policies in scope and computes one decision, not a sequence of independent checks. First, a matching explicit Deny in any of them ends it immediately. If there is none, the request must be permitted by every guardrail that applies: the service control policy on the account's Organizations path, the principal's permissions boundary, and any session policy passed at AssumeRole time. Those three can only restrict — none of them ever grants anything. Then there must be an actual grant: an Allow in the principal's identity-based policies, or, for a same-account request, an Allow in the resource-based policy. If a grant is missing at that last step, or any guardrail fails to permit the action, the answer is an implicit deny. The practical summary is deny wins, guardrails intersect, grants union.

AWS collects all policies in scope and computes one decision, not a sequence of independent checks. First, a matching explicit `Deny` in **any** of them ends it immediately. If there is none, the request must be permitted by every guardrail that applies: the service control policy on the account's Organizations path, the principal's permissions boundary, and any session policy passed at `AssumeRole` time. Those three can only restrict — none of them ever grants anything. Then there must be an actual grant: an `Allow` in the principal's identity-based policies, or, for a same-account request, an `Allow` in the resource-based policy. If a grant is missing at that last step, or any guardrail fails to permit the action, the answer is an implicit deny. The practical summary is *deny wins, guardrails intersect, grants union*.

go deeper

for a junior

Focus on the two ends of the model: nothing is permitted until some policy allows it, and one Deny anywhere is final. Being able to name identity-based and resource-based policies as the two things that grant is enough here.

for a middle

You are expected to list all five document types and state the combination rules correctly, especially that SCPs, boundaries and session policies restrict without ever granting. Expect to be asked to trace a concrete request.

for a senior

Use the model diagnostically. Given an AccessDenied, narrow to which layer said no, explain why cross-account needs both sides, and flag service-specific behaviour such as KMS key policies before someone loses an afternoon to it.

for a principal

Decide where each control belongs across the organization: what is enforced by SCP versus boundary versus session policy, who owns each layer, and how you keep the combined effective permissions reviewable rather than an emergent property nobody can predict.

One decision, not a pipeline

It is tempting to picture IAM walking a chain and stopping at the first hit. The mental model that actually predicts behaviour is different: AWS assembles every policy that applies to this request, evaluates all of them, and then combines the results with fixed rules. Nothing depends on ordering, attachment time, or which policy is "more specific".

The policy types in scope

For a role in an organization member account calling a service that supports resource policies, up to five kinds of document apply:

Identity-based policies — managed and inline policies on the role. These grant.
Resource-based policy — an S3 bucket policy, an SQS queue policy, a Lambda function policy, a KMS key policy. These grant, and they name a Principal.
Service control policy (SCP) — attached in AWS Organizations to the account or an OU above it. Filters only.
Permissions boundary — a managed policy attached to the role as its ceiling. Filters only.
Session policy — a policy document passed inline when the role was assumed. Filters only.

The combination rules

1. Any explicit Deny wins. A matching Effect: Deny in any of the five ends the evaluation with a deny. This is why a central guardrail is trustworthy: no downstream Allow can unwind it.

2. Filters intersect. SCP, boundary and session policy each define a set of actions that are permitted to be granted. The request must fall inside all of them. Because they never grant, an Allow s3:* inside an SCP does not give anyone S3 access — it only means the SCP is not the thing standing in the way. This is the single most common misunderstanding in the whole model.

3. Grants union. The actual permission must come from an identity-based policy or a resource-based policy. Within one account these are a union: either side allowing is enough. A user with no S3 policy at all can read a bucket in the same account if the bucket policy names them, and a role with s3:GetObject in its identity policy can read a same-account bucket whose policy is silent.

4. Cross-account is an intersection instead. When the principal and the resource are in different accounts, both sides must allow — the calling account's identity policy and the resource's own policy. Neither account can unilaterally hand out access to the other's resources, which is exactly the property you want.

5. No grant means implicit deny. Surviving all the filters is not permission. If nothing granted the action, the answer is still no.

A worked example

A role arn:aws:iam::111122223333:role/report-writer calls s3:PutObject on a bucket in the same account.

Its identity policy allows s3:PutObject on arn:aws:s3:::reports/* — a grant exists.
The bucket policy is silent about this role — irrelevant in the same account, since one grant suffices.
The SCP on the OU allows all actions except in unapproved regions, and the call is in an approved region — passes.
The permissions boundary allows s3:* and logs:* — passes.
The role was assumed with a session policy limiting it to s3:GetObject — fails. The intersection no longer contains PutObject, so the request is denied even though the identity policy is fine.

Change one variable — the object key is arn:aws:s3:::reports/2026/q1.csv but the identity policy says arn:aws:s3:::reports without /* — and you get the same AccessDenied from a completely different cause. This is why the debugging question is always which of the five said no.

Notable service-specific behaviour

Some services layer their own authorization on top of IAM. AWS KMS is the classic one: the key policy is authoritative, and an IAM policy alone does not grant access to a key unless the key policy delegates to IAM for that account. Treat "the resource policy is optional" as a general rule with real exceptions, and check the service's own documentation when a call fails despite a correct-looking identity policy.

What to say in an interview

Compress it to four beats: explicit Deny anywhere wins; SCP, boundary and session policy restrict but never grant; identity and resource policies grant and are a union in-account, an intersection across accounts; no grant means implicit deny. Then show you can apply it by naming which layer you would inspect first for a given symptom.

## One decision, not a pipeline It is tempting to picture IAM walking a chain and stopping at the first hit. The mental model that actually predicts behaviour is different: AWS assembles every policy that applies to this request, evaluates all of them, and then combines the results with fixed rules. Nothing depends on ordering, attachment time, or which policy is "more specific". ## The policy types in scope For a role in an organization member account calling a service that supports resource policies, up to five kinds of document apply: - **Identity-based policies** — managed and inline policies on the role. These grant. - **Resource-based policy** — an S3 bucket policy, an SQS queue policy, a Lambda function policy, a KMS key policy. These grant, and they name a `Principal`. - **Service control policy (SCP)** — attached in AWS Organizations to the account or an OU above it. Filters only. - **Permissions boundary** — a managed policy attached to the role as its ceiling. Filters only. - **Session policy** — a policy document passed inline when the role was assumed. Filters only. ## The combination rules **1. Any explicit Deny wins.** A matching `Effect: Deny` in any of the five ends the evaluation with a deny. This is why a central guardrail is trustworthy: no downstream Allow can unwind it. **2. Filters intersect.** SCP, boundary and session policy each define a set of actions that are *permitted to be granted*. The request must fall inside all of them. Because they never grant, an `Allow s3:*` inside an SCP does not give anyone S3 access — it only means the SCP is not the thing standing in the way. This is the single most common misunderstanding in the whole model. **3. Grants union.** The actual permission must come from an identity-based policy or a resource-based policy. Within one account these are a union: either side allowing is enough. A user with no S3 policy at all can read a bucket in the same account if the bucket policy names them, and a role with `s3:GetObject` in its identity policy can read a same-account bucket whose policy is silent. **4. Cross-account is an intersection instead.** When the principal and the resource are in different accounts, both sides must allow — the calling account's identity policy and the resource's own policy. Neither account can unilaterally hand out access to the other's resources, which is exactly the property you want. **5. No grant means implicit deny.** Surviving all the filters is not permission. If nothing granted the action, the answer is still no. ## A worked example A role `arn:aws:iam::111122223333:role/report-writer` calls `s3:PutObject` on a bucket in the same account. - Its identity policy allows `s3:PutObject` on `arn:aws:s3:::reports/*` — a grant exists. - The bucket policy is silent about this role — irrelevant in the same account, since one grant suffices. - The SCP on the OU allows all actions except in unapproved regions, and the call is in an approved region — passes. - The permissions boundary allows `s3:*` and `logs:*` — passes. - The role was assumed with a session policy limiting it to `s3:GetObject` — **fails**. The intersection no longer contains `PutObject`, so the request is denied even though the identity policy is fine. Change one variable — the object key is `arn:aws:s3:::reports/2026/q1.csv` but the identity policy says `arn:aws:s3:::reports` without `/*` — and you get the same `AccessDenied` from a completely different cause. This is why the debugging question is always *which* of the five said no. ## Notable service-specific behaviour Some services layer their own authorization on top of IAM. AWS KMS is the classic one: the key policy is authoritative, and an IAM policy alone does not grant access to a key unless the key policy delegates to IAM for that account. Treat "the resource policy is optional" as a general rule with real exceptions, and check the service's own documentation when a call fails despite a correct-looking identity policy. ## What to say in an interview Compress it to four beats: *explicit Deny anywhere wins; SCP, boundary and session policy restrict but never grant; identity and resource policies grant and are a union in-account, an intersection across accounts; no grant means implicit deny.* Then show you can apply it by naming which layer you would inspect first for a given symptom.

Why can an SCP that allows an action still leave the principal with no access?
Because SCPs never grant. An SCP defines the maximum set of actions principals in that account may be given; permission still has to come from an identity-based or resource-based policy. An account whose SCP allows `s3:*` and whose roles have no S3 policy has exactly zero S3 access.
If the identity policy and the resource policy disagree within one account, which wins?
Neither overrides the other on Allow — they union, so a single Allow on either side is enough. On Deny the asymmetry returns: a Deny in either document kills the request. So the rule is not 'resource policy wins', it is 'Allows add up, Denies are absolute', applied to both documents.
Where does a session policy come from, and why is it easy to forget?
It is passed inline at assume time — for example the `--policy` or `--policy-arns` argument of `aws sts assume-role` — so it exists only for that session and appears in no console page listing the role's attached policies. Federation brokers and CI tooling often add one silently, which is why a role that works interactively can fail from a pipeline.
Does the evaluation change if the caller is an IAM user rather than a role session?
The combination rules are identical. What changes is which documents exist: a user typically has no session policy unless federated via `GetFederationToken`, and it may have a permissions boundary just as a role can. The presence or absence of a filter changes the intersection, never the algorithm.

saying these in an interview costs you the question

Says an SCP with Allow grants the permission
Describes evaluation as first-match-wins ordering
Thinks the resource policy overrides the identity policy
Believes passing every guardrail is itself permission
Forgets session policies exist for assumed-role calls

§ answer

basics

solid answer

§ go deeper

▾level notes4 levels

▾deep dive~4 min

One decision, not a pipeline

The policy types in scope

The combination rules

A worked example

Notable service-specific behaviour

What to say in an interview

▾common follow-ups4 questions

▾red flags5 flags

§ context

▾related questions11 questions

▾related topics4 topics

One decision, not a pipeline

The policy types in scope

The combination rules

A worked example

Notable service-specific behaviour

What to say in an interview

answer

go deeper

context