AWS Service Control Policy Strategies and Inheritance

Purpose of This Lesson

This lesson explains how AWS Service Control Policies (SCPs) are used in AWS Organizations to control the maximum available permissions across accounts and organizational units.

For the SAP-C02 exam, SCPs matter because many scenario-based questions involve multi-account governance, centralized security controls, permission boundaries, and organizational hierarchy design. You need to understand not only what an SCP does, but also how SCPs are evaluated across the AWS Organizations hierarchy.

The key focus is understanding the difference between:

• Deny list strategy
• Allow list strategy
• SCP inheritance
• How permissions must flow from the root, through each OU, down to the target account

Key Concepts

What Service Control Policies Do

Service Control Policies are policy documents used with AWS Organizations to define the maximum available permissions for AWS accounts.

An SCP does not directly grant permissions to IAM users, roles, or groups. Instead, it acts as a guardrail that defines what permissions are even possible inside an account.

For an action to be allowed:

1. The IAM identity must have permission.
2. The SCP hierarchy must allow the action.
3. There must not be an explicit deny.

Think of SCPs as organization-level permission boundaries.

SCPs and AWS Organizations Hierarchy

AWS Organizations uses a hierarchy:

• Root
• Organizational Units
• Child OUs
• AWS accounts

SCPs can be attached at different levels of this hierarchy.

A policy attached higher in the hierarchy affects everything below it. For example, an SCP attached to the root affects all OUs and accounts underneath the root.

A policy attached to an OU affects all child OUs and accounts within that OU.

Deny List Strategy

The deny list strategy is the default AWS Organizations approach.

With this strategy, the AWS-managed policy named FullAWSAccess is attached by default. This policy allows all AWS actions on all resources.

Example conceptually:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

This means all AWS services and API actions are available unless you explicitly deny something with another SCP.

How the Deny List Strategy Works

Under a deny list model:

• FullAWSAccess is attached at the root, OUs, and/or accounts.
• All permissions are available by default.
• You create SCPs with explicit deny statements to block specific services or actions.
• Explicit deny overrides allow.

For example, if you attach an SCP that denies all DynamoDB actions to an OU, accounts in that OU cannot use DynamoDB even if IAM permissions allow it.

Example:

{
  "Effect": "Deny",
  "Action": "dynamodb:*",
  "Resource": "*"
}

If this SCP is attached to OU1 and OU2, then accounts under those OUs cannot perform DynamoDB actions.

When to Use a Deny List Strategy

A deny list strategy is easier to manage when most AWS services are allowed and you only need to restrict specific services, regions, or actions.

Common use cases include:

• Denying access to unused or risky services
• Restricting specific AWS Regions
• Blocking deletion of security resources
• Preventing users from disabling CloudTrail, GuardDuty, or AWS Config
• Creating broad guardrails while allowing flexibility

The downside is that new AWS services may be allowed automatically unless you explicitly block them.

Allow List Strategy

The allow list strategy is more restrictive.

With this strategy, FullAWSAccess is removed, and you must explicitly allow the services and actions that accounts are permitted to use.

This is a tighter governance model, but it requires more planning.

How the Allow List Strategy Works

In an allow list model:

• FullAWSAccess is removed.
• SCPs must explicitly allow actions.
• The allowed permissions must exist at every level of the hierarchy.
• Permissions must flow from the root through each OU down to the account.

This is the most important concept for the exam:

An allow at a lower OU or account does not work unless the same permission is also allowed at every parent level above it.

SCP Inheritance in an Allow List Strategy

In an allow list strategy, permissions are not additive in the way many people expect.

For example, imagine this hierarchy:

Root
└── OU1
    └── OU2
        └── Account

Assume the following:

At the root and OU1, you allow:

ec2:*
cloudwatch:*

At OU2, you attach a policy allowing:

dynamodb:*

The result is not EC2, CloudWatch, and DynamoDB.

The result is only:

ec2:*
cloudwatch:*

