How to Let a New Account Update AWS Config Under Root SCPs?

SAP-C02 By islever Editorial Last updated

Design a multi-account AWS environment. Determine security controls based on requirements.

Short 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.

Question

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?
  1. Remove the organization’s root SCPs that limit access to AWS Config. Create AWS Service Catalog products for the company’s standard AWS Config rules and deploy them throughout the organization, including the new account.
  2. Create a temporary OU named Onboarding for the new account. Apply an SCP to the Onboarding OU to allow AWS Config actions. Move the new account to the Production OU when adjustments to AWS Config are complete.
  3. Convert the organization’s root SCPs from deny list SCPs to allow list SCPs to allow the required services only. Temporarily apply an SCP to the organization’s root that allows AWS Config actions for principals only in the new account.
  4. 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. Correct Answer

Key Takeaways

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.

Common mistake: 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.

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

These links open the official vendor documentation in a new tab.

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.

More SAP-C02 FAQ →

Discussion 72 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 30 of 72

  1. 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.
  2. 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.
  3. sebnzogang 👍 6 Answered 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.
  4. 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.
  5. nayeh 👍 5 Answered 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
Show 25 more comments
  1. victorHugo 👍 5
    " All accounts are members of the Production OU", therefore we don't need the SCP in root.
  2. 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.
  3. dimitry_khan_arc 👍 3 Answered 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.
  4. 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
  5. 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?
  6. pkr3003 👍 2 Answered 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.
  7. Jonalb 👍 2 Answered 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.
  8. 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.
  9. MasterVivek 👍 2 Answered 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.
  10. ninomfr64 👍 2 Answered 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.
  11. 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
  12. 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.
  13. hspc_ 👍 2 Answered 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
  14. 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.
  15. TonytheTiger 👍 2 Answered 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
  16. 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.
  17. chico2023 👍 2 Answered 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.
  18. 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.
  19. 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.
  20. 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..
  21. 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?
  22. dev112233xx 👍 2 Answered D
    D is the correct answer. Explicit Deny on root can’t be bypassed by just adding “allow” in the OU SCP
  23. ansgohar 👍 2 Answered D
    D. An SCP at a lower level can't add a permission after it is blocked by an SCP
  24. severlight 👍 2 Answered D
    need to get rid of deny in root scp
  25. masetromain 👍 2 Answered D
    The correct answer is D for me

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Cost-Effective Image Processing with SQS and S3 Lifecycle Policies

S-grade

Modernize centralized firewall appliances with a Gateway Load Balancer and Auto Scaling

S-grade

Use Lambda over a CloudWatch Logs stream to count unique users per client

S-grade

Serve global game assets with Route 53 latency records and health checks

S-grade

Practice All SAP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full SAP-C02 Practice Test →

← Back to SAP-C02 Study Guide