Examkin

Question

Difficulty: HardIAM Policies and Roles

A developer is implementing a serverless application where an AWS Lambda function in Account A (111122223333111122223333) needs to access a DynamoDB table in Account B (444455556666444455556666). The developer creates an IAM role named `CrossAccountDynamoDBRole` in Account B that has the required permissions to access the DynamoDB table. The Lambda function is configured with an execution role named `arn:aws:iam::111122223333:role/LambdaExecutionRole` and runs code that calls the `AssumeRole` API of AWS Security Token Service (STS) to assume `CrossAccountDynamoDBRole`.

However, when the Lambda function runs, the `AssumeRole` call fails with an `AccessDenied` error. The developer reviews the trust policy of `CrossAccountDynamoDBRole` in Account B:

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

Which modification to the trust policy of `CrossAccountDynamoDBRole` in Account B will resolve this error?

  1. A
    Keep the service principal as `lambda.amazonaws.com` but add a condition to restrict the `aws:SourceArn` to the Lambda function's ARN:

    "Condition": {
    "ArnEquals": {
    "aws:SourceArn": "arn:aws:lambda:us-east-1:111122223333:function:my-function"
    }
    }
  2. Update the `Principal` block to reference the ARN of the Lambda function's IAM execution role in Account A:

    "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/LambdaExecutionRole"
    }
    Answer
  3. C
    Update the `Principal` block to trust Account A's root user, but change the policy's `Action` from `sts:AssumeRole` to `sts:AssumeRoleWithWebIdentity`:

    "Principal": {
    "AWS": "arn:aws:iam::111122223333:root"
    },
    "Action": "sts:AssumeRoleWithWebIdentity"
  4. D
    Change the `Principal` service to the DynamoDB service principal so that the table can receive requests directly from the role:

    "Principal": {
    "Service": "dynamodb.amazonaws.com"
    }

Answer

Update the Principal block of the target role's trust policy in Account B to trust the Lambda execution role's ARN in Account A.
The correct option is correct because when Lambda code runs, the AWS SDK client initiates API calls signed with the function's execution role credentials. To assume the cross-account role, the trust policy in Account B must specify the caller's IAM execution role ARN (`arn:aws:iam::111122223333:role/LambdaExecutionRole`) as the principal in the trust relationship statement.

Step-by-Step Solution

1
Analyze the IAM configuration and identify the entity calling the `AssumeRole` API.
The Lambda function uses its execution role (`arn:aws:iam::111122223333:role/LambdaExecutionRole`) to sign and execute AWS API requests, including `sts:AssumeRole`.
When a function runs, it uses the temporary credentials of its execution role to authorize all actions.
2
Inspect the trust policy of the target role `CrossAccountDynamoDBRole` in Account B.
The current trust policy only allows the service principal `lambda.amazonaws.com` to assume the role.
This configuration is for allowing the Lambda service to assume an execution role, not for allowing an assumed role to call another role.
3
Update the trust policy of the target role to authorize the correct principal.
The principal is changed to `"AWS": "arn:aws:iam::111122223333:role/LambdaExecutionRole"`.
This establishes a cross-account trust relationship allowing the execution role in Account A to assume the role in Account B.

Key Concept

Cross-Account IAM Roles and Service vs. AWS Principals
Rate this question

Topics

IAM Policies and Roles

More questions from this topic