3.4.1.4. Organizational SCPs

3.4.1.4. Organizational SCPs

SCPs are the highest-level permission control — they define what can't happen in an account, regardless of IAM policies.

Deny-list approach (recommended):

{
  "Version": "2012-10-17",
  "Statement": [
    {"Effect": "Allow", "Action": "*", "Resource": "*"},
    {"Sid": "DenyLeavingOrg", "Effect": "Deny",
     "Action": "organizations:LeaveOrganization", "Resource": "*"},
    {"Sid": "DenyDisablingAudit", "Effect": "Deny",
     "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail",
                "config:StopConfigurationRecorder"], "Resource": "*"},
    {"Sid": "DenyRootActions", "Effect": "Deny", "Action": "*", "Resource": "*",
     "Condition": {"StringLike": {"aws:PrincipalArn": "arn:aws:iam::*:root"}}}
  ]
}

Common SCP guardrails:

• Deny region usage outside approved regions (with exception for global services)
• Deny root account access
• Deny disabling CloudTrail, Config, GuardDuty
• Deny creating IAM access keys for root
• Deny public S3 bucket policies (organization-level), e.g., deny s3:PutBucketPublicAccessBlock and s3:PutAccountPublicAccessBlock so Block Public Access (on by default for new buckets) can't be switched off

SCP inheritance: Account's effective SCP = intersection of all SCPs from root → OU chain → account. A deny at any level overrides allows at all other levels.

Exam Trap: SCPs apply to all principals except the management account and service-linked roles. The management account is immune — workloads should never run there. Service-linked roles (created by AWS services) are exempt, ensuring services like CloudTrail continue working under restrictive SCPs.