Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 309 discussion

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

Revising my earlier vote to ACE, agree that resource based policies is not required. SCP though apply restriction rather than allow, reviewing it to ensure it doesn't block this access does make sense.

Correct Options: A. Configure the SCP for Account A to allow the action. 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. Explanation of Incorrect Options: B. Configure the resource-based policies to allow the action: Resource-based policies are typically used to control access to specific resources like S3 buckets, not for cross-account role assumption. D. Configure the identity-based policy on the user in Account B to allow the action: The identity-based policy for users in Account B is not relevant here, as the user in Account A needs permission to assume the role.

SCPs are not necessary at all here...

the ask is steps to "ASSUME A ROLE" not to "access the resource" . so option B and F are wrong as with A, C, E I can still assume the role regardless of the configuration of resource policy and session policy who can still deny access to the resource

To allow an IAM user in Account A to assume a role in Account B - we only need identity-based , resource-based and trust policies. Session policy and SCP not required.

A (SCP) is more relevant than B (resource-based policies) because, while SCPs are not granting permissions, they could potentially restrict actions. Therefore, ensuring that the SCP in Account A (and Account B) does not block the necessary sts:AssumeRole action is important. B (resource-based policies) isn't relevant for the cross-account role assumption in this context.

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.

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

Answer is BCE. SCPs are not used for ALLOW actions but for DENY actions at Org level.

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.