AWS Organizations SCP Inheritance and Management Account Behavior

Purpose of This Lesson

This lesson explains how AWS Organizations Service Control Policies, or SCPs, work across the organization hierarchy. The focus is on SCP inheritance, the default deny-list strategy, attaching SCPs to Organizational Units, and understanding why the management account is not restricted by SCPs.

For the AWS Certified Solutions Architect – Professional SAP-C02 exam, this matters because SCPs are a common governance tool in multi-account AWS environments. Scenario questions often test whether you understand that SCPs define the maximum available permissions, but do not grant permissions by themselves.

Key Concepts

AWS Organizations Hierarchy

An AWS Organization has a hierarchy that typically looks like this:

• Root
• Organizational Units, or OUs
• Member accounts
• Management account

The management account is the original account used to create the AWS Organization. It sits at the top-level root view and has special behavior compared to member accounts.

A common structure might look like this:

AWS Organization Root
├── Management Account
└── Prod OU
    └── Production AWS Account

SCPs can be attached at different levels of this hierarchy:

• Root
• OU
• Member account

When an SCP is attached to a parent level, it affects child OUs and accounts beneath it, subject to inheritance rules.

What Service Control Policies Do

Service Control Policies are used to define the maximum permissions available to accounts in an AWS Organization.

An SCP does not give permissions to a user, role, or service. IAM still controls what an identity is allowed to do.

Think of it this way:

Effective permissions = IAM permissions allowed AND SCP permissions allowed

If IAM allows an action but the SCP denies it, the action is denied.

If SCP allows an action but IAM does not allow it, the action is still denied.

SCPs are guardrails. IAM policies are the actual permission grants.

Default Deny-List Strategy

AWS Organizations uses a default deny-list strategy when SCPs are enabled.

In this model, AWS attaches the AWS managed SCP named FullAWSAccess by default. This policy allows all actions on all resources.

Conceptually, it looks like this:

Effect: Allow
Action: *
Resource: *

This means all AWS API actions are allowed to flow through the organization hierarchy unless another SCP explicitly denies something.

With a deny-list approach:

• Everything is allowed by default through the SCP layer.
• You add explicit deny statements to restrict specific actions.
• Explicit deny always wins.
• IAM permissions are still required for the user or role to perform the action.

This is easier to manage for many organizations because you start from broad availability and then block high-risk or unwanted actions.

SCP Inheritance

SCPs inherit down the AWS Organizations hierarchy.

If an SCP is attached to the root, it applies to OUs and member accounts beneath the root.

If an SCP is attached to an OU, it applies to accounts inside that OU and any child OUs beneath it.

If an SCP is attached directly to an account, it applies only to that account.

For an action to be allowed under the SCP layer, the permission must be allowed through the hierarchy. However, an explicit deny at any level overrides an allow.

Example:

Root: FullAWSAccess
Prod OU: Deny launching non-t2.micro EC2 instances
Production Account: IAM role has AdministratorAccess

Even though the role in the production account has AdministratorAccess, the SCP attached to the Prod OU can still block launching disallowed EC2 instance types.

Example SCP: Restrict EC2 Instance Type

The example policy in the lesson denies the ability to launch EC2 instances unless the instance type is t2.micro.

The policy logic is:

• Deny ec2:RunInstances
• Apply to all resources
• Use a condition that denies the request when ec2:InstanceType is not equal to t2.micro

The important exam concept is not the specific instance type. The important concept is that SCPs can enforce organizational restrictions such as:

• Only allow specific EC2 instance families
• Block large or expensive instance types
• Prevent use of certain AWS Regions
• Prevent disabling security services
• Block root user actions in member accounts
• Prevent leaving the AWS Organization

SCP Deny Overrides AdministratorAccess

In the example, the user switches into a member account using the OrganizationAccountAccessRole.

That role has AdministratorAccess in the member account.

However, when the SCP denies launching anything other than a t2.micro instance, the administrator role is still blocked.

This is a major SAP-C02 exam point:

AdministratorAccess in IAM does not bypass an SCP.

SCPs sit above account-level IAM permissions. They define the outer boundary of what the account can do.

