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

Right answer is D. An SCP at a lower level can't add a permission after it is blocked by an SCP at a higher level. SCPs can only filter; they never add permissions. SO you need to create a new OU for the new account assign an SCP, and move the root SCP to Production OU. Then move the new account to production OU when AWS config is done.

Answer: D. Not A: too much overhead and maintenance. Not B: SCP at Root will still deny Config to the temporary OU. Not C: Too much overhead to create allow list.

B is correct answer. Question states "Once onboarded, the administrators of the new business unit discovered that they are not able to update existing AWS Config rules to meet the company’s policies." -> Hence, it's TEMPORARY onboarding issue, which is resolved by temporary OU. Once resolved, we are good to move to Production (original) OU. Also, question states that "allow administrators to make changes and continue to enforce the current policies without introducing additional long-term maintenance" --> H/ence, we don't want to change SCP from Root so that later on we can onboard as many OU as we need

By moving the restrictive SCP from root > Production OU, you free the Onboarding OU from that restriction. Onboarding OU can have a permissive SCP that allows AWS Config actions. Once setup is done, move the account to Production OU where root-level restrictions (now at Production OU) resume. Preserves existing policies, avoids long-term complexity.

Explanation: The company uses deny list SCPs at the root level, which means all accounts, including newly added ones, are subject to those restrictions. The new account needs temporary access to AWS Config actions to update rules, but the current SCPs are blocking that. Option B allows for a temporary and isolated change: By creating a separate Onboarding OU, you can apply a more permissive SCP just for that OU. Once the necessary AWS Config changes are made, the account can be moved to the Production OU, where the standard restrictions apply. This approach avoids modifying root-level SCPs or converting the entire policy model, which would introduce long-term maintenance overhead.

Answer: D But it needs to say deny list policy is moved back to the root level, after AWS config process.

Here's my take, and let me know if its wrong. D is wrong because it suggests moving the Root SCP. This is extremely dangerous and generally not advisable, but it also implies that the Root SCP disallows AWS Config changes, which would imply previous administrators also could not change AWS Config. This is an assumption, so I would go with B.

B A: Removing root-level SCPs would loosen security controls across all accounts and increase the risk of misconfiguration. Also, using Service Catalog doesn’t solve the issue of updating existing AWS Config rules. C: Converting from deny list to allow list SCPs across the whole organization is a major change, hard to manage, and could unintentionally block many services. It's not recommended unless you’re planning a full org-wide shift. D: Moving the root SCP to the Production OU changes the scope of restrictions — the root SCP applies to all accounts by default. Moving it to a child OU limits its coverage, which introduces long-term security and management risks.

the question test knowledge about allow /denied inherit. all ou under root with 'deny' can't allow. So B is fail. C , D is correct but D is less operation.

For a permission to be allowed for a specific account, there must be an explicit Allow statement at every level from the root through each OU in the direct path to the account (including the target account itself). https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html

Yes, in option D, the solution is to create a temporary OU named Onboarding for the new account. By creating a new OU for the new account, it allows for a new set of permissions and policies to be applied to this account, separate from the existing Production OU. Once the new OU is created, an SCP is applied to it to allow AWS Config actions. This SCP allows the new account to make necessary adjustments to AWS Config without being blocked by the existing policies at the root level of the organization. Then, the root SCP that is blocking these actions is moved to the Production OU, where it will continue to block these actions for all other accounts that are members of the Production OU. Finally, once the necessary adjustments are made, the new account can be moved to the Production OU, where it will be subject to the existing policies and restrictions.

The best option to allow administrators to make changes and continue to enforce the current policies without introducing additional long-term maintenance would be option D: D. Create a temporary OU named Onboarding for the new account. Apply an SCP to the Onboarding OU to allow AWS Config actions. Move the organization’s root SCP to the Production OU. Move the new account to the Production OU when adjustments to AWS Config are complete. This solution involves creating a temporary OU named Onboarding for the new account and applying an SCP to the Onboarding OU that allows AWS Config actions. The organization's root SCP should be moved to the Production OU, and the new account should be moved to the Production OU when the adjustments to AWS Config are complete. This approach allows the administrators of the new account to make changes to AWS Config rules while maintaining the current policies in the Production OU.

Please note Question Constraint: Which option will allow administrators to make changes and continue to enforce the current policies without introducing additional long-term maintenance? Strategies for using SCPs You can configure the service control policies (SCPs) in your organization to work as either of the following: A deny list – actions are allowed by default, and you specify what services and actions are prohibited An allow list – actions are prohibited by default, and you specify what services and actions are allowed.

D: is not correct, because removing the root SCPs on the production OU means removing all the security rules on the services preventing changes, including changes to the AWS Config rules. and depending on the scenario this will be a security hole for production. Don't forget that the aim is to introduce the new AWS account into the Production OU with the same configurations and restrictions as the accounts that are already there. So thanks to the temporary OU on which we have an SCP that authorises actions on AWS Config, we just need to modify the configuration of the new account so that it matches the production requirements. Once the configuration requirements have been met, we move the new account into the production OU.

Chosen D. B is not correct because root having explicit deny will override any explicit allow in its child OU even if allowance is given. Unless I keep Onboarding account under a parent where there is not explicit deny for Config service, Onboarding account can not configure. So, need to move the explicit deny from root account to production account and then keep onboarding account under root.

This question is ambiguous. If D was formulated like this: "D. Create a temporary OU named Onboarding for the new account. Apply a Config non-blocking SCP to the Onboarding OU to allow AWS Config actions. Apply the organization’s root SCP to the Production OU instead of to the root OU. Move the new account to the Production OU when adjustments to AWS Config are complete." Then D would be a viable option. However, it isn't, and even if it were, it fails to mention the crucial fact that the Root OU always must have an SCP, which in this case must Allow everything. For someone with some experience this is a given, but as it isn't mentioned, I'd go for B. However, AWS should reformulate the question and the answers. They are really subpar.

I don't like any of the answers to be honest. Let's look at D since that's the one most people think is right. The problem with D is that you can't detach the last SCP associated with a root container, OU, or account. There has to be at least one. So, removing the SCP from the root and moving it down to the Production OU is a no-go unless you add a permissable SCP to the root. Check the section on detaching here: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_attach.html The only way B is correct is if the reason the new admins don't have access to Config is not because Config is in the Deny List, but because the management account doesn't have the appropriate IAM Policy giving PERMISSION to Config. You need both an IAM Policy and a permissable SCP to have permission and access to a service. But, why wasn't IAM Policy mentioned in choice B. Clearly, without that information, choice B also is not right.