ERROR REFERENCE
Denied because no policy allows it
An implicit deny: nothing blocks the action, but nothing grants it either. The error wording names the policy layer AWS expected the permission in — that is where the fix goes, as a least-privilege Allow for exactly the denied action and resource.
WHAT IT MEANS
What this error means
Modern IAM denial messages are precise about what was missing:
... is not authorized to perform: <action> on resource:
<arn> because no identity-based policy allows the
<action> action. The variants name different layers:
- "no identity-based policy allows" — the deploy role or user simply lacks the permission. The most common case for CloudFormation execution roles that were scoped before the template grew a new resource type.
- "no resource-based policy allows" — the target bucket, key, queue, or secret needs to grant the caller in its own policy.
- "no session policy allows" — the assumed-role session was created with a restricted session policy that filtered the permission out.
A wrong identity often masquerades as this failure: a deploy running under a different profile or role than intended is missing permissions it "should" have because it is not the principal you think it is.
FIX
How to fix it
-
Confirm the identity first:
in the failing environment. If the account or role is not what you expected, fix the profile/role selection — not the policies.aws sts get-caller-identity - Grant the exact denied action on the exact resource in the policy layer the error names: the deploy role's identity policy, or the resource policy of the named bucket, key, or queue.
- Confirm the change with the IAM Policy Simulator before re-running the deployment — simulator runs are free and faster than deploy-retry loops.
- If it is unclear which policy applies, look up the denied event in CloudTrail (by request ID when the error includes one).
-
Keep the grant least-privilege. Never attach
AdministratorAccessto make a deployment pass.
AUTOMATE THE TRIAGE
Diagnose this automatically
SAM Doctor recognizes the no-policy-allows wording (high confidence), reports the denied action and expected policy layer from redacted evidence, and keeps explicit denies, OIDC failures, and ECR permission errors as their own findings. Runs locally; no AWS access, no log upload.
python -m pip install sam-doctor
sam-doctor diagnose deployment.log --format markdownRELATED
Related errors
- Access denied with an explicit deny — the opposite case: a Deny statement blocks the action, and no Allow can help.
- Not authorized to perform: sts:AssumeRoleWithWebIdentity — when the denial happens before the session even exists.
- The security token included in the request is expired — a credential-lifetime failure that is not a permissions problem at all.