AWS IAM: iam:PassRole Access Denied - The Complete Guide to Fixing the Most Confusing Error

The "not authorized to perform: iam:PassRole" error means your AWS identity lacks permission to assign an IAM role to an AWS service—but the fix depends entirely on which service you're passing it to. This guide covers the actual difference between PassRole and AssumeRole, service-specific troubleshooting for ECS, Lambda, CloudFormation and others with real code examples, ready-to-use policy templates, security best practices, and why this error confuses even experienced AWS users.

The Core Confusion: PassRole vs. AssumeRole

Most AWS users don't realize these are completely different permissions serving different purposes. Understanding the distinction is the first step to fixing your error—and it's the reason the error message is so confusing.

The Six Common Causes of PassRole Errors

1. Missing PassRole Permission (Most Common)

Your IAM user or role simply doesn't have the iam:PassRole action in any attached policy. This is the most frequent cause and the easiest to fix.

1. Check your current policies:

   aws iam list-attached-user-policies --user-name your-username
   aws iam list-role-policies --role-name your-role

2. Add PassRole permission:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "iam:PassRole",
         "Resource": "arn:aws:iam::ACCOUNT_ID:role/YOUR_ROLE_NAME"
       }
     ]
   }

2. Wrong Resource ARN

You have PassRole permission, but for a different role than the one you're trying to pass. The Resource element in your policy must match the ARN of the role you're passing.

The Diagnostic Flowchart: Find Your Failure Point

Follow this decision tree to identify exactly where the trust is breaking:

Service-Specific Fixes with Real Code Examples

Amazon ECS: Task Role PassRole Errors

The most common PassRole scenario. When you run an ECS task with a task role, you need PassRole permission for that specific role.

Typical error in ECS:

Unable to assume the role 'arn:aws:iam::123456789012:role/ecsTaskRole' 
because no identity-based policy allows the iam:PassRole action 
on the resource 'arn:aws:iam::123456789012:role/ecsTaskRole'

Fix for CLI users:

1. Identify the task role ARN from your task definition
2. Create/update your policy:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "AllowPassECSTaskRole",
         "Effect": "Allow",
         "Action": "iam:PassRole",
         "Resource": "arn:aws:iam::123456789012:role/ecsTaskRole"
       }
     ]
   }

3. Attach the policy to your user or role

Fix for CDK users (broader permissions needed):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCDKDeployments",
      "Effect": "Allow",
      "Action": [
        "iam:PassRole",
        "iam:GetRole",
        "iam:CreateRole",
        "iam:DeleteRole",
        "iam:UpdateRole"
      ],
      "Resource": "*"
    }
  ]
}

AWS Lambda: Execution Role PassRole Errors

When creating or updating a Lambda function with a custom execution role, you need PassRole permission.

Typical error in Lambda:

User: arn:aws:iam::123456789012:user/dev is not authorized to perform: 
iam:PassRole on resource: 
arn:aws:iam::123456789012:role/lambda-execution-role

Fix for Lambda:

1. Check your Lambda execution role ARN
2. Add PassRole permission:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "AllowPassLambdaRole",
         "Effect": "Allow",
         "Action": "iam:PassRole",
         "Resource": "arn:aws:iam::123456789012:role/lambda-execution-role"
       }
     ]
   }

3. For console users, you also need:

   {
     "Sid": "AllowListRolesForConsole",
     "Effect": "Allow",
     "Action": "iam:ListRoles",
     "Resource": "*"
   }

CloudFormation: Service Role PassRole Errors

When deploying CloudFormation stacks with service roles, you need PassRole permission for those roles.

Typical error in CloudFormation:

CloudFormation is not authorized to perform: 
iam:PassRole on resource: 
arn:aws:iam::123456789012:role/cloudformation-service-role

Fix for CloudFormation:

1. Identify the CloudFormation service role in your template
2. Add PassRole permission:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "AllowPassCFNRole",
         "Effect": "Allow",
         "Action": "iam:PassRole",
         "Resource": "arn:aws:iam::123456789012:role/cloudformation-service-role"
       }
     ]
   }

3. For stack sets, you may need PassRole for multiple roles across accounts

