bregman-arie When to use
Use when you receive AccessDenied, UnauthorizedOperation, or not authorized to perform errors.
Preconditions
- You can access the AWS account with permission to inspect IAM and CloudTrail.
- You can identify the failing action and, ideally, the principal and resource.
Procedure
- Capture the failing API action, resource, region, and principal (role/user).
- Look up the corresponding CloudTrail event (or application logs) for context.
- Identify which policy types apply: identity policy, resource policy, permission boundary, SCP, session policy.
- Use policy simulation to confirm the explicit deny/implicit deny.
- Propose the narrowest change that grants access.
Decision points
- Explicit Deny in any layer: must remove/override deny (cannot be allowed elsewhere).
- SCP denies: change must happen at org/OU level.
- Resource policy missing principal: update resource policy rather than identity.
- Permission boundary blocks: adjust boundary or use a different role.
Verification
- Re-run the exact API call and confirm success.
- Confirm no broader permissions were granted than necessary.
Rollback / undo
- Revert the policy change to the prior version.
- Detach any temporary policies used for debugging.
Escalation
- Security/IAM owners for SCP/boundary changes.
- Service owners for resource policy changes on shared resources.
Examples
Action: s3:GetObject
Resource: arn:aws:s3:::<bucket>/<key>
Principal: arn:aws:sts::<account>:assumed-role/<role>/<session>