AccessDenied: systematic troubleshooting, in order

AccessDenied troubleshooting, in order

The rule

An explicit deny anywhere in the evaluation chain beats any number of allows. Work the layers in order instead of guessing.

The checklist

1. Read the error exactly. It names the action, the resource, and often the context key. Match all three.
2. Identity policy: does the caller's policy allow this action on this resource? Check for typos in ARNs and missing wildcards.
3. Resource policy: for S3, KMS, SQS and friends, the resource side must also allow (or at least not deny) the caller.
4. Explicit deny scan: search every attached policy for an explicit deny on the action. One deny anywhere ends the evaluation.
5. Organizations SCPs: the account may be restricted from above. SCPs do not grant, they only filter, so a missing allow at the SCP layer denies.
6. Permissions boundaries and session policies: these filter too. Federated and assumed roles often carry a session policy the agent forgot about.
7. KMS key policy: if the resource is encrypted with a customer managed key, the key policy must grant use. This is the most-missed layer.

Tools

Use the IAM policy simulator or IAM Access Analyzer policy checks to test the exact call before changing policies. Change one layer at a time.

Distills the IAM access-denied troubleshooting flow: evaluation order across identity policies, resource policies, SCPs, permissions boundaries, and session policies. Verified against the live IAM troubleshooting guide. https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_access-denied.html