Examkin

Question

Difficulty: MediumResolving IAM and Authorization Failures

A developer has configured an AWS Lambda function in Account A to write data to an Amazon DynamoDB table in Account B. To achieve this, the Lambda function code uses the AWS SDK to call `sts:AssumeRole` on an IAM role in Account B named `DynamoDBWriteRole`. The Lambda function's execution role in Account A has a policy allowing `sts:AssumeRole` on the ARN of `DynamoDBWriteRole`. However, the function execution fails with an `AccessDenied` error during the STS assume role operation. The developer examines the trust policy of `DynamoDBWriteRole` in Account B:

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

Which of the following actions will resolve this authorization failure?

  1. A
    Add a Principal block specifying lambda.amazonaws.com directly to the identity-based permission policy attached to the Lambda execution role in Account A.
  2. B
    Modify the Lambda function code to initialize the DynamoDB client by passing hardcoded IAM Access Key IDs and Secret Access Keys from the Lambda execution role.
  3. Update the trust policy of DynamoDBWriteRole in Account B to specify the ARN of the Lambda execution role from Account A in the Principal block instead of the Lambda service principal.Answer
  4. D
    Configure a Cognito Identity Pool in Account B to authenticate the Lambda function and obtain temporary AWS credentials for DynamoDB.

Answer

Updating the trust policy of DynamoDBWriteRole in Account B to specify the ARN of the Lambda execution role from Account A in the Principal block instead of the Lambda service principal.
The correct action is to modify the trust policy of the target role in Account B so that it trusts the ARN of the Lambda execution role in Account A. When a Lambda function runs and utilizes the AWS SDK to call `AssumeRole`, the call is initiated under the identity of the Lambda execution role, not the Lambda service principal. Therefore, the destination role's trust policy must explicitly allow the execution role's ARN (or Account A) as the trusted Principal.

Step-by-Step Solution

1
Identify the identity making the role assumption request.
The Lambda function's execution role in Account A is the calling identity that invokes `sts:AssumeRole`.
When code running inside a Lambda function uses the AWS SDK to assume a role, the request is authenticated via the function's execution role credentials.
2
Analyze the destination role's trust policy in Account B.
The current trust policy grants permissions only to the AWS service principal `lambda.amazonaws.com`.
The service principal `lambda.amazonaws.com` is used to allow the Lambda service to assume a role to execute a function, not to allow programmatic SDK calls made by an IAM role.
3
Modify the trust policy of the destination role in Account B.
Replace the service principal in the Principal block with the ARN of the Lambda execution role from Account A.
This establishes the necessary cross-account trust relation allowing the specific IAM identity from Account A to call `sts:AssumeRole` on the role in Account B.

Key Concept

Understanding and resolving IAM trust policy misconfigurations in cross-account delegation.
Estimated Time:1m 30s
Rate this question

Topics

Resolving IAM and Authorization Failures

More questions from this topic