Home / AWS / AWS cloud troubleshooting: AWS IAM Role AssumeRole Failed Because an Explicit

AWS

AWS cloud troubleshooting: AWS IAM Role AssumeRole Failed Because an Explicit

Fix STS `AssumeRole` failures where the trust policy looks correct but an explicit deny in an identity policy, permission boundary, or SCP still blocks the request.

Published: Jan 22, 20269 min readBy FixWikiHub Editorial Team

Abstract illustration for a troubleshooting knowledge base category.

Introduction

AWS IAM uses a policy evaluation logic where explicit deny statements always override allow statements. This is a fundamental security principle: if any policy in the evaluation chain contains an explicit deny for an action, the request is blocked regardless of how many allow statements exist. This design prevents accidental access escalation through policy combination.

When an AssumeRole call fails with AccessDenied, administrators typically check the role's trust policy. However, AWS evaluates multiple policy types during authorization: identity-based policies attached to the calling principal, resource-based policies (trust policy for roles), permission boundaries, service control policies (SCPs), and session policies. An explicit deny in any of these layers blocks the request.

Understanding the complete policy evaluation chain is essential for debugging AssumeRole failures. The trust policy is necessary but not sufficient—every layer must permit the action. Debugging requires systematically checking each policy type that applies to the caller and the target role.

Symptoms

When AWS IAM AssumeRole fails due to explicit deny, you will observe these symptoms:

sts:AssumeRole returns AccessDenied error despite correct trust policy
Role trust policy appears correct when reviewed in isolation
One principal can assume the role while another cannot
Failure started after SCP, permission boundary, or tag-based policy changes
Cross-account role assumption works from some accounts but not others
CloudTrail shows AssumeRole attempt with AccessDenied and policy evaluation details
IAM Policy Simulator shows the action as denied

Common error messages:

```bash aws sts assume-role --role-arn arn:aws:iam::123456789012:role/MyRole --role-session-name test

# Error output: An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::123456789012:user/testuser is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::123456789012:role/MyRole ```

CloudTrail event showing explicit deny:

json

{
  "eventName": "AssumeRole",
  "errorCode": "AccessDenied",
  "errorMessage": "User is not authorized to perform: sts:AssumeRole",
  "userIdentity": {
    "arn": "arn:aws:iam::123456789012:user/testuser"
  },
  "resources": [{
    "ARN": "arn:aws:iam::123456789012:role/MyRole"
  }]
}

Common Causes

Several factors cause AssumeRole failures through explicit deny:

1.Explicit deny in caller's identity policy: The IAM user or role making the AssumeRole call has an attached policy with an explicit deny on sts:AssumeRole or a wildcard that includes it.
2.Permission boundary blocking the action: Permission boundaries set the maximum permissions a principal can have. A boundary with no sts:AssumeRole permission or explicit deny blocks the action.
3.Organization Service Control Policy (SCP): SCPs apply to AWS accounts and can deny actions account-wide. An SCP denying sts:AssumeRole blocks all role assumptions in affected accounts.
4.Trust policy conditions not met: The role's trust policy includes conditions (ExternalId, MFA, source identity, session tags) that the caller doesn't satisfy.
5.Session policy deny: When assuming a role with inline session policies, those policies may deny specific actions.
6.Attribute-based access control (ABAC) deny: Tag-based conditions in policies may deny access based on missing or mismatched tags on the caller or role.
7.Cross-account permission missing: For cross-account role assumption, the source account must also allow sts:AssumeRole for the target role.

Step-by-Step Fix

Follow these steps to diagnose and resolve explicit deny AssumeRole failures:

Step 1: Identify the calling principal

Determine exactly who is trying to assume the role:

```bash # Check current caller identity aws sts get-caller-identity

# Output: { "UserId": "AIDACKCEVSQ6C2EXAMPLE", "Account": "123456789012", "Arn": "arn:aws:iam::123456789012:user/testuser" }

# Note the ARN - this is the principal to investigate ```

