Question

Difficulty: HardIAM Policies and Roles

A developer is configuring a serverless application where an AWS Lambda function in Account A (111111111111111111111111) needs to ingest records from an Amazon Kinesis data stream located in Account B (222222222222222222222222). The Lambda function runs under the execution role `arn:aws:iam::111111111111:role/LambdaExecutionRole`.

To accomplish this, the developer creates a role named `CrossAccountStreamReader` in Account B with the following permission policy attached:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kinesis:DescribeStream",
"kinesis:GetShardIterator",
"kinesis:GetRecords"
],
"Resource": "arn:aws:kinesis:us-east-1:222222222222:stream/DataIngestStream"
}
]
}

The Lambda function code is written to assume this role using the AWS Security Token Service (STS) before calling Kinesis APIs. However, when executing the function, the developer receives an `AccessDenied` error during the STS `AssumeRole` API call.

Which TWO configurations are required to resolve this error? (Select TWO.)

  1. Attach an IAM policy to `LambdaExecutionRole` in Account A that allows the `sts:AssumeRole` action on `arn:aws:iam::222222222222:role/CrossAccountStreamReader`.Answer
  2. Configure the trust policy of the `CrossAccountStreamReader` role in Account B to allow the `sts:AssumeRole` action with the Principal set to `arn:aws:iam::111111111111:role/LambdaExecutionRole`.Answer
  3. C
    Configure the trust policy of `LambdaExecutionRole` in Account A to allow the `sts:AssumeRole` action with the Principal set to `arn:aws:iam::222222222222:role/CrossAccountStreamReader`.
  4. D
    Attach a resource-based policy to the Kinesis data stream in Account B that grants the `kinesis:GetRecords` action to the principal `arn:aws:iam::111111111111:role/LambdaExecutionRole`.
  5. E
    Attach an IAM policy to `LambdaExecutionRole` in Account A that grants `kinesis:GetRecords` permissions on the resource `arn:aws:kinesis:us-east-1:222222222222:stream/DataIngestStream`.

Answer

To resolve the issue, the developer must attach an IAM policy to the Lambda execution role in Account A that allows the `sts:AssumeRole` action on the target cross-account role, and configure the trust policy of the cross-account role in Account B to trust the Lambda execution role.
To successfully execute a cross-account API call using STS assume role, the permission must be allowed on both sides. The calling identity in the source account (the Lambda execution role) must have an identity-based permission policy allowing it to call the `sts:AssumeRole` action on the target role. Concurrently, the target role in the destination account must have a trust policy (resource-based policy on the role itself) that lists the caller's ARN as a trusted principal.

Step-by-Step Solution

1
Grant permission to the Lambda function's execution role to assume the target role.
Create and attach an IAM policy to the execution role in Account A allowing the `sts:AssumeRole` action on the target role ARN (`arn:aws:iam::222222222222:role/CrossAccountStreamReader`).
By default, IAM entities do not have permission to assume roles, especially across accounts. This permission must be explicitly granted on the source side.
2
Establish the trust relationship on the target role in the destination account.
Edit the trust policy of the cross-account role in Account B to declare the execution role ARN (`arn:aws:iam::111111111111:role/LambdaExecutionRole`) as a trusted Principal.
An IAM role must explicitly define who is authorized to assume it. This prevents unauthorized identities from gaining access to resources in Account B.

Key Concept

Cross-account access via IAM roles requires a two-way authorization configuration: the calling identity must have permission to assume the role, and the target role's trust policy must trust the calling identity. Additionally, Amazon Kinesis Data Streams do not support resource-based policies, necessitating the use of cross-account IAM roles for this scenario.
Rate this question