Successful Launch: t2.micro

When the user launches a t2.micro EC2 instance, the request succeeds because the SCP deny condition does not apply.

The SCP only denies the request when the instance type is something other than t2.micro.

This means the SCP is not granting permission to launch EC2. It is simply not blocking that allowed instance type. IAM still needs to allow the launch.

Failed Launch: t2.medium

When the user tries to launch a t2.medium, the request fails with an authorization error.

This happens because:

• IAM allows the action through AdministratorAccess.
• The SCP denies ec2:RunInstances when the instance type is not t2.micro.
• Explicit deny wins.

This is exactly how SCP guardrails are intended to work.

Console Side Effects and Partial Operations

One practical detail from the test is that the EC2 console may still perform some related actions before the final blocked action fails.

For example, security groups may be created successfully, but the EC2 instance launch fails when RunInstances is denied.

This matters in real environments because an SCP may prevent the main action but still leave behind supporting resources if those actions are not also restricted.

From an operational standpoint, engineers should test SCPs carefully and review whether partial resource creation is possible.

Management Account Is Not Restricted by SCPs

A key point from the lesson is that SCPs do not affect users or roles in the AWS Organizations management account.

Even when the restrictive SCP is moved from the Prod OU to the organization root, the management account can still launch a t2.medium instance.

This is one of the most important exam traps.

SCPs apply to member accounts, but they do not restrict the management account itself.

For governance, this means the management account must be protected using other controls, such as:

• Strong IAM policies
• MFA
• Least privilege administrative roles
• Root user protection
• CloudTrail
• AWS Config
• GuardDuty
• Access Analyzer
• Break-glass procedures
• Limited human access

Do not assume that placing an SCP at the root will restrict the management account.

AWS Organizations Service Access

The lesson also shows that AWS Organizations has different policy types and service integrations that can be enabled or disabled.

For this scenario, the relevant policy type is:

Service Control Policies

SCPs must be enabled before they can be created and attached.

In a real AWS Organization, you may also see other policy types or service integrations, but SCPs are the primary governance control being tested here.

Exam-Relevant Takeaways

For the SAP-C02 exam, remember these points:

• SCPs define the maximum available permissions for AWS accounts.
• SCPs do not grant permissions.
• IAM policies are still required to allow actions.
• An explicit deny in an SCP overrides IAM permissions, including AdministratorAccess.
• The default AWS Organizations SCP model is a deny-list strategy using FullAWSAccess.
• FullAWSAccess allows permissions to flow through the organization hierarchy.
• SCPs can be attached to the root, OUs, or individual member accounts.
• SCPs inherit downward through the AWS Organizations hierarchy.
• An SCP attached to an OU affects accounts inside that OU.
• An SCP attached to the root affects member accounts beneath the root.
• SCPs do not restrict identities in the management account.
• SCPs are useful for governance, cost control, security guardrails, and compliance enforcement.
• SCPs can restrict actions based on conditions, such as EC2 instance type.

Architecture Decision Guide

Scenario	Best AWS Choice	Why
Restrict all production accounts from launching large EC2 instances	SCP attached to the Production OU	Applies the restriction consistently to all accounts in the OU
Restrict only one AWS account	SCP attached directly to the account	Limits the impact to a single account
Restrict all member accounts in the organization	SCP attached to the root	Inherits down to all OUs and member accounts
Grant a developer permission to launch EC2	IAM policy or IAM role	SCPs do not grant permissions
Prevent even administrators from launching disallowed instance types	SCP explicit deny	SCP deny overrides IAM AdministratorAccess
Restrict the management account	IAM controls, MFA, monitoring, and account governance	SCPs do not apply to the management account
Allow most AWS services but block a few risky actions	Deny-list SCP strategy	Start with FullAWSAccess and add explicit denies
Require only approved AWS services or Regions	Allow-list SCP strategy	More restrictive, but requires explicit allows throughout the hierarchy

Common Exam Traps

Trap 1: Thinking SCPs Grant Permissions

SCPs do not grant access.

If a user has no IAM permission to launch EC2, attaching an SCP that allows EC2 does not give them permission.