Step 2: Check the role's trust policy

Verify the trust policy allows the calling principal:

```bash # Get role trust policy aws iam get-role --role-name MyRole --query 'Role.AssumeRolePolicyDocument'

# Example trust policy: { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::123456789012:root"}, "Action": "sts:AssumeRole", "Condition": { "StringEquals": {"sts:ExternalId": "my-external-id"} } }] }

# Verify caller's account is in Principal # Check if conditions are required and being met ```

Step 3: Check caller's identity policies

Look for explicit denies in attached policies:

```bash # List policies attached to the user aws iam list-attached-user-policies --user-name testuser

# List inline policies for the user aws iam list-user-policies --user-name testuser

# Get specific policy content aws iam get-policy --policy-arn arn:aws:iam::aws:policy/AWSDenyAll

# Search for explicit denies aws iam get-policy-version \ --policy-arn arn:aws:iam::123456789012:policy/MyPolicy \ --version-id v1 \ --query 'PolicyVersion.Document.Statement[?Effect==Deny]'

# Check for wildcard denies # Look for: "Action": "sts:AssumeRole" or "Action": "*" ```

Step 4: Check permission boundaries

Verify permission boundary allows AssumeRole:

```bash # Check if user has permission boundary aws iam get-user --user-name testuser --query 'User.PermissionsBoundary'

# Output if boundary exists: { "PermissionsBoundaryType": "Policy", "PermissionsBoundaryArn": "arn:aws:iam::123456789012:policy/MyBoundary" }

# Get boundary policy content aws iam get-policy-version \ --policy-arn arn:aws:iam::123456789012:policy/MyBoundary \ --version-id v1

# Check if boundary allows sts:AssumeRole # Boundary must explicitly allow the action ```

Step 5: Check Service Control Policies

Examine organization SCPs:

```bash # List SCPs attached to the account aws organizations list-policies-for-target --target-id 123456789012 --filter SERVICE_CONTROL_POLICY

# Get SCP content aws organizations describe-policy --policy-id p-example

# Look for explicit denies: { "Statement": [{ "Effect": "Deny", "Action": ["sts:AssumeRole"], "Resource": "*" }] }

# SCPs apply to all principals in the account # Even root user is subject to SCP ```

Step 6: Check trust policy conditions

Verify all conditions are being met:

```bash # If ExternalId required: aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/MyRole \ --role-session-name test \ --external-id my-external-id

# If MFA required, ensure MFA is used: aws sts get-session-token --serial-number arn:aws:iam::123456789012:mfa/user --token-code 123456

# If source identity required: aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/MyRole \ --role-session-name test \ --source-identity admin@company.com ```

Step 7: Use IAM Policy Simulator

Test the exact policy evaluation:

```bash # Via AWS Console: # IAM > Policy Simulator # Select user: testuser # Select action: sts:AssumeRole # Specify resource: arn:aws:iam::123456789012:role/MyRole

# Via CLI (simplified): # The simulator shows which policy statements matched # And whether the final result is allowed or denied ```

Step 8: Remove or modify the conflicting deny

Fix the policy that contains the explicit deny:

```bash # If deny is in identity policy, create new version without deny: aws iam create-policy-version \ --policy-arn arn:aws:iam::123456789012:policy/MyPolicy \ --policy-document '{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["sts:AssumeRole"], "Resource": "arn:aws:iam::123456789012:role/MyRole" }] }' \ --set-as-default

# If deny is in permission boundary, update boundary: aws iam put-user-policy \ --user-name testuser \ --policy-name AllowAssumeRole \ --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"*","Resource":"*"}]}' ```

Step 9: Test after changes

Verify the fix works:

```bash # Attempt AssumeRole aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/MyRole \ --role-session-name test

# Expected successful output: { "Credentials": { "AccessKeyId": "ASIAX...", "SecretAccessKey": "...", "SessionToken": "...", "Expiration": "..." }, "AssumedRoleUser": { "AssumedRoleId": "AROAX...:test", "Arn": "arn:aws:sts::123456789012:assumed-role/MyRole/test" } } ```

