Cargando...
Cargando...
Master the layered permission model — SCPs set the ceiling, IAM Policies set the floor
SCPs restrict what CAN be allowed; IAM Policies define what IS allowed
| Feature | Organizations SCPs Guardrails for entire AWS accounts | IAM Policies Fine-grained permissions for identities |
|---|---|---|
Primary Purpose SCPs never grant permissions on their own. They only restrict what IAM policies can grant. | Define the MAXIMUM available permissions for accounts/OUs — a permission ceiling | Grant or deny specific permissions to IAM identities (users, roles, groups) |
Who/What They Apply To SCPs apply to the account ROOT user too — this is a critical exam distinction. IAM policies cannot restrict the root user. | Entire AWS accounts or Organizational Units (OUs) — affects ALL principals in those accounts including root | Specific IAM users, roles, or groups within a single account |
Scope of Control Use SCPs when you need consistent guardrails across ALL accounts in a business unit or org. | Cross-account, organization-wide — can span hundreds of accounts simultaneously | Single account scope — cannot reach across account boundaries on their own |
Can Grant Permissions? CRITICAL: Even if an SCP has Allow * on all actions, an IAM policy must still explicitly grant the permission for access to occur. | NO — SCPs only restrict. They NEVER grant permissions by themselves. | YES — Identity-based policies explicitly grant permissions to principals |
Effect on AWS Root User This is a top exam trap. SCPs are the ONLY mechanism to restrict root user actions in member accounts. | YES — SCPs restrict even the account root user (except for a small set of root-only tasks) | NO — IAM policies cannot restrict the account root user |
Effective Permission Calculation The intersection model: a permission must be allowed in BOTH the SCP and the IAM policy to be effective. Any explicit Deny at either layer wins. | Acts as an AND filter — effective permissions = SCP Allow ∩ IAM Allow (with Deny overrides) | Evaluated after SCP filter — explicit Deny always wins; no Allow = implicit Deny |
Deny vs Allow Strategy AWS recommends Deny-list strategy for SCPs (add Deny for prohibited actions) to avoid breaking existing IAM permissions. Allow-list requires listing every permitted service. | Supports both Allow-list (whitelist) and Deny-list (blacklist) strategies. Default is full-access SCP; you add Deny statements. | Primarily Allow-based with explicit Deny overrides. No implicit allow — must be explicitly granted. |
Inheritance Model An SCP applied at the Root OU affects ALL accounts. An SCP at a child OU combines with parent OU SCPs (most restrictive wins). | Hierarchical — policies cascade down from Root → OU → Account. Child inherits all parent restrictions. | Flat — policies are attached directly to identities; no automatic inheritance between accounts |
Management Account Behavior CRITICAL TRAP: The management account is immune to SCPs. This is why AWS recommends not running workloads in the management account. | SCPs do NOT apply to the management (master) account — it is always exempt | Apply normally to identities in the management account |
Policy Types Available IAM has 6 policy evaluation types. SCPs are a separate layer evaluated BEFORE IAM policies in the authorization chain. | Only one type: Service Control Policy (SCP). No inline vs managed distinction. | Multiple types: AWS Managed, Customer Managed, Inline policies, Resource-based policies, Permission Boundaries, Session Policies |
Resource-Based Policy Interaction For cross-account access: both the SCP of the caller's account AND the resource policy must allow the action. | SCPs restrict the calling principal but do NOT restrict resource-based policies directly. Cross-account access via resource policy still subject to SCP. | Resource-based policies can grant cross-account access independently of identity-based policies |
Permission Boundaries Comparison SCPs = org-level guardrails. IAM Permission Boundaries = identity-level guardrails. Both define maximum permissions but at different scopes. | Account-level boundary — restricts all principals in an account | IAM Permission Boundaries are identity-level — restrict a specific user or role only |
Supported Condition Keys aws:PrincipalOrgID in SCPs is extremely powerful — restrict resource access to principals within your org. | Supports aws:PrincipalOrgID, aws:PrincipalOrgPaths, aws:RequestedRegion, aws:SourceOrgID and most global condition keys | Supports full range of global and service-specific condition keys |
Use Case: Prevent Region Usage Region restriction is a classic SCP use case. Apply once at OU level vs maintaining per-identity policies. | IDEAL — Deny all actions in non-approved regions for entire accounts using aws:RequestedRegion | Possible but must be applied to every identity individually — operationally burdensome |
Use Case: Prevent Service Usage Compliance requirement to block certain services? Always SCP. Never rely on IAM policies alone for org-wide compliance. | IDEAL — Deny specific services (e.g., deny all EC2 in a data-only account) org-wide | Possible but requires updating all users/roles — SCPs are far more scalable |
Use Case: Fine-grained Resource Access SCPs for coarse-grained guardrails; IAM policies for fine-grained resource access control. | NOT suitable — SCPs cannot reference specific resource ARNs effectively for fine-grained control | IDEAL — Grant access to specific S3 buckets, DynamoDB tables, specific EC2 instances by ARN |
Pricing Both are free services. Cost is never a differentiator between these two in exam scenarios. | Included with AWS Organizations — no additional charge for using SCPs | No charge — IAM is free |
Where Configured Delegated administrator accounts CAN manage SCPs if granted that permission by management account. | AWS Organizations console/API — managed centrally by management account or delegated admin | IAM console/API — managed within each individual account |
Audit & Visibility IAM Access Analyzer does NOT evaluate SCP impact — it only analyzes IAM and resource-based policies. Use AWS Organizations console to view effective SCPs. | Visible in AWS Organizations; changes logged in CloudTrail as Organizations API calls | Visible in IAM; changes logged in CloudTrail as IAM API calls; IAM Access Analyzer evaluates effective permissions |
Exam Frequency Expect 3-5 questions combining BOTH concepts in permission evaluation scenarios on security exams. | Very high — especially SCS-C02 and DOP-C02; scenario-based questions on what SCPs can/cannot do | Very high — foundational to all AWS certifications; policy evaluation logic is heavily tested |
Summary
SCPs and IAM Policies work together in a layered model — SCPs define the maximum permissions available to an entire account or OU (the ceiling), while IAM Policies define what specific identities are actually allowed to do within that ceiling. Neither alone is sufficient: SCPs without IAM policies grant nothing; IAM policies without SCPs have no org-level guardrails. The effective permission is always the INTERSECTION of what both layers allow, with any explicit Deny at either layer winning absolutely.
🎯 Decision Tree
If the requirement is org-wide compliance/guardrails across multiple accounts → use SCPs | If the management account must be restricted → SCPs cannot help (management account is exempt) — use IAM policies + Permission Boundaries | If you need to restrict the ROOT user of member accounts → SCPs (only mechanism that works) | If you need fine-grained resource-level access control → IAM Policies | If you need to prevent a service from being used in any account in an OU → SCP with Deny | If you need to grant least-privilege access to a specific application → IAM Role with Customer Managed Policy | If both SCP and IAM allow an action → access is granted | If either SCP or IAM denies → access is denied
CRITICAL — The Intersection Rule: Effective permissions = (SCP Allows) ∩ (IAM Policy Allows). An action must be permitted by BOTH layers to succeed. SCPs alone NEVER grant access — they only prevent IAM policies from granting access beyond the SCP boundary. On exam scenarios with 'why is access denied?' — check BOTH layers.
CRITICAL — Management Account Exemption: SCPs NEVER apply to the management (master) account, regardless of what SCPs are attached to the Root OU. If an exam scenario asks how to restrict the management account, the answer involves IAM policies and Permission Boundaries — NOT SCPs. This exemption is absolute and cannot be overridden.
CRITICAL — Root User Restriction: SCPs are the ONLY way to restrict the root user of MEMBER accounts. IAM policies cannot restrict root users. If an exam asks how to prevent member account root users from disabling GuardDuty or CloudTrail, the answer is an SCP with an explicit Deny — not an IAM policy.
IMPORTANT — Allow-list vs Deny-list SCP Strategy: By default, AWS attaches the 'FullAWSAccess' SCP to all OUs (Deny-list strategy — everything allowed unless explicitly denied). If you REMOVE FullAWSAccess and add specific Allow statements (Allow-list strategy), you must explicitly list every service/action you want to permit. Exam questions often test which strategy is more operationally safe — Deny-list is safer for existing workloads.
IMPORTANT — SCP Inheritance Cannot Be Overridden: If a parent OU has an SCP that Denies an action, a child OU or account CANNOT override that Deny with an Allow SCP or IAM policy. Restrictions only become MORE restrictive as you go deeper in the hierarchy. Exam scenario: 'Account in nested OU needs access that parent OU denies' — the only fix is modifying the parent OU SCP.
NICE-TO-KNOW — IAM Access Analyzer Limitation: IAM Access Analyzer analyzes IAM policies and resource-based policies but does NOT factor in SCPs when calculating effective permissions. If an exam asks about a tool to validate org-wide effective permissions including SCPs, Access Analyzer alone is insufficient — you must check SCPs separately in AWS Organizations.
IMPORTANT — Cross-Account Resource Access with SCPs: When a principal in Account A accesses a resource in Account B, BOTH the SCP of Account A (restricting what the principal can do) AND the resource-based policy in Account B must allow the action. SCPs in Account B do NOT need to allow the action for cross-account resource-based policy access to work — but Account A's SCP must permit the action for the calling principal.
The #1 exam trap: Candidates believe that attaching the default 'FullAWSAccess' SCP (Allow *) to an account GRANTS permissions. It does NOT. SCPs never grant permissions — they only define the maximum boundary within which IAM policies can grant permissions. A brand new member account with FullAWSAccess SCP and NO IAM policies has NO effective permissions for any IAM principal (the root user can still act, but SCPs can restrict even that). Always remember: SCP Allow + IAM Allow = Access Granted; SCP Allow + No IAM Allow = Access Denied; SCP Deny + IAM Allow = Access Denied.
CertAI Tutor · DEA-C01, DOP-C02, SCS-C02, AIF-C01 · 2026-02-22
Services
Comparisons
Guides & Patterns