Answer: C, E, F Attach a policy to the IAM user in Account A > Trust Policy in Account B > GetSessionToken API operation

- 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

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

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.

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

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.

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. ---

F is wrong. 'You can create role session and pass session policies programmatically using the AssumeRole, AssumeRoleWithSAML, or AssumeRoleWithWebIdentity API operations' https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session

BCE Here are the basic steps: Create an IAM role in the target account that will be assumed. This role should have the necessary permissions for the actions that will be performed. Attach a trust policy to the role that allows the source account to assume it. The trust policy specifies the principals (accounts, users, roles) that are trusted to assume the role. It would list the source account as a trusted entity. When a user in the source account wants to assume the role, they call the aws sts assume-role CLI command or AssumeRole API action. They specify the ARN of the role in the target account. AWS security credentials will be returned that can be used by the source account user to make API calls and access resources as permitted by the permissions of the assumed role in the target account.

A,C,E -ANS 1. Configure the SCP for Account A to allow the action. 2. Configure the identity-based policy on the user in Account A to allow the action. 3. Configure the trust policy on the target role in Account B to allow the action. Here's a breakdown of why these steps are necessary: SCP (Service Control Policy): It acts as a guardrail, enforcing a baseline of permissions across accounts. It must explicitly allow cross-account role assumption for it to be possible. Identity-Based Policy on User in Account A: This policy grants permissions directly to the IAM user. It must include the sts:AssumeRole action to allow the user to assume the role in Account B. Trust Policy on Target Role in Account B: It specifies which entities are trusted to assume the role. It must include the principal (IAM user or account) from Account A in its trust policy to permit the assumption.

A - SCP's by default deny so you must have an explicit allow. Often that is done with the FullAwsAccess, but this answer fits most (see reasoning for other answers) B - Resource-based policies are attached to a resources, and not IAM user/group/role so not applicable here C - The IAM user needs the policy to do sts:AssumeRole, so this one is needed D - The IAM role in account B only needs permissions to access resources in account B. Also, the answer talks about "user" and there is no user in account B (or at least not in the scope of the question) E - The IAM role in account B needs to trust the action of the user in account A, so this is needed as well. F - GetSessionToken is used to get a session for an IAM user. This users is in account A and we don't need a session in account A, but we need an assumerole to account B. Therefore this is not needed. If the question talks about MFA then this might come into play.