A Lambda function in account 111111111111 saves orders to a DynamoDB table in account 222222222222.
The security team for account 222222222222 requires that the function reaches the table only through an IAM role that they own and control, and no long-term credentials may be stored anywhere. The function's code uses the AWS SDK.
Which TWO steps are required? (Choose two.)
Choose two answers.
AA. In account 222222222222, create a role with write access to the table and a trust policy that names the function's execution role.
BB. Attach a resource-based policy to the table that allows the function's execution role to call dynamodb:PutItem.
CC. Add a statement to the function's resource-based policy that allows the role in account 222222222222 to invoke the function.
DD. Allow sts:AssumeRole on the role's ARN in the execution role, and have the code call AssumeRole to get temporary credentials.
EE. Create an IAM user in account 222222222222 with table access, and keep its access key in AWS Secrets Manager for the function.
Show the answer and explanation
Answers: A, D
A. Right: Correct. The role in the table's account holds the DynamoDB permissions, and its trust policy decides who may assume it. Naming the execution role as the trusted principal lets the function, and nothing else, take on the role. Learn more: Cross-account access with IAM roles (opens in a new tab)
C. Wrong: A function's resource-based policy controls who can invoke the function, not what the function can reach. It does nothing to give the function access to a table in another account. Learn more: Lambda resource-based policies (opens in a new tab)
D. Right: Correct. The caller's own identity policy must also allow sts:AssumeRole on the target role, because a trust policy alone is not enough. The SDK then uses the temporary credentials from AssumeRole for DynamoDB calls. Learn more: Cross-account access with IAM roles (opens in a new tab)
E. Wrong: An IAM user's access key is a long-term credential, which the requirement rules out, even when stored in Secrets Manager. It also bypasses the role that the security team wants to manage. Temporary credentials from AssumeRole are the intended approach.
Explanation
Cross-account role access needs both sides: the role in the table's account must trust the function's execution role, and the execution role must be allowed to call sts:AssumeRole on that role. The code then uses the temporary credentials. A table resource policy or an IAM user's keys would reach the table but not through a role the table owner controls without stored secrets.
Both sides are needed: the role trusts the execution role, and the execution role may call sts:AssumeRole on it.
Want more on IAM roles, policies and STS? The 5 full-length practice sets have 15 more IAM roles, policies and STS questions, 390 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →