A principal with the AWS managed AdministratorAccess policy attached still gets AccessDenied on an action. Which parts of AWS IAM evaluation can cause that, and why does attaching another Allow never fix it?

seniorshould knowfreq 52%

answer

breadth is not the binding constraint
intersections shrink, unions grow
three ceilings and one veto
the session may be narrower than the role
the blocking policy may be another team's

basics

~20 s

Something is restricting rather than failing to grant: an explicit Deny in any applicable policy, or a guardrail that the action falls outside of — a service control policy, a permissions boundary, or a session policy. All of these subtract from what identity policies grant, so more Allows change nothing.

solid answer

~50 s

AdministratorAccess is only a very wide Allow, and IAM's decision is the intersection of everything that restricts, not the maximum of everything that grants. Four things produce this symptom: a matching explicit Deny in any applicable policy — including a resource-based one such as a bucket or KMS key policy; a service control policy on the account or an OU above it that does not permit the action; a permissions boundary on the principal that does not include it; or a session policy passed when the role was assumed. Adding another Allow cannot help, because every one of these either wins outright over Allows or defines a ceiling that Allows can never exceed. The fix is always on the subtractive side: find which layer said no, then change that document — often in another account, owned by another team. Start with the denial message, which usually names the policy type responsible.

AdministratorAccess is only a very wide `Allow`, and IAM's decision is the **intersection** of everything that restricts, not the maximum of everything that grants. Four things produce this symptom: a matching explicit `Deny` in any applicable policy — including a resource-based one such as a bucket or KMS key policy; a service control policy on the account or an OU above it that does not permit the action; a permissions boundary on the principal that does not include it; or a session policy passed when the role was assumed. Adding another Allow cannot help, because every one of these either wins outright over Allows or defines a ceiling that Allows can never exceed. The fix is always on the subtractive side: find which layer said no, then change *that* document — often in another account, owned by another team. Start with the denial message, which usually names the policy type responsible.

go deeper

for a junior

Take away the headline: a very broad Allow is not the same as unlimited access, because other policies can restrict or explicitly deny what your policy grants.

for a middle

Name the four sources — explicit Deny, SCP, permissions boundary, session policy — and explain that the first wins outright while the other three define ceilings that Allows cannot exceed.

for a senior

Show a diagnostic order rather than a list: read the denial message, confirm the caller, check for a session policy, read the resource policy, then walk the OU chain — and resist widening permissions as a fix.

for a principal

Own the tradeoff between control and velocity: how many guardrail layers an organization can support, who may author each, how exceptions are reviewed, and how teams see their effective ceiling instead of discovering it through failed deployments.

Why an administrator can be denied

The intuition that trips people up is that permissions accumulate. They do — but only the granting half of the model accumulates. IAM computes effective permissions roughly as:

(union of grants) ∩ SCP ∩ permissions boundary ∩ session policy, minus anything explicitly denied

AdministratorAccess maximizes the first term only. Every other term is a filter, and an intersection is bounded by its smallest member. So a principal can hold the broadest policy AWS publishes and still be unable to call ec2:RunInstances.

The four causes, and how to tell them apart

1. An explicit Deny. Any applicable policy containing a matching Effect: Deny ends the request. It may be in the principal's own inline policy, in a guardrail, or in a resource-based policy — a bucket policy denying requests without aws:SecureTransport, a KMS key policy denying a principal, an SQS queue policy scoped to one role. Denials from resource policies surprise administrators most, because nothing on the identity side looks wrong.

2. A service control policy. SCPs attach to accounts and organizational units and define the maximum permissions available in that account. An account under an OU whose SCP permits nothing outside two regions cannot act elsewhere, whatever its administrators write. Two details matter operationally: SCPs do not restrict the organization's management account, and they do not restrict service-linked roles — so testing a guardrail from the management account produces a false green.

3. A permissions boundary. A managed policy attached to a user or role as a ceiling. Effective permissions are the intersection of the identity policy and the boundary. This is what makes delegated administration safe: a team lead may create roles freely, provided every role carries the boundary. It is also easy to miss, because the console shows it separately from attached policies.

4. A session policy. Passed inline at assume time — for example aws sts assume-role --policy or --policy-arns — and scoped to that session only. It appears in no listing of the role's policies, so a role that works interactively can fail from a CI job or a federation broker that narrows the session. This is the hardest of the four to spot from the console.

Diagnosing it in order

Read the error. AWS AccessDenied messages commonly state the reason and the policy type — for instance that no identity-based policy allows the action, or that an explicit deny in a service control policy blocked it. That single line usually eliminates three of the four candidates.
Establish who you actually are. A shell you believe is your admin role may be an instance profile, a stale profile, or an assumed role two hops away. Confirm the caller before theorizing.
Look for a session policy. Check how the credentials were obtained — federation, a pipeline, a broker — before assuming the persistent policies are the problem.
Check the resource's own policy. For S3, KMS, SQS, SNS and Lambda, read the resource policy explicitly; do not infer it from the identity side.
Walk up the organization. SCPs on any OU between the root and the account apply, so the blocking statement may be several levels above the account you are in.

Why this design is a feature

Every one of these mechanisms exists so that a decision made centrally cannot be reversed locally. If an account admin could out-allow an SCP, the SCP would be advice rather than a control. The property that makes the guardrails useful is precisely the property that makes them frustrating to debug — so the operational answer is not to weaken them but to make them legible: keep guardrail policies in version control, document which OU carries which restriction, and give teams a way to see the effective ceiling rather than guessing at it.