Verification

After fixing the policy, verify AssumeRole works correctly:

```bash # Test role assumption aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/MyRole \ --role-session-name verification-test \ --query 'Credentials.[AccessKeyId,Expiration]'

# Should return credentials without error

# Use assumed role credentials aws sts get-caller-identity --profile assumed-role

# Should show the assumed role ARN # arn:aws:sts::123456789012:assumed-role/MyRole/verification-test ```

Check CloudTrail for successful AssumeRole:

bash

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
  --query 'Events[?contains(CloudTrailEvent, `testuser`)]'

Prevention

To prevent explicit deny AssumeRole failures:

1.Document all policy layers: Maintain clear documentation of all policies affecting principals.

markdown

## Principal: testuser
- Identity Policies: MyPolicy, ReadOnlyAccess
- Permission Boundary: MyBoundary
- SCP: DenyAllExceptAdmin
- Trust Policy Condition: ExternalId required

1.Use IAM Policy Simulator regularly: Test policy changes before deployment.

bash

# Always test with simulator before applying policy changes

1.Avoid broad deny statements: Use specific deny conditions rather than blanket denies.

```json // Better: Specific deny with conditions { "Effect": "Deny", "Action": "sts:AssumeRole", "Resource": "*", "Condition": { "StringNotEquals": {"aws:PrincipalTag/Team": "Admin"} } }

// Avoid: Broad unconditional deny { "Effect": "Deny", "Action": "*", "Resource": "*" } ```

1.Audit SCPs for unintended side effects: SCP changes affect all principals in the account.
2.Implement change management for policies: Review all policy layers when making changes.

bash

# Pre-change checklist:
# 1. Check identity policies
# 2. Check permission boundaries
# 3. Check SCPs
# 4. Check trust policy conditions
# 5. Test with Policy Simulator
# 6. Apply change
# 7. Verify with actual test

1.Use policy conditions for flexibility: Prefer conditions over explicit denies.
2.Monitor AssumeRole failures: Set up CloudWatch alerts for AssumeRole AccessDenied events.

bash

aws cloudwatch put-metric-alarm \
  --alarm-name AssumeRole-Failures \
  --metric-name CallCount \
  --namespace AWS/STS \
  --statistic Sum \
  --period 300 \
  --threshold 10 \
  --comparison-operator GreaterThanThreshold

[AWS troubleshooting: Fix IAM Permission Denied - Complete Tro](fix-iam-permission-denied)
[AWS cloud troubleshooting: AWS ACM Certificate Pending Validation Because the](aws-acm-certificate-pending-validation-wrong-route53-zone)
[AWS cloud troubleshooting: AWS ALB Returns 502 Because the Target Closed the ](aws-alb-502-target-closed-connection-keepalive-timeout-mismatch)
[AWS cloud troubleshooting: Fix AWS ALB CreateListener TargetGroupNotFound Err](aws-alb-createlistener-targetgroupnotfound)
[AWS cloud troubleshooting: Fix Aws Alb Lambda 502 Bad Gateway Issue in AWS](aws-alb-lambda-502-bad-gateway)

Was this guide helpful?

Related search paths

People also search for

If the symptom is close but not identical, these search paths usually surface the right neighboring fixes faster than scrolling the full archive.

AWS cloud troubleshooting: AWS IAM Role AssumeRole Failed AWS cloud troubleshooting: AWS IAM Role AssumeRole Failed AWS AWS cloud troubleshooting: AWS IAM Role AssumeRole Failed troubleshooting AWS cloud troubleshooting: AWS IAM Role AssumeRole Failed fix Fix STS `AssumeRole` failures where the trust policy looks correct but an explicit deny in an identity policy, permission boundary, or SCP still blocks the request AWS Fix STS `AssumeRole` failures where the trust policy looks correct but an explicit deny in an identity policy, permission boundary, or SCP still blocks the request

Explore Related Topics