DynamoDB is not available because DynamoDB was not allowed at the root and every OU above OU2.

For DynamoDB to be available in OU2, DynamoDB must be allowed at:

• Root
• OU1
• OU2
• Target account, if account-level SCPs are used

Explicit Deny Always Wins

SCP evaluation follows the same important rule found in IAM policy evaluation:

An explicit deny overrides any allow.

Even if a service is allowed through the hierarchy, an explicit deny at any applicable level blocks the action.

For example:

• Root allows all services.
• OU allows EC2.
• Account IAM policy allows EC2.
• Another SCP denies ec2:TerminateInstances.

The user or role cannot terminate EC2 instances because the explicit deny wins.

SCPs Do Not Grant Permissions

This is one of the most important SAP-C02 concepts.

An SCP only defines the maximum permissions available to an account. It does not grant access by itself.

A user or role still needs IAM permissions inside the account.

For example, if an SCP allows EC2, that does not mean every user can launch EC2 instances. The user still needs an IAM policy allowing EC2 actions.

The SCP simply says, “EC2 is allowed to be granted inside this account.”

Deny List vs Allow List Mindset

The two strategies represent different governance philosophies.

A deny list strategy says:

“Everything is available unless we specifically block it.”

An allow list strategy says:

“Nothing is available unless we specifically approve it.”

For the exam, AWS often expects you to recognize which model is more appropriate based on the organization’s governance, compliance, and operational needs.

Exam-Relevant Takeaways

For the SAP-C02 exam, remember these points:

SCPs control the maximum available permissions in AWS accounts, but they do not grant permissions directly.

The default AWS Organizations setup uses the FullAWSAccess SCP, which allows all actions on all resources.

A deny list strategy keeps FullAWSAccess in place and adds explicit deny statements where needed.

An allow list strategy removes FullAWSAccess and requires explicit allow statements at every level of the hierarchy.

With an allow list strategy, permissions must be allowed from the root all the way down to the target account.

If an action is not allowed at any parent level, it is not available below that level.

An explicit deny in any applicable SCP overrides any allow.

Adding an allow at a lower OU does not work if the action is not also allowed by the parent OUs and root.

SCPs apply to member accounts in AWS Organizations, but permissions in the management account are handled differently and are not restricted in the same way by SCPs.

Architecture Decision Guide

Scenario	Best AWS Choice	Why
Organization wants broad AWS service access but needs to block a few risky actions	Deny list SCP strategy	Easier to operate because all services are allowed by default, and specific services/actions can be denied
Organization has strict compliance requirements and only approved services may be used	Allow list SCP strategy	Provides tighter control by allowing only explicitly approved AWS services/actions
Need to prevent accounts from using DynamoDB in specific OUs	Deny SCP attached to target OU	Explicit deny blocks DynamoDB for accounts under that OU
Need to allow DynamoDB only in a specific OU using an allow list model	Allow DynamoDB at root, every parent OU, and the target OU	Permissions must flow through every level of the hierarchy
Need to stop users from disabling security logging	Explicit deny SCP	Deny actions such as disabling CloudTrail, AWS Config, or GuardDuty, regardless of IAM permissions
Need to give an IAM role access to EC2	IAM policy plus SCP allowance	SCPs only set the maximum permissions; IAM still grants the actual access
Need centralized governance across many AWS accounts	AWS Organizations with SCPs	SCPs provide guardrails across accounts and OUs
Need temporary fine-grained permissions for a single user	IAM policy, not SCP	SCPs are organization/account guardrails, not user-level access policies

Common Exam Traps

Trap 1: Thinking SCPs Grant Permissions

SCPs do not grant permissions.

Even if an SCP allows ec2:*, the IAM user or role still needs an IAM policy allowing EC2 actions.

Trap 2: Thinking a Lower-Level Allow Overrides a Parent Restriction

In an allow list strategy, attaching an allow policy at a lower OU is not enough.

If the parent OU or root does not allow the action, the permission does not flow down.

Trap 3: Forgetting That Explicit Deny Wins