The user still needs IAM permissions.

Trap 2: Thinking AdministratorAccess Bypasses SCPs

AdministratorAccess does not bypass an SCP.

If the SCP denies the action, the action is denied.

This is true even for highly privileged roles inside member accounts.

Trap 3: Forgetting the Management Account Exception

SCPs do not restrict the management account.

Even if an SCP is attached at the organization root, users and roles in the management account are not affected by that SCP.

Trap 4: Confusing Root of the Organization with Root User

The AWS Organizations root is the top of the organization hierarchy.

The AWS account root user is the original privileged identity inside an AWS account.

These are not the same thing.

Trap 5: Assuming an OU Name Has Special Meaning

An OU named “Prod” is just a container.

The name itself has no security meaning. The attached policies and account placement determine the actual governance behavior.

Trap 6: Ignoring SCP Inheritance

An SCP attached at the OU level affects accounts in that OU.

An SCP attached at the root affects child OUs and member accounts.

A deny at a higher level can impact many accounts, so SCP placement is an architecture decision.

Trap 7: Forgetting About Partial Console Actions

The AWS console often performs multiple API calls.

An SCP might deny the final action while allowing earlier setup actions, such as creating a security group.

For clean governance, review all related actions involved in a workflow.

Real-World Engineer Notes

In a real enterprise AWS environment, SCPs are one of the most important controls for multi-account governance.

A common pattern is to organize accounts into OUs such as:

Security
Infrastructure
Shared Services
Production
Development
Sandbox
Suspended

Then apply SCPs based on the risk level and purpose of each OU.

For example, a sandbox OU might allow developers to experiment, but block expensive EC2 instance types, GPU instances, or unsupported Regions.

A production OU might block actions such as:

• Disabling CloudTrail
• Deleting AWS Config recorders
• Disabling GuardDuty
• Leaving the AWS Organization
• Creating IAM users
• Modifying critical security roles
• Launching unapproved instance types
• Using Regions that are not approved by the business

From an operational perspective, SCPs should be tested carefully before being applied broadly.

A bad SCP at the root can disrupt multiple member accounts.

Best practice in real environments is to:

• Test the SCP in a sandbox OU first.
• Use a dedicated test account.
• Validate common workflows before production rollout.
• Keep break-glass access available.
• Document the business reason for each deny.
• Monitor CloudTrail for access denied events.
• Use clear SCP names, such as Deny-Unapproved-Regions or Deny-Disable-Security-Services.

For cost governance, SCPs are useful because they can prevent expensive resources from being launched in the first place.

For security governance, SCPs help enforce organizational standards even when account administrators have broad IAM permissions.

However, SCPs are not a replacement for IAM least privilege. They are a guardrail layer, not a full access management strategy.

Quick Reference Summary

Service Control Policies are AWS Organizations guardrails that define the maximum available permissions for member accounts.

The default strategy is a deny-list model where FullAWSAccess is attached by default and explicit deny policies are added where needed.

SCPs can be attached to the root, OUs, or individual member accounts.

SCPs inherit downward.

IAM still grants permissions, but SCPs can block permissions.

An SCP explicit deny overrides IAM AdministratorAccess.

The management account is not restricted by SCPs, even if the SCP is attached at the organization root.

For the exam, remember:

IAM grants permissions.
SCPs limit permissions.
Explicit deny wins.
Management account is not affected by SCPs.

Flashcards

Q: What is the purpose of an AWS Organizations SCP?
A: An SCP defines the maximum available permissions for member accounts in an AWS Organization.

Q: Does an SCP grant permissions to IAM users or roles?
A: No. SCPs do not grant permissions. IAM policies are still required.

Q: What happens if IAM allows an action but an SCP denies it?
A: The action is denied because explicit deny overrides allow.

Q: What is the default SCP attached in AWS Organizations?
A: FullAWSAccess.

Q: What does the FullAWSAccess SCP do?
A: It allows all actions on all resources at the SCP layer, allowing permissions to flow through the organization hierarchy.

Q: What is a deny-list SCP strategy?
A: A strategy where actions are allowed by default through FullAWSAccess, and specific actions are explicitly denied using SCPs.