Browse Guides from Other Categories

Discover troubleshooting guides from related categories to expand your knowledge.

FAQ

AWS Troubleshooting FAQs

Common questions about troubleshooting and preventing similar issues

How do I know if this aws-errors troubleshooting guide applies to my situation?

This guide is designed for aws-errors issues. If you're experiencing similar symptoms described in the article, follow the step-by-step instructions. Start with the most common causes and work through the diagnostic process.

Is it safe to follow these aws-errors troubleshooting steps?

Yes, all steps are designed to be safe and non-destructive. We recommend creating backups before making significant changes and testing each step before proceeding to the next.

How long does it typically take to resolve this type of aws-errors issue?

Most aws-errors issues can be resolved within 30 minutes to 2 hours, depending on the complexity and root cause. Follow the troubleshooting flow to identify and fix the problem efficiently.

How can I prevent this aws-errors issue from happening again?

Regular maintenance, monitoring, and following best practices for aws-errors configuration can help prevent recurrence. Consider implementing automated checks and alerts for early detection.

Written by

FixWikiHub Editorial Team

Our editorial team consists of experienced DevOps engineers, systems administrators, and cloud architects with hands-on experience in production environments across AWS, Azure, GCP, and on-premises infrastructure.

Every guide undergoes technical review for accuracy and is updated when software versions, commands, or best practices change.

Last updated: Jan 22, 2026

About our team

Important Notice

Disclaimer & Safety Guidelines

The troubleshooting steps in this guide are provided for educational and informational purposes. Before applying any changes to production systems:

Test in a staging environment first — Always verify commands and configurations in a non-production environment before deploying to live systems.
Create backups — Ensure you have current backups of databases, configurations, and critical files before making changes.
Understand the impact — Review how each step may affect your specific environment, dependencies, and users.
Consult official documentation — This guide supplements, but does not replace, official vendor documentation and best practices.

FixWikiHub is not responsible for any damages arising from the use of this content. See our Terms of Use for more information.

Resources

Official Documentation & Further Reading

For authoritative information, consult the official documentation for the technologies discussed in this guide. Our troubleshooting content supplements, but does not replace, vendor documentation.

AWS Documentation — Official Amazon Web Services guides and API references
Kubernetes Documentation — Official Kubernetes documentation
Nginx Documentation — Official Nginx web server documentation
Apache Documentation — Official Apache HTTP Server documentation
Docker Documentation — Official Docker container documentation

AWS cloud troubleshooting: AWS IAM Role AssumeRole Failed Because an Explicit

Introduction

Symptoms

Common Causes

Step-by-Step Fix

Step 1: Identify the calling principal

Step 2: Check the role's trust policy

Step 3: Check caller's identity policies

Step 4: Check permission boundaries

Step 5: Check Service Control Policies

Step 6: Check trust policy conditions

Step 7: Use IAM Policy Simulator

Step 8: Remove or modify the conflicting deny

Step 9: Test after changes

Verification

Prevention

Related Articles

People also search for

Browse Guides from Other Categories

WordPress

SSL

DNS

AWS Troubleshooting FAQs

FixWikiHub Editorial Team

Disclaimer & Safety Guidelines

Official Documentation & Further Reading

AWS cloud troubleshooting: AWS IAM Role AssumeRole Failed Because an Explicit

Introduction

Symptoms

Common Causes

Step-by-Step Fix

Step 1: Identify the calling principal

Step 2: Check the role's trust policy

Step 3: Check caller's identity policies

Step 4: Check permission boundaries

Step 5: Check Service Control Policies

Step 6: Check trust policy conditions

Step 7: Use IAM Policy Simulator

Step 8: Remove or modify the conflicting deny

Step 9: Test after changes

Verification

Prevention

Related Articles

People also search for

Share this guide

More AWS Troubleshooting Guides

Browse Guides from Other Categories

AWS Troubleshooting FAQs

FixWikiHub Editorial Team

Disclaimer & Safety Guidelines

Official Documentation & Further Reading