An explicit deny always overrides an allow.

This applies even if IAM allows the action and another SCP allows the action.

Trap 4: Confusing Deny List and Allow List Strategies

Deny list strategy:

• FullAWSAccess remains attached.
• You block specific actions with deny statements.

Allow list strategy:

• FullAWSAccess is removed.
• You must explicitly allow actions at every level.

Trap 5: Assuming Permissions Are Additive Across the Hierarchy

In an allow list model, permissions are not simply added together from each level.

The action must be allowed through the full path from root to account.

Trap 6: Overusing Allow List Without Understanding Operational Overhead

An allow list strategy is more secure but more complex. It requires ongoing maintenance when teams need new AWS services or when AWS launches new services.

Real-World Engineer Notes

In real environments, the deny list strategy is often easier to operate, especially for organizations that want to enable cloud teams while applying guardrails.

For example, you may allow general AWS usage but deny:

• Leaving approved AWS Regions
• Disabling CloudTrail
• Deleting AWS Config rules
• Turning off GuardDuty
• Creating public S3 buckets
• Using expensive or unapproved services

The allow list strategy can make sense for highly regulated environments, but it requires strong governance. Every new service request needs to be reviewed and allowed at the correct hierarchy levels.

From an operational standpoint, allow list strategies can create confusing troubleshooting scenarios. A team may have the correct IAM permissions, but an API call still fails because the SCP hierarchy does not allow the action.

When troubleshooting SCP-related access issues, check:

1. The IAM policy attached to the user, group, or role.
2. The SCPs attached to the account.
3. The SCPs attached to each parent OU.
4. The SCPs attached to the root.
5. Whether an explicit deny exists anywhere in the hierarchy.

For cloud governance, it is common to use a hybrid pattern:

• Start with the default deny list model.
• Apply explicit denies for critical guardrails.
• Use separate OUs for workloads with stricter compliance needs.
• Use allow list controls only where the business requirement justifies the added complexity.

For example, a production regulated workload OU may use a more restrictive SCP model, while development accounts may use broader permissions with guardrails.

Quick Reference Summary

Service Control Policies are used with AWS Organizations to define maximum available permissions for member accounts.

The default model is the deny list strategy using FullAWSAccess.

Deny list means everything is allowed unless explicitly denied.

Allow list means nothing is allowed unless explicitly allowed.

In an allow list strategy, permissions must be allowed at every level from root to account.

An explicit deny always overrides an allow.

SCPs do not grant permissions. IAM policies still grant the actual access.

For SAP-C02, expect scenario questions where the correct answer depends on SCP inheritance, explicit deny behavior, and whether permissions flow from the root through the OU hierarchy.

Flashcards

Q: What is the purpose of an AWS Service Control Policy?
A: An SCP defines the maximum available permissions for AWS accounts in an AWS Organization. It does not grant permissions directly.

Q: What is the default SCP strategy in AWS Organizations?
A: The deny list strategy, where FullAWSAccess is attached by default and specific actions are denied as needed.

Q: What does the FullAWSAccess SCP allow?
A: It allows all AWS actions on all resources using Action: "*" and Resource: "*".

Q: In a deny list strategy, how do you restrict access to a service?
A: Attach an SCP with an explicit deny for that service or action.

Q: What happens if an SCP explicitly denies DynamoDB actions?
A: DynamoDB actions are blocked for affected accounts, even if IAM policies allow DynamoDB.

Q: What is an allow list SCP strategy?
A: A restrictive strategy where FullAWSAccess is removed and only explicitly allowed services/actions are available.

Q: In an allow list strategy, where must an action be allowed?
A: At every level of the hierarchy from root through each OU down to the target account.

Q: If DynamoDB is allowed only at a child OU but not at the root, can accounts in that OU use DynamoDB?
A: No. DynamoDB must be allowed at the root and each parent OU for the permission to flow down.

Q: Does an SCP grant permissions to IAM users or roles?
A: No. IAM policies grant permissions. SCPs only define the maximum permissions that can be granted.

