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.

For all the answers provided, which answer is mostly correct, the revealed solution or most voted?

Option B. If a "Deny" list SCP is applied at the root of the organization to restrict access to a service, and then a new SCP is created at a lower level (e.g., an Organizational Unit or OU) to "Allow" access to that restricted service, the permissions are cumulative. So, if an account is placed under the Test OU, it will inherit the permissions from both SCPs. Since the "Allow" SCP at the Test OU level overrides the "Deny" SCP at the root level, the account under the Test OU will effectively have access to the restricted service. This is because SCPs are evaluated hierarchically, with SCPs at higher levels in the organizational structure being evaluated first, followed by SCPs at lower levels. When there are conflicting SCPs, the most permissive policy (i.e., the one that allows access) takes precedence.

Option D: The link doesn't give you a full explanation on why "D" is correct however it does check all the boxes https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/transitional-ou.html

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.

The question itself is a bit confusing. It says "Deny List in the root", which should be understood as Deny List Architecture, but can be misinterpreted as "Allow List Architecture with attached Deny List in the root that explicitly deny AWS Config". Since AWS Config on Production OU is denied, an appropriate SCP is attached to it, which explicitly denies AWS Config. Thus, the root has FullAWSAccess SCP attached to it. That's why we just need to create Onboarding OU with no explicit deny of AWS Config and that's it. So the correct answer is truly correct, but the question is a bit tricky and easy to misunderstand.

option D - how creating new OU will solve the problem? the root SCP will deny it , isnt? also why do we need to Move the organization’s root SCP to the Production OU ?

Answer D is the answer most accurate. it would be good that add another statement to say" Add awsFullAccess SCP policy on the root and move the deny list scp policy from root to production OU"

Option A - This option actually rolls out AWS Config across the company which is exactly the opposite of what they are doing Option B - This option does not work because AWS Config will still be restricted despite the Allow SCP in Onboarding because of the Deny SCP in the root of the organization Option C - This option allows access to AWS Config in the new business unit and restricts access to everything else. However, the SCP will require regular updates to add new AWS services Option D - This option applies the correct level of access to each OU without needing updates: Onboarding gets access to AWS Config, Production does not and FullAWSAccess is established at the root after the company's Deny SCP is moved.

SCP at root must be moved to Production OU to prevent it from being applied to onboarded account.

This was not easy for me due to wording, however here is my take: Not A. here we permanently remove SCPs that limit access to AWS Config, while we are requested to continue to enforce the current policies Not B. temporary OU and related SCP that allows AWS Config are nested under root where SCPs that limit access to AWS Config are applied. As SCP can only remove permission and not add, this will not work Not C. converting deny list into allow list here is not beneficial also temporarily apply SCP allowing AWS Config does not meet the request to avoid additional long-term maintenance. Thus D does the job.

D is correct

The Root is not an OU. It is a container for the management account, and for all OUs and accounts in your organization. Conceptually, the Root contains all of the OUs. It cannot be deleted. You cannot govern enrolled accounts at the Root level within AWS Control Tower. Instead, govern enrolled accounts within your OUs. The SCP don't apply at root OU. This will impact production as when you move SCP from root to Production you are changing SCP for all OU which are part of it. Will customer allow to change existing production SCP to on board a new. I don't think D is correct

B is horribly wrong. Correct answer must be D.

need to get rid of deny in root scp