Examkin

Question

Difficulty: EasyResolving IAM and Authorization Failures

A developer has configured a microservice to perform actions in a different AWS account by assuming an IAM role. The microservice's execution role has an IAM policy that allows the sts:AssumeRole action on the target role's ARN. During execution, the microservice fails to assume the target role and receives an AccessDenied error. Which of the following is the most likely cause of this authorization failure?

  1. A
    The permission policy attached to the target IAM role is missing the sts:AssumeRole action.
  2. B
    The microservice is missing hardcoded AWS access keys for the target IAM role in its initialization code.
  3. The trust policy of the target IAM role does not list the microservice's execution role ARN as a trusted principal.Answer
  4. D
    The destination account must configure an Amazon Cognito Identity Pool to authorize cross-account access for the microservice.

Answer

The trust policy of the target IAM role does not list the microservice's execution role ARN as a trusted principal.
For an identity to successfully assume an IAM role (especially in another account), two conditions must be met: the calling identity must have permission to call sts:AssumeRole on the target role, and the target role's trust policy must list the calling identity as a trusted principal. Since the caller already has the necessary permission policy, the failure is due to the trust policy of the target IAM role missing the caller's execution role ARN as a trusted principal.

Step-by-Step Solution

1
Analyze the IAM role assumption request flow.
The caller (microservice's execution role) calls the AWS Security Token Service (STS) AssumeRole API on the target role.
This establishes that permissions are required on both the caller side (identity-based permission policy) and the callee side (resource-based trust policy).
2
Verify identity-based permissions.
The microservice's execution role already has a policy allowing sts:AssumeRole on the target role.
This rules out a permission failure on the caller's side.
3
Verify resource-based trust policy permissions.
Identify that the target role must have a trust policy granting assume-role permission to the caller principal.
Without the trust policy explicitly listing the caller's ARN, STS rejects the role assumption, causing an AccessDenied error.

Key Concept

IAM AssumeRole Trust Policies
Rate this question

Topics

Resolving IAM and Authorization Failures

More questions from this topic