Multi-Account Organizations And Scp Governance — AWS Solutions Architect Pro (SAP-C02)
SCPs Applied to Root OU Do Not Restrict the Management Account
SCPs get chosen to prevent the management account from taking prohibited actions, but they do not apply there. The management account is exempt from SCPs by design, regardless of which OU it appears to sit under. This makes it an inappropriate place to run workloads in any compliant multi-account architecture. SCPs constrain member accounts by setting a ceiling on allowed actions, but they do not grant permissions; a principal still needs an IAM policy explicitly allowing the action. When a scenario asks how to prevent all accounts from disabling GuardDuty, an SCP on the root OU covers member accounts only. Separate administrative controls are required for the management account.
What This Pattern Tests
The exam tests SCP mechanics. SCPs are permission boundaries on AWS accounts — they restrict the maximum permissions IAM policies can grant but do not grant permissions themselves. If an SCP denies ec2:RunInstances, no IAM policy in that account can launch EC2 instances. SCPs apply to all principals in the account (including the root user) except the management account. SCPs can be attached to OUs (affects all accounts in the OU) or individual accounts. The trap is writing an SCP with Allow statements thinking it grants permissions (it only permits IAM to grant them) or assuming SCPs affect the management account (they do not).
Decision Axis
SCP scope (OU-wide vs. account-specific) and the interaction between SCP ceilings and IAM grants. The effective permission is the intersection.
Associated Traps
More Top Traps on This Exam
Domain Coverage
Difficulty Breakdown