Question

Difficulty: HardIAM Policies and Roles

A developer is implementing an AWS Lambda function in Account A (111111111111111111111111) that needs to retrieve database credentials stored as a secure parameter in the Systems Manager Parameter Store in Account B (222222222222222222222222). The parameter is encrypted using an AWS KMS customer managed key (CMK) in Account B. The developer intends to use the AWS Security Token Service (STS) to assume an IAM role named `DbConfigReaderRole` in Account B.

The Lambda function is associated with an execution role named `LambdaExecutionRole` in Account A.

Which of the following configuration steps must be performed to allow the Lambda function to retrieve the configuration parameter? (Select TWO.)

  1. In Account B, configure the trust policy for `DbConfigReaderRole` to allow the principal `arn:aws:iam::111111111111:role/LambdaExecutionRole` to perform the `sts:AssumeRole` action.Answer
  2. In Account A, attach a policy to `LambdaExecutionRole` that grants `sts:AssumeRole` permissions on the resource `arn:aws:iam::222222222222:role/DbConfigReaderRole`.Answer
  3. C
    In Account B, attach an identity-based permission policy to `DbConfigReaderRole` that grants `sts:AssumeRole` permissions to the principal `arn:aws:iam::111111111111:role/LambdaExecutionRole`.
  4. D
    In the Lambda function code, configure the AWS SDK client to initialize credentials by hardcoding the access keys of an IAM user in Account B that has permissions to read the parameter.
  5. E
    In Account B, attach a resource-based policy directly to the Systems Manager Parameter that grants `ssm:GetParameter` permissions to the `LambdaExecutionRole` in Account A.

Answer

The configuration requires adding the calling role as a trusted principal in the trust policy of the target role in Account B, and granting permission to assume the target role in the identity-based policy of the caller's role in Account A.
For cross-account access via STS, two distinct components are required: the target role's trust policy must list the source principal as a trusted entity, and the source identity's permissions policy must permit the call to assume the target role.

Step-by-Step Solution

1
Identify the cross-account trust requirement.
The target role `DbConfigReaderRole` in Account B (222222222222222222222222) must explicitly trust the Lambda execution role in Account A (111111111111111111111111) via its trust policy.
Without this trust relationship, STS will deny the assume role request from Account A's principal.
2
Identify the delegation permission requirement.
The source execution role `LambdaExecutionRole` in Account A must be granted permission to perform the `sts:AssumeRole` action on the target role's ARN in Account B.
By default, IAM execution roles do not have permission to assume arbitrary external roles; this must be explicitly allowed.
3
Differentiate trust policies from identity-based policies and resource-based policies.
Confirm that trust relationships are defined in trust policies (not identity-based policies) and that Systems Manager Parameter Store does not support resource policies.
This rules out the incorrect options that attempt to configure trust in permissions policies or use non-existent parameter resource policies.

Key Concept

IAM Policies and Roles
Estimated Time:2m 0s
Rate this question