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?
- AAdd a Principal block specifying lambda.amazonaws.com directly to the identity-based permission policy attached to the Lambda execution role in Account A.
- BModify 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.
- 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.Cevap
- DConfigure a Cognito Identity Pool in Account B to authenticate the Lambda function and obtain temporary AWS credentials for DynamoDB.