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

- 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

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

SCP does not grant permission it's a guardrail (it's a deny policy always) so the option is wrongly worded!

✅C. Configure the identity-based policy on the user in Account A to allow the action. The IAM user in Account A needs permission to assume the role in Account B. This is done by attaching an identity-based policy that allows the sts:AssumeRole action on the target role in Account B. ✅ E. Configure the trust policy on the target role in Account B to allow the action. The IAM role in Account B must trust the user from Account A. This is done by adding a trust policy to the role, specifying Account A’s user or a specific IAM principal from Account A. ✅ A. Configure the SCP for Account A to allow the action. Service Control Policies (SCPs) act as guardrails at the AWS Organizations level. If there is an SCP that denies cross-account role assumption, it must be modified to allow sts:AssumeRole for Account A.

IAM Role does not support Resource-Based Policy, we should apply Trust Policy instead.

Option A (Configure the SCP for Account A to allow the action) is correct because the SCP would need to be configured to allow the assumption of roles from one account to another. Option C (Configure the identity-based policy on the user in Account A to allow the action) is also correct, as it would define the permissions that the IAM user has within their own account. And finally, Option E (Configure the trust policy on the target role in Account B to allow the action) is necessary because it specifies the external identity provider and the roles that can be assumed by users from that identity provider.

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.