# 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.