Examkin

Question

Difficulty: Very hardIAM Policies and Roles

A developer is implementing a cross-account ingestion pipeline where an AWS Lambda function running in Account A (111111111111111111111111) needs to write files to an Amazon S3 bucket in Account B (222222222222222222222222). The Lambda function is configured with the execution role `arn:aws:iam::111111111111:role/LambdaExecutionRole`.

To write files, the Lambda function code uses the AWS SDK to assume an IAM role in Account B named `S3WriteRole` (`arn:aws:iam::222222222222:role/S3WriteRole`).

The IAM policy attached to `LambdaExecutionRole` in Account A is:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::222222222222:role/S3WriteRole"
}
]
}

When the Lambda function executes, the `sts:AssumeRole` API call fails with an `AccessDenied` error. The developer inspects the trust policy of `S3WriteRole` in Account B, which is currently configured as follows:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}

Which of the following modifications to Account B's `S3WriteRole` trust policy will resolve this authorization error?

  1. A
    Keep the Service principal as lambda.amazonaws.com and add a Condition block matching the aws:PrincipalArn to arn:aws:iam::111111111111:role/LambdaExecutionRole.
  2. B
    Update the Action element in the trust policy to include both sts:AssumeRole and s3:PutObject, and set the Resource to the S3 bucket ARN.
  3. Change the Principal element in the trust policy to trust the AWS resource ARN: "AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole".Answer
  4. D
    Hardcode the access keys of an IAM user in Account B who has write access to the S3 bucket directly into the Lambda function code, bypassing the STS call.

Answer

Change the Principal element in the trust policy to trust the AWS resource ARN: "AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole".
The correct answer changes the trust policy's principal to trust the AWS principal of the execution role. This is correct because when the Lambda function runs and makes an SDK call to assume the role, it uses the credentials of its execution role. The target role's trust policy in Account B must explicitly trust this execution role ARN.

Step-by-Step Solution

1
Analyze the IAM caller context of the Lambda execution environment.
The AWS SDK inside the Lambda function uses the function's execution role (`LambdaExecutionRole`) to sign the request to assume the target role.
Understanding which principal initiates the API request is key to setting up the trust relationship.
2
Determine the required trust policy principal type.
Since the request is made by an IAM role (an AWS principal) and not by the Lambda service itself, the trust policy must use the "AWS" principal type pointing to the role's ARN.
Service principals are only used when AWS services (like Lambda or EC2) directly assume a role to bootstrap an execution environment, not for programmatic calls.
3
Validate the cross-account role assumption handshake.
Account A's role has permission to perform `sts:AssumeRole` on Account B's role, and Account B's role trusts Account A's role. This completes the trust chain.
Both sides of the cross-account relationship must be explicitly configured for the action to succeed.

Key Concept

AWS IAM trust relationships require configuring the correct principal type (AWS principal vs Service principal) depending on who is performing the role assumption.
Estimated Time:3m 0s
Rate this question

Topics

IAM Policies and Roles

More questions from this topic