Examkin

Question

Difficulty: HardResolving IAM and Authorization Failures

An application running inside an Amazon ECS task on AWS Fargate in Account A (111111111111111111111111) needs to write objects to an Amazon S3 bucket located in Account B (222222222222222222222222). The developer wants the application to temporarily assume an IAM role named CrossAccountS3Writer in Account B. The ECS task definition is configured with an ECS Task Role named ECSTaskRole.

The trust policy of the CrossAccountS3Writer role in Account B contains the following statement:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:role/ECSTaskRole"
},
"Action": "sts:AssumeRole"
}
]
}

When the application execution code attempts to call the sts:AssumeRole API, it fails with an AccessDenied error. How should the developer resolve this authorization failure?

  1. Attach an identity-based policy to ECSTaskRole in Account A that grants the sts:AssumeRole permission targeting the Amazon Resource Name (ARN) of the CrossAccountS3Writer role in Account B.Answer
  2. B
    Attach an identity-based policy to the ECS Task Execution Role in Account A that grants the sts:AssumeRole permission targeting the Amazon Resource Name (ARN) of the CrossAccountS3Writer role in Account B.
  3. C
    Modify the trust policy of the CrossAccountS3Writer role in Account B to specify the ECS service principal ecs-tasks.amazonaws.com as the principal instead of the ECSTaskRole ARN.
  4. D
    Generate long-term IAM access keys for a user in Account B, hardcode them into the application's client initialization code, and initialize the S3 client directly using those credentials.

Answer

Attach an identity-based policy to ECSTaskRole in Account A that grants the sts:AssumeRole permission targeting the Amazon Resource Name (ARN) of the CrossAccountS3Writer role in Account B.
For cross-account role assumption, AWS IAM requires a bilateral handshake: the trusting role (in Account B) must specify the external principal in its trust policy, and the trusted principal (in Account A) must have an identity-based policy that grants permission to call 'sts:AssumeRole' on the target role's ARN. Since the trust policy in Account B is already correctly configured, adding the 'sts:AssumeRole' permission to the ECSTaskRole in Account A completes this handshake and resolves the AccessDenied error.

Step-by-Step Solution

1
Analyze the error context and the resource policy configuration.
The application inside the ECS task is trying to assume the CrossAccountS3Writer role in Account B, but the AssumeRole request is denied.
Establishing cross-account delegation requires explicit authorization in both accounts: a trust relationship in the receiving account (Account B) and an identity-based grant in the initiating account (Account A).
2
Examine the trust policy of the target role (CrossAccountS3Writer) in Account B.
The trust policy correctly allows the identity 'arn:aws:iam::111111111111:role/ECSTaskRole' to call 'sts:AssumeRole'.
This confirms that Account B is configured properly to trust the ECS Task Role from Account A.
3
Determine the missing permission in the initiating account (Account A).
The ECS Task Role (ECSTaskRole) itself does not have a policy permitting it to invoke 'sts:AssumeRole' on the destination role.
IAM identities require explicit permission to call 'sts:AssumeRole' on a resource in another account, even if that resource trusts them.
4
Select the correct action to resolve the authorization failure.
Add an identity-based policy to 'ECSTaskRole' with an 'Allow' effect on the 'sts:AssumeRole' action, specifying the ARN of the target role in Account B as the resource.
This satisfies the cross-account delegation requirements by authorizing the ECS Task Role to perform the assume-role request.

Key Concept

Cross-Account IAM Delegation and ECS Task Roles
Rate this question

Topics

Resolving IAM and Authorization Failures

More questions from this topic