Other Services: Quick Reference

Ready-to-Use Policy Templates

Template 1: Least-Privilege PassRole (Production)

For security-conscious environments, scope PassRole to exactly the roles needed:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPassSpecificRoleToECS",
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::123456789012:role/ecs-prod-task-role",
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "ecs.amazonaws.com"
        }
      }
    }
  ]
}

Template 2: Pattern-Based PassRole (Teams)

For teams with naming conventions, use wildcards to allow multiple roles:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPassProjectRoles",
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::123456789012:role/project-alpha-*"
    }
  ]
}

Template 3: Multi-Service PassRole (Platform Teams)

For platform teams that need to pass roles to multiple services:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPassToComputeServices",
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": [
            "ecs.amazonaws.com",
            "lambda.amazonaws.com",
            "ec2.amazonaws.com"
          ]
        }
      }
    }
  ]
}

Template 4: CDK Deployment Role

Dedicated policy for CDK deployment roles:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCDKRoleManagement",
      "Effect": "Allow",
      "Action": [
        "iam:PassRole",
        "iam:GetRole",
        "iam:CreateRole",
        "iam:DeleteRole",
        "iam:UpdateRole",
        "iam:TagRole",
        "iam:UntagRole",
        "iam:ListRoleTags",
        "iam:PutRolePolicy",
        "iam:DeleteRolePolicy",
        "iam:GetRolePolicy"
      ],
      "Resource": "*"
    }
  ]
}

Security Analysis: The Hidden Dangers of PassRole

The Privilege Escalation Risk

Here's the attack scenario that keeps security engineers awake at night:

1. Attacker compromises a low-privileged IAM user
2. That user has PassRole with Resource: "*"
3. Attacker creates an ECS task and passes an admin role to it
4. The ECS task now has admin permissions in your account
5. Attacker uses the ECS task to access all resources

This is why AWS's own documentation recommends against broad PassRole permissions in production.

Security Best Practices

