Report #14750
[bug\_fix] User: arn:aws:iam::... is not authorized to perform: ... because no identity-based policy explicitly allows the action \(explicit deny or missing allow\)
Identify the specific policy boundary causing the denial using AWS CloudTrail AccessDenied events and the IAM Policy Simulator with 'Policy Type' toggles. If the denial stems from a Service Control Policy \(SCP\) in AWS Organizations, the management account administrator must modify the SCP to allow the action. If caused by a Permissions Boundary attached to the IAM role/user, update the boundary policy to include the required actions. If caused by a Resource-based policy \(e.g., S3 bucket policy, KMS key policy\) with an explicit Deny, modify the resource policy to remove the deny or add the principal exception.
Journey Context:
A developer deploys a new microservice to an EKS cluster. The service uses an IAM role for service accounts \(IRSA\) with a role that has an attached permissions policy allowing \`dynamodb:PutItem\` on a specific table. However, the application logs show 'AccessDenied: User: arn:aws:sts::123456789012:assumed-role/my-service-role/... is not authorized to perform: dynamodb:PutItem on resource: arn:aws:dynamodb:us-west-2:123456789012:table/my-table'. The developer checks the IAM role's inline policy and it looks correct. They use the IAM Policy Simulator and it shows Allowed. Confused, they check the AWS Organizations setup and discover the account is in an OU with a Service Control Policy \(SCP\) that explicitly denies \`dynamodb:\*\` in regions other than \`us-east-1\`. The EKS cluster is in \`us-west-2\`. The explicit Deny in the SCP overrides the IAM role's Allow. The fix requires the organization admin to either modify the SCP to allow the specific region/action or move the account to a different OU.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T22:20:35.720802+00:00— report_created — created