The trap to avoid

The reflex when hitting this is to attach something broader, then something broader still, and finally to consider loosening the guardrail. All three are wrong. Identify the layer, take the change to whoever owns it, and treat a guardrail exception as a reviewed decision — because the next person to widen an SCP "temporarily" is how an organization loses the control it built.

## Why an administrator can be denied The intuition that trips people up is that permissions accumulate. They do — but only the granting half of the model accumulates. IAM computes effective permissions roughly as: > (union of grants) ∩ SCP ∩ permissions boundary ∩ session policy, minus anything explicitly denied `AdministratorAccess` maximizes the first term only. Every other term is a filter, and an intersection is bounded by its smallest member. So a principal can hold the broadest policy AWS publishes and still be unable to call `ec2:RunInstances`. ## The four causes, and how to tell them apart **1. An explicit Deny.** Any applicable policy containing a matching `Effect: Deny` ends the request. It may be in the principal's own inline policy, in a guardrail, or in a **resource-based** policy — a bucket policy denying requests without `aws:SecureTransport`, a KMS key policy denying a principal, an SQS queue policy scoped to one role. Denials from resource policies surprise administrators most, because nothing on the identity side looks wrong. **2. A service control policy.** SCPs attach to accounts and organizational units and define the maximum permissions available in that account. An account under an OU whose SCP permits nothing outside two regions cannot act elsewhere, whatever its administrators write. Two details matter operationally: SCPs do not restrict the organization's **management account**, and they do not restrict service-linked roles — so testing a guardrail from the management account produces a false green. **3. A permissions boundary.** A managed policy attached to a user or role as a ceiling. Effective permissions are the intersection of the identity policy and the boundary. This is what makes delegated administration safe: a team lead may create roles freely, provided every role carries the boundary. It is also easy to miss, because the console shows it separately from attached policies. **4. A session policy.** Passed inline at assume time — for example `aws sts assume-role --policy` or `--policy-arns` — and scoped to that session only. It appears in no listing of the role's policies, so a role that works interactively can fail from a CI job or a federation broker that narrows the session. This is the hardest of the four to spot from the console. ## Diagnosing it in order 1. **Read the error.** AWS `AccessDenied` messages commonly state the reason and the policy type — for instance that no identity-based policy allows the action, or that an explicit deny in a service control policy blocked it. That single line usually eliminates three of the four candidates. 2. **Establish who you actually are.** A shell you believe is your admin role may be an instance profile, a stale profile, or an assumed role two hops away. Confirm the caller before theorizing. 3. **Look for a session policy.** Check how the credentials were obtained — federation, a pipeline, a broker — before assuming the persistent policies are the problem. 4. **Check the resource's own policy.** For S3, KMS, SQS, SNS and Lambda, read the resource policy explicitly; do not infer it from the identity side. 5. **Walk up the organization.** SCPs on any OU between the root and the account apply, so the blocking statement may be several levels above the account you are in. ## Why this design is a feature Every one of these mechanisms exists so that a decision made centrally cannot be reversed locally. If an account admin could out-allow an SCP, the SCP would be advice rather than a control. The property that makes the guardrails useful is precisely the property that makes them frustrating to debug — so the operational answer is not to weaken them but to make them legible: keep guardrail policies in version control, document which OU carries which restriction, and give teams a way to see the effective ceiling rather than guessing at it. ## The trap to avoid The reflex when hitting this is to attach something broader, then something broader still, and finally to consider loosening the guardrail. All three are wrong. Identify the layer, take the change to whoever owns it, and treat a guardrail exception as a reviewed decision — because the next person to widen an SCP "temporarily" is how an organization loses the control it built.

Why does testing a new SCP from the organization's management account give a misleading result?
Because SCPs do not restrict principals in the management account. A guardrail that appears to have no effect there may be blocking every member account, so validate in a real member account — ideally a disposable sandbox under the same OU — before rolling it out.
How do you make guardrails less painful to debug without weakening them?
Make them legible. Keep SCPs and boundary policies in version control with reasons attached, publish which OU carries which restriction, standardize on a small number of named boundaries rather than bespoke ones, and give teams a documented exception path so the pressure valve is a review rather than a quiet widening.
A role works when you assume it manually but fails from the CI pipeline. Where do you look first?
At the session. Pipelines commonly obtain credentials through web-identity federation or a broker that passes a narrowing session policy or a different role entirely. Compare the caller identity from both paths and inspect how the credentials were requested before touching the role's attached policies.

saying these in an interview costs you the question

Attaching a broader policy to fix a guardrail denial
Assuming AdministratorAccess overrides every restriction
Ignoring resource-based policies as a denial source
Testing an SCP from the management account
Overlooking session policies passed at assume time

A principal with the AWS managed AdministratorAccess policy attached still gets AccessDenied on an action. Which parts of AWS IAM evaluation can cause that, and why does attaching another Allow never fix it?

§ answer

basics

solid answer

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Why an administrator can be denied

The four causes, and how to tell them apart

Diagnosing it in order

Why this design is a feature

The trap to avoid

▾common follow-ups3 questions

▾red flags5 flags

§ context

▾related questions6 questions

▾related topics4 topics

Why an administrator can be denied

The four causes, and how to tell them apart

Diagnosing it in order

Why this design is a feature

The trap to avoid

answer

go deeper

context