How to Let a New Account Update AWS Config Under Root SCPs?
Answer
Correct answer: D — Move the root deny-list SCP to the Production OU, attach an AWS Config allow SCP to a temporary Onboarding OU, then move the account back.
A company uses AWS Organizations with a single OU named Production to manage multiple accounts. All accounts are members of the Production OU. Administrators use deny list SCPs in the root of the organization to manage access to restricted services. The company recently acquired a new business unit and invited the new unit’s existing AWS account to the organization. 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. Which option will allow administrators to make changes and continue to enforce the current policies without introducing additional long-term maintenance?
Community Insight
Tests SCP inheritance and deny precedence: root deny-list SCPs cannot be overridden by an allow SCP in a child OU, so the fix must move the deny policy away from the onboarding account.
AWS Organizations SCPs at the root override lower-level allows, so a newly acquired account cannot update AWS Config until the root deny-list SCP is relocated. The page explains why option D temporarily isolates the account in an Onboarding OU and then restores Production enforcement.
Many choose B, assuming an allow SCP on a temporary OU overrides the root deny-list SCP; SCPs only filter permissions and an explicit deny at the root still wins.
Community Discussion (73 comments)
rn5357
👍 1
Selected: D
If a lower-level policy can override a higher-level deny policy, how can you ensure every account complies with the company's policy?
f343e6a
👍 1
Selected: B
Answer is B: Temporary OU (Onboarding) allows for a safe, isolated adjustment period Allow SCP at Onboarding OU level overrides the deny list at root (SCP evaluation logic) Root SCPs remain untouched → current policies stay in force org-wide After onboarding, move to Production OU → account falls back under root deny list SCPs Zero long-term maintenance — this is a one-time onboarding pattern
bb_08
👍 1
Selected: B
Right answer should be B
satya89
👍 1
Selected: B
Option A involves removing organization-wide SCPs, which would create a security risk across all accounts. Option C suggests converting from deny lists to allow lists, which would be a significant change to the organization's security model and potentially disruptive. Option D involves moving the root SCP to the Production OU, which could leave the organization vulnerable at the root level and create inconsistent policy application. Therefore, Option B represents the best solution that allows temporary access for the required changes while maintaining the organization's security posture with minimal long-term maintenance requirements.
hess
👍 1
Selected: D
D is correct, as the root policy needs to be moved
pkr3003
👍 2
Selected: B
🧩 Why Option B Works (Official Logic) AWS documentation (see Organizing AWS Accounts ) explicitly recommends using OUs for different life cycle or operational stages, such as sandbox, onboarding, production, etc.: “You can group accounts into OUs that share common requirements. For example, you might have an OU for sandbox accounts that have fewer restrictions.” Therefore: Creating an Onboarding OU with a more permissive SCP allows temporary relaxation of restrictions (like AWS Config updates). Once configuration is complete, you can move the account back under the Production OU, where the standard deny-list SCPs apply. This method avoids altering the root-level SCPs, thus keeping governance intact for existing accounts. It also avoids additional long-term maintenance—no permanent policy changes, just a temporary OU for onboarding.
EzKkk
👍 1
Selected: C
1, Root uses deny list 2, New accounts can't update Config 1 + 2 => Root is denying Config => Migrate to Root use allow so we can update Config => Onboard accounts => C
nayeh
👍 5
Selected: B
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
princajen
👍 1
Selected: D
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.
MasterVivek
👍 2
Selected: B
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.
kvin97
👍 1
Selected: D
Answer: D But it needs to say deny list policy is moved back to the root level, after AWS config process.
calcinator423
👍 1
Selected: B
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.
MarkM1
👍 1
Selected: 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.
Cpso
👍 1
Selected: C
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.
hspc_
👍 2
Selected: D
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
masetromain
👍 5
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.
masetromain
👍 1
This approach is the correct solution because it allows the new account to make necessary adjustments to AWS Config while still adhering to the company's policies, and it does not introduce additional long-term maintenance. The new account will be only in the new OU temporarily, and the SCP blocking AWS Config actions will only be in the root temporarily.
c73bf38
👍 1
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.
Ajani
👍 1
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.
sebnzogang
👍 6
Selected: B
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.
victorHugo
👍 5
" All accounts are members of the Production OU", therefore we don't need the SCP in root.
dimitry_khan_arc
👍 3
Selected: D
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.
Dgix
👍 2
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.
JOKERO
👍 3
AWS Config will still be restricted despite the Allow SCP in Onboarding because of the Deny SCP in the root of the organization
fartosh
👍 1
This sentence: "Apply the organization’s root SCP to the Production OU instead of to the root OU." solves the issue you mentioned. You can safely move this SCP as the question states that all AWS accounts are in Production OU.
awsylum
👍 1
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.
awsylum
👍 1
The question mentioned a Deny List architecture, but it didn't specifically say Config was in the Deny List. We are assuming that, which could lead to the wrong answer. Unfortunately, I'm not satisfied with any of the answers. Hopefully, this is a question that would be thrown out from the exam. LOL.
awsylum
👍 1
Also, even if you could remove a root SCP, you would never do that in production. You would never just flat remove an SCP with a Deny list just to give one account access to some service. Even if it's temporary, that's a fatal mistake as the other accounts will not be restricted from certain services they shouldn't have access to.
soulation
👍 1
Before Onboarding OU, this organization only had 1 OU (Production). So moving the SCP from root to Production OU doesn't affect other existing accounts.
ninomfr64
👍 2
Selected: D
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.
atirado
👍 1
Selected: C
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.
DmitriKonnovNN
👍 1
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.
Mikep12357
👍 3
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.
pravinb
👍 1
Selected: D
D is the best match !
amministrazione
👍 1
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.
niroop893
👍 1
Answer: D
TonytheTiger
👍 2
Selected: D
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
kobi44
👍 1
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 ?
GabrielShiao
👍 1
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"
cgsoft
👍 1
Selected: D
SCP at root must be moved to Production OU to prevent it from being applied to onboarded account.
abeb
👍 1
D is correct
swadeey
👍 2
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
soulation
👍 1
The question said there's only 1 OU.
jainparag1
👍 1
B is horribly wrong. Correct answer must be D.
severlight
👍 2
Selected: D
need to get rid of deny in root scp
Sandeep_B
👍 2
Option D looks to be correct answer. Can anyone please confirm if you have got this question in the exam and cleared it..
ansgohar
👍 2
Selected: D
D. An SCP at a lower level can't add a permission after it is blocked by an SCP
autobahn
👍 3
So which is the correct answer B or D? Why is the portal saying it as "B" though many of them think it is D?
technosavvy
👍 2
Option D: This option would allow administrators to make changes to AWS Config rules for the new account, but it would also move the SCPs that limit access to other restricted services to the Production OU. This could create security risks for the other accounts in the organization.
Karamen
👍 2
The right answer is D
autobahn
👍 2
I'm thinking it is B because in D, it says move the organization's SCP to Production OU.. First of all why is this extra step needed? After configuring the Onboarding Account, all that needs to happen is to move that account under Production OU. Production Account's SCP should stay as is. That's my opinion. SO, B seems to be more straightforward solution.
chico2023
👍 2
Selected: D
D is the only one that has: "Move the organization’s root SCP to the Production OU" An SCP at a lower level can't add a permission after it is blocked by an SCP at a higher level.
NikkyDicky
👍 2
Selected: D
it's D
Jonalb
👍 2
Selected: D
Explanation: By creating a temporary OU named Onboarding for the new account, the company can isolate the new account and make the necessary adjustments without affecting the existing accounts. Applying an SCP to the Onboarding OU that allows AWS Config actions will grant the administrators of the new business unit the required permissions to update existing AWS Config rules. Moving the organization's root SCP to the Production OU ensures that the existing policies and restrictions are still enforced for the rest of the accounts within the organization. Once the adjustments to AWS Config are complete and the new account is aligned with the company's policies, the new account can be moved to the Production OU, integrating it into the existing account structure and applying the same policies.
bhanus
👍 1
The question NOWHERE talks about shared services VPC. Not sure if its missing here. D is the answer. A is also correct but its time taking as association of R53 zone for all the VPCs is time consuming. Imagine in future VPCs grow in number and you need to make sure R53 zone is associated with all VPCs which is time consuming. D makes it easy by associating to shared services VPC's once
RunkieMax
👍 1
Selected: D
root scp should to be move to production to let the onboarding OU the time to enforce the security
Limlimwdwd
👍 1
Selected: D
Root account deny control will supersede all the allow in the OU.. only way to workaround is move it to prod to keep the control measure
Anonymous9999
👍 1
Selected: D
From https://us-west-2.console.aws.amazon.com/vpc/home?region=us-west-2#subnets: Any account has only those permissions permitted by every parent above it. If a permission is blocked at any level above the account, either implicitly (by not being included in an Allow policy statement) or explicitly (by being included in a Deny policy statement), a user or role in the affected account can't use that permission Thus it cannot be B
mfsec
👍 1
Selected: D
D is correct
dev112233xx
👍 2
Selected: D
D is the correct answer. Explicit Deny on root can’t be bypassed by just adding “allow” in the OU SCP
kiran15789
👍 1
Selected: D
enforce the current policies without introducing additional long-term maintenance -> requires organisaiton SCP to move to Production OU to avoid such issues in future
dev112233xx
👍 1
Selected: D
D is 100% the correct answer. explicit deny in the root SCP can’t be bypassed even which explicit allow..
Ajani
👍 1
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_strategies.html
gameoflove
👍 1
Selected: D
SCP at root level is the root cause of the new not working and Answer D is right fit for it
promartyr
👍 2
When they say "Move the organization’s root SCP to the Production OU" - where is it moving from? Isn't there only one OU?
Sarutobi
👍 2
From the root of the AWS Organization to the Production OU, that is one level below. So the Organization is the root, and Production and Onboarding OU are the branches.
kamonegi
👍 1
from Onboarding OU to Production OU?
Musk
👍 2
D makes sense but there is something that does not: "Apply an SCP to the Onboarding OU to allow AWS Config actions." SCPs never allow. I think it mkes D incorrect.
Sarutobi
👍 2
Selected: D
D is correct.
skashanali
👍 2
Right answer is D As permission are inherited from root, they have to remove the SCP from root and apply on Production OU.. Also allow SCP related to AWS config for onboarding temp OU and revert the changes.
robertohyena
👍 21
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.
masetromain
👍 2
Selected: D
The correct answer is D for me
Snip
👍 54
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.
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option D is correct because AWS Organizations SCPs are evaluated cumulatively down the hierarchy and an explicit deny at the root overrides any allow attached to a child OU. A deny-list SCP at the organization root therefore blocks AWS Config actions for every account, including a new account placed in a temporary Onboarding OU. By moving that deny-list SCP to the Production OU, the Production accounts keep the same restrictions, while the new account in Onboarding can receive an SCP that permits AWS Config actions and complete its rule updates. Once the Config rules are aligned with company policy, moving the account into Production restores the standard enforcement without ongoing maintenance. Snip captured this precisely: "SCPs can only filter; they never add permissions".Why the Other Options Are Wrong
A is eliminated because Service Catalog products add a deployment and maintenance layer and do not remove the root SCP that is actually blocking AWS Config. B fails for the same reason as the root-level deny: an allow SCP on the temporary Onboarding OU cannot override the deny-list SCP still attached at the root. C is overly disruptive and labor-intensive because converting deny-list SCPs to allow-list SCPs changes the organization's whole guardrail model, and temporarily applying an allow at the root does not neutralize the existing root deny. D is the only option that both unblocks the new account and preserves the current policies for Production.Community Comment Notes
Several learners initially picked B, focusing on the temporary onboarding wording, but the SCP evaluation order makes it unworkable while the root deny remains in place. Snip's highly rated explanation notes that "SCPs can only filter; they never add permissions", which is the key reason a child-OU allow cannot reverse a root deny. dimitry_khan_arc made the same point, explaining that a root explicit deny overrides any explicit allow in a child OU. robertohyena's comment also dismisses A and C as excessive overhead, aligning with the without additional long-term maintenance requirement.Official Reference
Exam Strategy
When an SCP appears to block an account, first identify the highest-level deny; a child OU allow cannot override it. Prefer the least-disruptive relocation of the deny SCP that leaves other Production accounts protected.
Frequently Asked Questions
Why can’t an allow SCP on a temporary Onboarding OU override the root deny-list SCP?
SCPs are filters, not grants; an explicit deny at the organization root still applies to every child OU and account, so a lower-level allow cannot take effect while the root deny remains.
Why move the root SCP to the Production OU instead of deleting it?
Moving it keeps the same deny-list protections for Production accounts while freeing the new account in Onboarding to update AWS Config; deleting it would remove enforcement for everyone.
Related Analysis
Practice All SAP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full SAP-C02 Practice Test →