Comprehensive Study Guide: AWS Organizational Service Control Policies (SCPs)

This guide covers the implementation and management of Service Control Policies (SCPs) within AWS Organizations, a critical component of the Security and Compliance domain for the AWS Certified DevOps Engineer Professional (DOP-C02) exam.

Learning Objectives

By the end of this module, you should be able to:

• Define the purpose of SCPs as permission filters in a multi-account environment.
• Navigate the hierarchical structure of AWS Organizations (Roots, OUs, and Accounts).
• Evaluate effective permissions by combining SCPs with IAM policies.
• Differentiate between "Allow-list" (Whitelisting) and "Deny-list" (Blacklisting) strategies.
• Identify the limitations and scope of SCPs (e.g., impact on the Management Account).

Key Terms & Glossary

• Service Control Policy (SCP): A type of organization policy used to manage permissions in your organization. It does not grant permissions but acts as a guardrail/filter.
• Organizational Unit (OU): A container for accounts within an organization. OUs can contain other OUs, creating a hierarchy up to 5 levels deep.
• Management Account: The account used to create the organization. It has the responsibilities of a payer account and is not restricted by SCPs.
• Inheritance: The mechanism where policies applied at a higher level (Root or OU) automatically apply to all child entities beneath them.
• FullAWSAccess: The default managed SCP that allows all actions. Removing this is required to implement a strict whitelist strategy.

The "Big Idea"

SCPs are the guardrails of an AWS environment. While IAM policies define what a specific user can do, SCPs define the maximum available permissions for an entire account. If an SCP denies s3:DeleteBucket, no user in that account—even the Root user or an Administrator—can delete a bucket. It is the primary tool for enforcing compliance at scale without managing individual IAM users in every account.

Formula / Concept Box

The Permission Filter Formula

Effective Permission = (IAM Policy Allow) AND (SCP Allow) AND (NOT Explicit Deny)

Hierarchical Outline

• AWS Organizations Features
  • Consolidated Billing: Basic management, shared billing, no SCPs.
  • All Features: Includes Consolidated Billing plus advanced governance (SCPs, Tag Policies, etc.).
• SCP Evaluation Logic
  • Implicit Deny: If a service isn't allowed at any level in the hierarchy, it is denied by default.
  • Explicit Deny: Overrides any allow statement, regardless of where it is applied.
  • Hierarchy Rule: An account has only the permissions permitted by every parent above it.
• Strategies
  • Blacklisting: Allowing all services by default but explicitly denying specific high-risk actions (e.g., StopLogging).
  • Whitelisting: Removing FullAWSAccess and explicitly listing only approved services.

Visual Anchors

Organization Hierarchy Flow

Permission Intersection (Effective Access)

Definition-Example Pairs

• Term: Whitelisting
  • Definition: A restrictive approach where all permissions are denied by default, and only specifically listed actions are allowed.
  • Example: A financial institution's "Audit Account" is configured with an SCP that only allows cloudtrail:LookupEvents and s3:GetObject. All other AWS services are blocked.
• Term: Blacklisting
  • Definition: An approach where all actions are allowed, but specific dangerous actions are explicitly denied.
  • Example: An SCP applied at the Root level that denies organizations:LeaveOrganization to prevent member accounts from escaping corporate governance.

Worked Examples

Example 1: Calculating Access

Scenario:

1. Root level SCP: Allows * (Full Access).
2. OU level SCP: Explicitly Denies lambda:*.
3. Account level IAM Policy: Allows lambda:InvokeFunction and s3:*.

Question: Can a user in this account invoke a Lambda function?

Answer & Breakdown:

• Step 1: Check IAM policy. It allows lambda:InvokeFunction. (Potential Access: Yes)
• Step 2: Check SCP hierarchy. The OU level has an Explicit Deny for lambda:*.
• Step 3: Apply precedence. An explicit deny in an SCP overrides any allow in an IAM policy.
• Conclusion: Access Denied. The user cannot invoke the Lambda function.

Example 2: The "Management Account" Exception

Scenario: An SCP is applied to the Root of the organization that denies ec2:TerminateInstances.

Question: Can the Root user of the Management Account terminate an EC2 instance?

Answer: Yes. SCPs do not affect users or roles in the Management Account. They only filter permissions for Member Accounts.

Checkpoint Questions

1. What is the maximum depth allowed for an Organizational Unit (OU) hierarchy?
2. True or False: An SCP can be used to grant AdministratorAccess to a new IAM user.
3. If an account is moved from OU-A to OU-B, what happens to the SCPs inherited from OU-A?
4. Why is the FullAWSAccess policy important when using a Whitelisting strategy?

▶Click to view answers

1. 5 levels deep.
2. False. SCPs only filter; they never grant permissions. You still need an IAM policy to grant access.
3. They are removed, and the account immediately inherits the SCPs from OU-B.
4. You must remove FullAWSAccess because it acts as an 'Allow All' filter. If it remains, your whitelist will be ignored because the Full access filter will let everything through that the IAM policy allows.

Muddy Points & Cross-Refs

• SCP vs. Permissions Boundary: This is a common point of confusion. Remember: SCPs are for multi-account governance (Organizations level), while Permissions Boundaries are for delegating IAM creation power to users without letting them escalate their own privileges (Account level).
• Resource-based Policies: SCPs do affect access to resources within the account, but they do not affect resource-based policies in other accounts (e.g., an S3 bucket policy in Account B allowing access from Account A is not filtered by Account A's SCPs).

Comparison Tables

Strategy Comparison

[!IMPORTANT] Always remember: Explicit Deny > Explicit Allow > Implicit Deny. This rule is the golden key for solving permission evaluation questions on the DevOps Pro exam.