Multi-Account Organizations And Scp Governance — AWS Solutions Architect (SAA-C03)
SCPs restrict maximum permissions; they never grant them
The scenario asks for a control that prevents all accounts in an OU from disabling CloudTrail. A candidate selects an IAM policy applied to the root account. The exam answer is an SCP attached to the OU via AWS Organizations. IAM policies govern principals within an account; SCPs set the maximum permission boundary for all principals in the account, including account administrators. SCPs work by restriction — they remove what IAM would otherwise allow. The exam tests this additive-versus-restrictive distinction directly and repeatedly.
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
Decision Rules
Whether an SCP deny attached at the OU level is the correct ceiling control to enforce a blanket restriction across all principals in all member accounts, versus applying IAM permission boundaries per role (per-principal overhead, same OU scope only when exhaustively applied) or AWS Config rules with automated remediation (reactive, not preventive, and over-engineered for a single prohibit requirement).
Domain Coverage
Difficulty Breakdown