AWS 'An error occurred (AccessDeniedException)' or 'is not authorized to perform: ... because no identity-based policy allows' - how do I troubleshoot it with the IAM policy simulator?

Cause: AWS evaluates every request against all applicable policies. A request is denied implicitly when nothing allows it, or explicitly when any applicable policy has a matching Deny. Besides the caller's identity-based policies, the result can be shaped by resource-based policies, permissions boundaries, session policies, AWS Organizations service control policies (SCPs), and VPC endpoint policies. Some services also use their own condition keys, so an Allow can exist but its Condition may not match. Fix: 1. Read the whole message. It usually names the principal, the action, and the resource. Newer messages also say whether the denial was implicit or explicit and which policy type caused it. Fix that layer rather than adding broad permissions. 2. Confirm the identity: aws sts get-caller-identity. Wrong profile, an assumed role with a session policy, or role chaining are frequent surprises. 3. Open the IAM policy simulator. In Principal mode test the actual user or role; in Custom mode test a draft policy. Select the service, action and resource ARN, and supply values for any condition keys (for example aws:RequestedRegion or aws:MultiFactorAuthPresent) that the policies reference, because a condition that is not satisfied results in a denial. The simulator shows which statement allowed or denied the action. It can test permissions boundaries and, for accounts in an organization, SCPs (without showing the matched SCP statements). 4. Remember what the simulator does not cover: it makes no real request, does not support resource control policies, and can differ from live behavior for VPC endpoint policies, role chaining or multiple resource-based policies. Always retest in the live environment. 5. Check that the action supports resource-level permissions. If it does not, the statement's Resource must be "*", otherwise the policy grants nothing. Use the IAM policy validation / Access Analyzer checks to catch such mistakes. 6. Grant the least privilege needed: add the missing action on the specific resource, or remove the conflicting Deny or adjust the condition. Avoid replacing the policy with full administrator access. 7. Use CloudTrail event history to see the denied calls and decide which permissions to add or remove. Verify: re-run the simulator and then the real call; the simulator shows allowed and the command succeeds, with no new AccessDenied events for that principal in CloudTrail. Sources: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_policies.html https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshoot-403-errors.html