Examkin

Question

Difficulty: HardIAM Policies and Roles

A developer is configuring an AWS Lambda function in Account A (111122223333111122223333) to write data to an Amazon DynamoDB table in Account B (444455556666444455556666). The function executes using the IAM execution role `AccountALambdaRole`. The developer creates an IAM role named `CrossAccountAccessRole` in Account B with a policy that allows write operations on the DynamoDB table. The trust policy for `CrossAccountAccessRole` is currently configured as follows:

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

When the Lambda function in Account A attempts to assume the role `CrossAccountAccessRole` using the AWS SDK to write to the DynamoDB table, it fails with an `AccessDenied` error. Which two of the following modifications are required to resolve this error and allow the Lambda function to write to the DynamoDB table?

  1. Update the trust policy of CrossAccountAccessRole in Account B to specify the Principal as "AWS": "arn:aws:iam::111122223333:role/AccountALambdaRole" instead of the lambda.amazonaws.com service principal.Answer
  2. Attach an IAM permission policy to AccountALambdaRole in Account A that grants the sts:AssumeRole action on the resource arn:aws:iam::444455556666:role/CrossAccountAccessRole.Answer
  3. C
    Add a statement to the identity-based permission policy of AccountALambdaRole in Account A that includes a Principal element set to lambda.amazonaws.com with the sts:AssumeRole action.
  4. D
    Modify the trust policy of the Lambda execution role AccountALambdaRole in Account A to trust the role arn:aws:iam::444455556666:role/CrossAccountAccessRole.
  5. E
    Configure the Lambda function code to use hardcoded AWS access keys of an IAM user from Account B in the AWS SDK client constructor to write to the DynamoDB table directly.

Answer

To allow the Lambda function in Account A to write to the DynamoDB table in Account B, the developer must update the trust policy of the target role in Account B to trust the Lambda execution role's ARN, and attach an identity-based policy to the Lambda execution role in Account A that allows the sts:AssumeRole action on the target role's ARN.
For cross-account access using IAM roles, a two-way authorization flow must be established. First, the trust policy of the target role in Account B must be updated to specify the caller's ARN (Account A's Lambda role) as the trusted Principal. Second, the calling identity (Account A's Lambda role) must be granted the sts:AssumeRole permission on the target role's ARN in its identity-based policy. This establishes both the trust from the target and the permission from the source.

Step-by-Step Solution

1
Modify the trust policy in the target account (Account B).
The trust policy of CrossAccountAccessRole in Account B is updated to trust the ARN of AccountALambdaRole from Account A.
This establishes trust between Account B's role and the specific IAM principal in Account A, permitting the execution role to assume it.
2
Modify the permissions policy in the source account (Account A).
An identity-based policy is attached to AccountALambdaRole allowing the sts:AssumeRole action on the target role's ARN in Account B.
This grants the caller in Account A the necessary outbound permission to perform the role assumption operation.
3
Update the Lambda function code to use temporary credentials.
The AWS SDK calls AssumeRole, retrieves temporary credentials, and instantiates the DynamoDB client using them.
The function must run with the temporary credentials generated by the assumed role to access the DynamoDB table in Account B.

Key Concept

Cross-account IAM role assumption requires both a trust policy on the target role specifying the calling principal and a permission policy on the calling principal allowing sts:AssumeRole on the target role resource.
Rate this question

Topics

IAM Policies and Roles

More questions from this topic