Q: Can an SCP attached to an OU affect accounts inside that OU?
A: Yes. SCPs attached to an OU apply to member accounts inside that OU.

Q: Can an SCP attached to the root restrict member accounts?
A: Yes. SCPs attached to the organization root apply to child OUs and member accounts.

Q: Can an SCP attached to the root restrict the management account?
A: No. SCPs do not affect users or roles in the management account.

Q: Does IAM AdministratorAccess bypass an SCP?
A: No. AdministratorAccess does not bypass SCP restrictions.

Q: In the lesson example, why can the production account launch a t2.micro instance?
A: Because the SCP deny condition only applies when the instance type is not t2.micro.

Q: Why does launching a t2.medium instance fail in the production account?
A: The SCP denies ec2:RunInstances when the instance type is not t2.micro.

Q: What should be used to restrict access in the management account?
A: IAM controls, MFA, monitoring, least privilege roles, root user protection, and other account-level governance controls.

Q: Why are SCPs useful in multi-account environments?
A: They enforce centralized governance guardrails across member accounts, even when local administrators have broad IAM permissions.

Practice Questions

Question 1:
A company uses AWS Organizations with separate OUs for Production and Development accounts. The cloud governance team wants to prevent all Production accounts from launching EC2 instances larger than a specific approved instance type. Developers in those accounts currently have IAM AdministratorAccess. What should the company do?

A. Remove AdministratorAccess from all developers and replace it with ReadOnlyAccess
B. Attach an SCP to the Production OU that denies ec2:RunInstances when the instance type is not approved
C. Attach an IAM permissions boundary to the AWS Organizations root
D. Add a resource-based policy to each EC2 instance

Correct Answer:
B. Attach an SCP to the Production OU that denies ec2:RunInstances when the instance type is not approved

Explanation:
An SCP attached to the Production OU applies to accounts inside that OU. An explicit deny in the SCP overrides IAM AdministratorAccess, making this the correct centralized governance control.

---

Question 2:
An administrator attaches an SCP to the root of an AWS Organization that denies launching all EC2 instance types except t2.micro. The administrator then logs into the management account and successfully launches a t2.medium instance. Why did this happen?

A. SCPs do not apply to the management account
B. SCPs only apply to IAM users, not IAM roles
C. SCPs only apply to billing actions
D. The FullAWSAccess policy overrides explicit denies

Correct Answer:
A. SCPs do not apply to the management account

Explanation:
SCPs do not restrict users or roles in the AWS Organizations management account. They apply to member accounts, OUs, and accounts beneath the organization hierarchy.

---

Question 3:
A user in a member account has an IAM policy allowing full EC2 access. An SCP attached to the account denies ec2:RunInstances. What happens when the user tries to launch an EC2 instance?

A. The launch succeeds because IAM allows EC2 access
B. The launch succeeds only if the user has AdministratorAccess
C. The launch fails because the SCP explicitly denies the action
D. The launch succeeds if FullAWSAccess is attached at the root

Correct Answer:
C. The launch fails because the SCP explicitly denies the action

Explanation:
SCPs define the maximum available permissions. If an SCP explicitly denies an action, the action is denied even if IAM allows it.

---

Question 4:
Which statement best describes the relationship between IAM policies and SCPs?

A. SCPs grant permissions, and IAM policies restrict them
B. IAM policies grant permissions, and SCPs define the maximum permissions available
C. SCPs and IAM policies are evaluated separately, and either one can allow access
D. SCPs only apply when IAM permissions are missing

Correct Answer:
B. IAM policies grant permissions, and SCPs define the maximum permissions available

Explanation:
IAM policies grant access to identities. SCPs act as organization-level guardrails that limit what permissions can be used in member accounts.

---

Question 5:
A company wants to start with all AWS services available in its member accounts and then block only specific risky actions, such as disabling security services or launching unapproved instance types. Which SCP strategy best fits this model?

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

Correct Answer:
B. Deny-list strategy

Explanation:
A deny-list strategy starts with broad access through FullAWSAccess and then uses explicit deny statements to block specific actions.