SAP-C02 · Question #576
A company is using AWS Organizations with a multi-account architecture. The company's current security configuration for the account architecture includes SCPs, resource-based policies…
The correct answer is C. Configure the identity-based policy on the user in Account A to allow the action. E. Configure the trust policy on the target role in Account B to allow the action. F. Configure the session policy to allow the action and to be passed programmatically by the. To allow an IAM user in Account A to assume a role in Account B, the permissions must be explicitly granted at multiple levels: the user's identity policy, the target role's trust policy, and optionally by a session policy during assumption.
Question
A company is using AWS Organizations with a multi-account architecture. The company's current security configuration for the account architecture includes SCPs, resource-based policies, identity-based policies, trust policies, and session policies. A solutions architect needs to allow an IAM user in Account A to assume a role in Account B. Which combination of steps must the solutions architect take to meet this requirement? (Choose three.)
Options
- AConfigure the SCP for Account A to allow the action.
- BConfigure the resource-based policies to allow the action.
- CConfigure the identity-based policy on the user in Account A to allow the action.
- DConfigure the identity-based policy on the user in Account B to allow the action.
- EConfigure the trust policy on the target role in Account B to allow the action.
- FConfigure the session policy to allow the action and to be passed programmatically by the
How the community answered
(26 responses)- A8% (2)
- B12% (3)
- C62% (16)
- D19% (5)
Why each option
To allow an IAM user in Account A to assume a role in Account B, the permissions must be explicitly granted at multiple levels: the user's identity policy, the target role's trust policy, and optionally by a session policy during assumption.
While SCPs can *deny* actions, they don't *grant* them. If an SCP for Account A *denied* sts:AssumeRole, it would prevent the action, but it's not a step that *must* be taken to *allow* it; rather, the absence of a denial is required.
Resource-based policies are generally used for resources like S3 buckets or SQS queues, and while a trust policy is a type of resource policy for roles, 'resource-based policies' as a general term is less specific than the explicit need for a *trust policy* on the role.
The IAM user in Account A must have an identity-based policy that explicitly allows the sts:AssumeRole action to assume the role in Account B.
The IAM user requiring the action is in Account A, so configuring an identity-based policy on a user in Account B is irrelevant to granting the Account A user permission to assume a role.
The target IAM role in Account B must have a trust policy that permits the IAM user from Account A (or Account A itself) to assume it.
If a session policy is used during the sts:AssumeRole API call, it acts as an additional filter and must also allow the specific actions that the user will perform after assuming the role.
Concept tested: Cross-Account Role Assumption Permissions
Source: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_permissions-to-switch.html
Community Discussion
No community discussion yet for this question.