AWS "is not authorized to perform … because no identity-based policy allows": read the error, find the missing permission

1. Who is really calling?

aws sts get-caller-identity

Credentials come from many places — environment variables, ~/.aws/credentials profiles, an instance role, an SSO session — and they’re often not the ones you think. If the ARN isn’t what you expected, fix that first: AWS_PROFILE, a forgotten AWS_ACCESS_KEY_ID, the wrong role in the CI job.

2. No policy allows the action

Find the policies attached to the user or role (IAM console, or aws iam list-attached-role-policies --role-name app-prod and list-role-policies for inline ones) and look for a statement that allows exactly this action on exactly this resource. The common mistakes:

• The resource doesn’t match. For S3, objects are arn:aws:s3:::bucket/* and the bucket itself is arn:aws:s3:::bucket. s3:GetObject needs the first, s3:ListBucket the second:

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::acme-reports" },
    { "Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject"], "Resource": "arn:aws:s3:::acme-reports/*" }
  ]
}

• The action isn’t the one you think. One CLI command can call several API actions (aws s3 sync lists, reads and writes). The error names the action that failed — that’s the one to add.
• A condition doesn’t match — a required tag, a source VPC, MFA, a region.

The IAM Policy Simulator (in the IAM console) or aws iam simulate-principal-policy shows whether a given action on a given resource is allowed, and which statement decides.

3. An explicit Deny wins

A Deny anywhere beats every Allow. If the message mentions an explicit deny, adding more Allow statements changes nothing. Find the Deny:

• in the user’s / role’s own policies (often a “guardrail” policy);
• in a service control policy of your AWS Organization — only the organization’s admins can see and change those;
• in a permissions boundary attached to the role.

4. The resource has its own policy

Some resources have their own policy: S3 buckets, KMS keys, SQS queues, SNS topics, Secrets Manager secrets. Two classic cases:

• Another account. Cross-account access needs both sides: the caller’s policy and the resource’s policy must allow it.
• Encrypted with KMS. Reading an S3 object encrypted with a customer-managed KMS key also needs kms:Decrypt on that key — in the caller’s policy and allowed by the key policy. The error may still name s3:GetObject; look for KMS in CloudTrail.

5. When the message gives no reason

Some services still answer only AccessDenied or AccessDeniedException. Then CloudTrail has the details: search the event history for that event name and errorCode: AccessDenied — it shows the exact identity, action and resource, and sometimes more about the policy that denied it.