Q: What wins when an explicit deny conflicts with an allow?
A: The explicit deny always wins.

Q: Which SCP strategy is easier to operate for most organizations?
A: The deny list strategy is usually easier because services are allowed by default and only specific actions are blocked.

Q: Which SCP strategy is better for strict compliance environments?
A: The allow list strategy, because only approved services and actions are permitted.

Q: Why can allow list SCPs be harder to manage?
A: Every required service or action must be explicitly allowed through the full AWS Organizations hierarchy.

Q: What should you check when IAM permissions appear correct but access is still denied?
A: Check SCPs at the account, OU, parent OU, and root levels for missing allows or explicit denies.

Q: What is the key SCP inheritance rule for SAP-C02?
A: Permissions must flow from the root through every OU to the account, especially in an allow list strategy.

Practice Questions

Question 1:
A company uses AWS Organizations with the default SCP configuration. The security team wants to prevent all accounts in the Development OU from using Amazon DynamoDB. What should they do?

A. Remove all IAM policies that allow DynamoDB from users in the Development OU
B. Attach an SCP to the Development OU that explicitly denies dynamodb:*
C. Attach an SCP to the Development OU that allows only ec2:*
D. Remove FullAWSAccess from the root account only

Correct Answer:
B. Attach an SCP to the Development OU that explicitly denies dynamodb:*

Explanation:
The default AWS Organizations model uses a deny list strategy with FullAWSAccess attached. To block DynamoDB for accounts in a specific OU, attach an SCP with an explicit deny for DynamoDB actions to that OU.

---

Question 2:
An organization uses an allow list SCP strategy. The root and parent OU allow only EC2 and CloudWatch actions. A child OU has an SCP that allows DynamoDB actions. Can accounts in the child OU use DynamoDB?

A. Yes, because the child OU explicitly allows DynamoDB
B. Yes, if IAM permissions allow DynamoDB
C. No, because DynamoDB is not allowed at the root and parent OU levels
D. No, because SCPs cannot control DynamoDB access

Correct Answer:
C. No, because DynamoDB is not allowed at the root and parent OU levels

Explanation:
In an allow list strategy, permissions must be allowed at every level from the root through each OU down to the account. A lower-level allow does not work unless the permission is also allowed above it.

---

Question 3:
A user has an IAM policy that allows ec2:TerminateInstances. An SCP attached to the user’s account explicitly denies ec2:TerminateInstances. What happens when the user tries to terminate an EC2 instance?

A. The action succeeds because IAM allows it
B. The action succeeds if the user is an administrator
C. The action fails because the explicit deny in the SCP overrides the IAM allow
D. The action fails only if the SCP is attached to the root

Correct Answer:
C. The action fails because the explicit deny in the SCP overrides the IAM allow

Explanation:
An explicit deny in an SCP overrides any allow in IAM or other policies.

---

Question 4:
A company wants to strictly limit AWS accounts so that only approved AWS services can be used. New services should not automatically become available. Which SCP strategy is most appropriate?

A. Deny list strategy
B. Allow list strategy
C. IAM group strategy
D. Resource-based policy strategy

Correct Answer:
B. Allow list strategy

Explanation:
An allow list strategy removes FullAWSAccess and requires approved services/actions to be explicitly allowed. This prevents new or unapproved services from being available by default.

---

Question 5:
A developer says they cannot access an AWS service even though their IAM role has the correct permissions. The organization uses SCPs with an allow list strategy. What is the most likely cause?

A. SCPs automatically deny all IAM roles
B. The AWS service is not allowed somewhere in the AWS Organizations hierarchy
C. IAM roles cannot be used with AWS Organizations
D. FullAWSAccess must be attached only to the account, not the root

Correct Answer:
B. The AWS service is not allowed somewhere in the AWS Organizations hierarchy

Explanation:
In an allow list strategy, an action must be allowed at every level from root to account. If any level does not allow the action, the account cannot use that service or API action.