1. Never use Resource: "*" in production unless combined with a Condition restricting the service
2. Use naming conventions for roles so you can use pattern matching (e.g., role/prod-*)
3. Audit PassRole permissions regularly using IAM Access Analyzer
4. Consider using conditions like iam:PassedToService to restrict which services can receive roles
5. Monitor resource creation in CloudTrail (since PassRole itself isn't logged)
6. Separate deployment roles from operational roles
7. Use service-linked roles where possible (they don't require PassRole)

CloudTrail Quirks: Why PassRole Doesn't Appear in Logs

Here's something that confuses even experienced AWS users: PassRole is not an API call, so it doesn't appear in CloudTrail logs.

To audit PassRole usage, you must look at the CloudTrail events for the resource creation actions:

• ECS: Look for RunTask or CreateService events—the role ARN is in requestParameters.taskDefinition
• Lambda: Look for CreateFunction or UpdateFunctionConfiguration events—the role ARN is in requestParameters.role
• CloudFormation: Look for CreateStack or UpdateStack events—the role ARN is in requestParameters.roleARN
• EC2: Look for RunInstances events—the role ARN is in requestParameters.iamInstanceProfile

Real-World Scenarios: Learning from Others' Mistakes

Scenario 1: The CDK Deployment That Failed

A developer tries to deploy an ECS service with CDK, using their personal IAM user with limited permissions.

What happened: CDK needed to create IAM roles and pass them to ECS, but the developer's policy only had basic S3 and Lambda permissions.

Why it was confusing: The error said "PassRole" but the developer didn't realize CDK creates and manages IAM roles as part of deployment.

The fix: Created a dedicated CDK deployment role with broader IAM permissions, including PassRole, CreateRole, and DeleteRole.

Scenario 2: The Cross-Account Role

A platform engineer tries to pass a role from their production account to a service in their development account.

What happened: The PassRole permission existed in the development account, but the role's trust policy in production only allowed specific identities from the production account.

Why it was confusing: The error appeared to be about PassRole, but the real issue was the trust policy in the other account.

The fix: Updated the role's trust policy in production to allow the development account's service principal.

Scenario 3: The SCP That Blocked Everything

A security team implements an SCP that denies all IAM permissions for all users in an OU, including PassRole.

What happened: Developers in that OU couldn't create any resources that required roles, breaking CI/CD pipelines.

Why it was confusing: The IAM policies allowed PassRole, but the SCP at the organization level denied it. The error didn't clearly indicate the SCP was the cause.

The fix: Updated the SCP to allow PassRole for specific role patterns while maintaining other restrictions.

Frequently Asked Questions

1. What's the difference between iam:PassRole and sts:AssumeRole?

PassRole allows you to assign a role to an AWS service (like ECS or Lambda). AssumeRole allows an identity to become that role. They're separate permissions that solve different problems.

2. Do I need iam:PassRole for Lambda's basic execution role?

If you're using Lambda's default execution role, no. But if you're creating a custom execution role, you need PassRole permission for that specific role ARN.

3. Can I use wildcards in PassRole Resource ARNs?

Yes, you can use wildcards like role/project-* to allow passing any role matching that pattern. This is common for teams with naming conventions.

4. Why doesn't iam:PassRole appear in CloudTrail?

Because PassRole is a permission, not an API call. To audit PassRole usage, look at CloudTrail events for the resource creation (RunTask, CreateFunction, CreateStack, etc.).

5. Does the root user need iam:PassRole permission?

No. The root user has all permissions by default, including PassRole. However, using root for daily operations is against AWS best practices.

6. Can I restrict PassRole to specific AWS services?

Yes, using the iam:PassedToService condition key. For example: "Condition": {"StringEquals": {"iam:PassedToService": "ecs.amazonaws.com"}}

7. What's the difference between a service role and a service-linked role?

A service role is created by you and passed to a service. A service-linked role is created by AWS specifically for that service. Service-linked roles don't require PassRole.

8. Do I need PassRole for EC2 instance profiles?

Yes. When you launch an EC2 instance with an IAM role (instance profile), you need PassRole permission for that role.

9. Can SCPs block iam:PassRole?

Yes. Service Control Policies can explicitly deny PassRole at the organization level, even if your IAM policies allow it.

10. How do I fix PassRole errors in CDK deployments?

CDK deployments often need broader PassRole permissions. Add "Action": ["iam:PassRole", "iam:GetRole"] with "Resource": "*" to your deployment role.

11. What if the role is in a different AWS account?

You need PassRole permission in your account, and the role's trust policy in the other account must allow your account (or specifically your identity) to assume it.

12. Can I use PassRole with temporary credentials?

Yes, but temporary credentials may have session policies that restrict PassRole. Check for session policy limitations.

13. How do I test PassRole permissions without creating resources?

Use the IAM Policy Simulator: aws iam simulate-principal-policy --policy-source-arn YOUR_ARN --action-names iam:PassRole --resource-arns ROLE_ARN

14. What's the minimum PassRole policy for ECS deployments?

At minimum, you need PassRole for your task role ARN. For CDK, you may also need iam:GetRole.

15. Do I need PassRole for SageMaker notebook instances?

Yes. Creating a SageMaker notebook with a custom role requires PassRole permission for that role.

16. How do I audit PassRole permissions across my account?

Use IAM Access Analyzer to identify external access, and review IAM policies attached to users and roles for PassRole actions. Then use the IAM Policy Simulator to test specific scenarios.

Conclusion: From Confusion to Clarity

The iam:PassRole error isn't actually confusing once you understand what PassRole does: it's the permission to assign a role to an AWS service, separate from the service's ability to assume that role.

The error appears in many contexts—ECS, Lambda, CloudFormation, RDS, and more—but the fix is always the same pattern: add PassRole permission with the correct Resource ARN to your identity policy.

Remember the security principle: scope your PassRole to specific roles whenever possible. The convenience of Resource: "*" isn't worth the security risk in production environments.

Revision note. Written September 2026, covering AWS IAM PassRole errors as of writing. AWS services continue to add new contexts where PassRole is required, so always check the specific service documentation when troubleshooting. If you've been fighting this error, remember that you're not alone—PassRole confusion is one of the most common IAM issues, and now you have the knowledge to fix it quickly and securely.