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.)
To allow an IAM user in Account A to assume a role in Account B, several steps are necessary: First, the identity-based policy on the user in Account A must be configured to allow the action, as this policy controls what the users in Account A can do. Second, the trust policy on the role in Account B must be configured to trust the IAM user from Account A to assume the role. This configuration establishes the relationship that allows the user to assume the role. Lastly, as the company uses AWS Organizations with SCPs, the SCP for Account A must be configured to allow this action. SCPs act at the organizational unit and account level to ensure that nothing in the hierarchy explicitly denies the required action.
Answer: C, E, F Attach a policy to the IAM user in Account A > Trust Policy in Account B > GetSessionToken API operation
F is wrong, you cannot use GetSessionToken to configure session policy. You can pass a single inline session policy programmatically by using the policy parameter with the AssumeRole, AssumeRoleWithSAML, AssumeRoleWithWebIdentity, and GetFederationToken API operations. ACE is correct answer.
- C) Attach an identity-based policy to the IAM user in Account A (allowed to assume IAM role in Acccount B) - E) Configure the trust policy on the target role in Account B (accountID of the trusted account which is Account A) - B) Configure a resource-based policy which allows certain actions on resources which reside in Account B) reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html
IAM roles and resource-based policies delegate access across accounts only within a single partition. For example, assume that you have an account in US West (N. California) in the standard aws partition. You also have an account in China (Beijing) in the aws-cn partition. You can't use an Amazon S3 resource-based policy in your account in China (Beijing) to allow access for users in your standard aws account. So B can't be answer.
Option F is not applicable because session policies are intended to be used in conjunction with the AssumeRole operation to further refine permissions for the assumed role session, rather than being associated with the GetSessionToken operation. They are optional policies that you can pass when assuming a role to further restrict permissions for that session, not for enabling the role assumption itself. Company uses SCP policies so if there has to be an SCP in place
Fun fact - an IAM role trust policy is in fact a resource policy. So just like Service Control Policies (SCPs) are a guardrail for IAM permission policies, AWS will soon announce Resource Control Policies (RCPs) which will be a guardrail for resource policies, like IAM trust policies. Neat, eh? Check out https://www.zeuscloud.io/post/an-aws-iam-wishlist
F Cannot be the answer. https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html --- The temporary security credentials created by AssumeRole can be used to make API calls to any AWS service with the following exception: You cannot call the AWS STS GetFederationToken or GetSessionToken API operations. ---
Options B, D, and F are not directly relevant to enabling cross-account role assumption in this context: B. Resource-based policies are not typically configured on IAM users but on resources like S3 buckets or KMS keys. D. The identity-based policy on a user in Account B is irrelevant since the action is being initiated by a user in Account A. F. Session policies are used to pass permissions when you create a session for a role or federated user. The GetSessionToken API operation is used with IAM users to create a session with MFA, not for assuming roles across accounts. Therefore, the correct combination of steps is A, C, and E.
A: if "allow" is taken to mean "not deny" B: Resource policies have nothing to do with this C: required D: The user is in account A, not in account B, so this is out E: required F: Not how things are done when assuming roles
ACE is correct answer. F is wrong, you cannot use GetSessionToken to configure session policy. You can pass a single inline session policy programmatically by using the policy parameter with the AssumeRole, AssumeRoleWithSAML, AssumeRoleWithWebIdentity, and GetFederationToken API operations.
you generally do not need to modify the Service Control Policies (SCPs) to allow one account's IAM users to assume roles in another account, as long as the SCPs do not explicitly deny the required actions (like sts:AssumeRole).
BCE - SCP is not required here & used for deny not for allow
The key point here is "The company's current security configuration for the account architecture includes SCPs," so if SCPs are in place, the SCP in the account A has to be configured to allow the action.
ACE for me
B, C, E are correct answers.
A: By default, an account is created and added to an AWS Organization inherits a "FullAWSAccess" policy, we don't have to "allow" the action
E Trust policy in B D Identity-based policy on the ROLE in Account B to allow the action (I think typo in question) C Configure the identity-based policy on the user in Account A to allow the action. Just try it in AWS env.
Answer is BCE. SCPs are not used for ALLOW actions but for DENY actions at Org level.
Answer: CEF Option A incorrect coz, Service Control Policies (SCPs) are used to set permission guardrails for the entire organization or organizational units. They are not directly related to allowing IAM users to assume roles in other accounts.