An AWS Organization has a single OU named Production that contains all accounts. Root-level deny-list SCPs are used to restrict access to certain services. A newly invited account from an acquired business unit cannot update existing AWS Config rules to comply with company policy. Which approach allows the new account administrators to make required changes now while preserving and enforcing the existing policies with minimal ongoing maintenance?

The correct approach involves creating a temporary Onboarding OU for the new account and attaching an SCP that explicitly allows AWS Config actions. This grants the necessary permissions to the new account without altering the existing, more restrictive SCPs at the root. Moving the organization's root SCPs under the Production OU ensures that these restrictive policies still apply to all accounts within the Production OU. Once the AWS Config modifications are complete, moving the new account into the Production OU will automatically subject it to the established, stricter policies. Incorrect options: Removing root-level deny-list SCPs is not ideal as it weakens security for all accounts. AWS Service Catalog is for deploying resources, not for overriding SCPs. Creating a temporary Onboarding OU and attaching an allowing SCP is a good first step, but moving the account directly into Production without adjusting the root SCPs would immediately re-apply the original restrictions, potentially blocking future Config changes or other necessary actions. Converting to allow-list SCPs at the root is a significant architectural change that would require extensive effort to enumerate all allowed services, and temporarily allowing Config actions at the root for a single account is less granular and harder to manage than using an OU.