Question

A security engineer configures cross-account access so that an application role in a production account (Account B) can be assumed by an automation role in a tooling account (Account A). The engineer attached an identity-based policy to the automation role in Account A granting sts:AssumeRole on the target role's ARN. In Account B, the target role's trust policy lists only the AWS service principal 'ec2.amazonaws.com' as a trusted principal, and the target role has a permissions policy allowing the required S3 actions. When the automation role attempts to assume the target role, the AssumeRole call fails with AccessDenied. What is the correct fix?

Accepted Answer

Modify the target role's trust policy in Account B to include the automation role's ARN (or Account A's root) as a trusted principal for sts:AssumeRole.

Answer

Add an additional sts:AssumeRole statement to the automation role's identity-based policy in Account A specifying the wildcard resource '*'.

Answer

Attach a resource-based S3 bucket policy in Account B allowing the automation role to access the bucket directly.

Answer

Increase the target role's maximum session duration in Account B so the AssumeRole session token can be issued.