SCP vs Permission Boundary: Two Guardrails That Look Alike but Aren't

Both SCPs and permission boundaries are maximum-permission guardrails — neither grants permissions on its own. The exam tests whether you know WHERE each applies: SCPs guard accounts (and OUs/roots) in AWS Organizations; permission boundaries guard individual IAM users and roles.

The effective permission is always the intersection: for an IAM entity to act, its identity policy must allow it AND no guardrail must deny it.

Service Control Policies — account-level ceiling

SCPs attach to the organization root, OUs, or individual accounts in AWS Organizations. They set the maximum permissions for ALL principals in affected accounts — including the root user. Deny-list strategy (default allow, SCPs carve out) is the common pattern: 'deny leaving these regions,' 'deny disabling CloudTrail.'

Key facts: SCPs don't affect service-linked roles; they apply to IAM users/roles including root; a 'deny' wins over any allow; management-account SCPs don't limit the management account itself.

Permission boundaries — entity-level ceiling

A permission boundary is a managed policy attached to a single IAM user or role that caps what that entity can do — even if its identity policies grant more. The classic use case: let developers create IAM roles for their Lambda functions, but only if the new roles carry a boundary that prevents privilege escalation.

Boundaries don't apply to resource-based policies for access evaluation in the same way — a resource policy can grant access to the entity within boundary limits, but the boundary still caps what identity-policy permissions can do.

Side-by-side

Exam shortcut: 'prevent privilege escalation when delegating role creation' → permission boundary. 'Enforce rules across every account in the org' → SCP. Both can appear in the same scenario — layered, not competing.

• Scope: SCP = org/OU/account; boundary = one user or role
• Managed by: SCP = organization admin; boundary = IAM admin in the account
• Applies to root user: SCP yes; boundary no (root has no policies)
• Use for: SCP = governance across many accounts; boundary = safe IAM delegation
• Evaluation: both intersect with identity policies — allow requires all three layers