AWS Organizations Service Control Policies (SCPs) and Permission Guardrails

Purpose of This Lesson

Service Control Policies, or SCPs, are an AWS Organizations feature used to centrally control the maximum available permissions across AWS member accounts. For the SAP-C02 exam, SCPs matter because many scenario questions involve multi-account governance, least privilege, account guardrails, production versus development restrictions, and preventing risky actions across an AWS Organization.

SCPs do not grant permissions by themselves. They act as permission boundaries at the AWS account, OU, or organization root level. A user or role still needs IAM permissions, but the action must also be allowed by the applicable SCP path. AWS describes SCPs as guardrails that define the maximum actions IAM users and roles can perform in member accounts.

Key Concepts

What Is a Service Control Policy?

A Service Control Policy is an AWS Organizations policy type that limits what actions are available inside AWS member accounts.

Think of an SCP as the outer permission boundary for an account.

IAM permissions answer:

“Does this user, role, or resource policy grant permission to perform the action?”

SCPs answer:

“Is this action even allowed to be used in this AWS account?”

Both must allow the action. If IAM allows ec2:RunInstances but an SCP denies it, the user cannot launch the instance.

SCPs are available only when AWS Organizations is configured with all features enabled, not just consolidated billing.

SCPs Do Not Grant Permissions

A very important exam point is that an SCP with this statement does not give users administrator access:

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

In an IAM policy, that would grant broad access. In an SCP, it only means the organization is not restricting those actions at that level.

A user, group, or role still needs IAM permissions to actually perform actions. AWS states that SCPs never grant permissions; they only define the maximum available permissions.

FullAWSAccess and the Default AWS Organizations Behavior

When SCPs are enabled, AWS attaches the AWS-managed FullAWSAccess SCP by default. This policy allows all services and actions from an SCP perspective.

That does not mean every user has full access. It means AWS Organizations is not limiting the account through SCPs.

If you remove FullAWSAccess and do not replace it with another allow policy, member accounts under that part of the hierarchy can lose the ability to perform AWS actions. AWS specifically warns not to remove FullAWSAccess unless it is replaced with another policy that allows the required actions.

AWS Organizations Hierarchy

AWS Organizations uses a hierarchy:

Organization root
Management account
Organizational units
AWS member accounts

The management account sits at the top of the organization. Under the organization root, you can create OUs such as:

Root
├── Security OU
├── Infrastructure OU
├── Development OU
│   └── Dev Account
└── Production OU
    └── Prod Account

SCPs can be attached to:

• The organization root
• Organizational units
• Individual member accounts

The effective SCP permissions for an account are based on the policies attached along the path from the root down to that account.

SCP Inheritance and Evaluation

For an action to be allowed in a member account, the action must be allowed at every level in the path from the organization root to the account. If an allow is missing at any level, the action is denied by default.

For example:

Root
└── Development OU
    └── Dev Account

If ec2:* is allowed at the root but not allowed at the Development OU level, the Dev Account cannot use EC2 actions.

This is why SCP inheritance can be tricky. It is not enough to look only at the account-level SCP. You must evaluate the full hierarchy.

Explicit Deny Always Wins

An explicit deny in an SCP overrides an allow.

If a parent OU has an SCP that denies ec2:RunInstances, then accounts under that OU cannot launch EC2 instances, even if the account has another SCP allowing EC2 and the IAM user has AdministratorAccess.

AWS confirms that a deny policy attached at any level in the organization path affects accounts underneath it.

Example: Restricting EC2 Instance Types

A common SCP example is restricting development accounts to small instance types.

Example concept:

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "ec2:InstanceType": "t2.micro"
    }
  }
}

This policy says:

Deny ec2:RunInstances if the requested EC2 instance type is not t2.micro.

That means a user can launch a t2.micro instance only if IAM also allows the launch. If the user tries to launch a larger instance, such as m5.large, the SCP blocks it.

For the exam, focus less on the specific instance type and more on the pattern:

Use SCPs to enforce organization-wide or OU-wide guardrails, such as blocking expensive instance types, restricting regions, preventing security logging changes, or denying use of unapproved services.

Management Account Is Not Restricted by SCPs

SCPs do not affect users or roles in the AWS Organizations management account. They affect only member accounts. This is one reason AWS best practice is to avoid running normal workloads or creating everyday administrative users directly in the management account.

In a mature AWS environment, the management account should be treated as a highly protected administrative account. Identity, security tooling, logging, production workloads, and development workloads are usually separated into dedicated member accounts.

SCPs Also Affect the Root User in Member Accounts

SCPs apply to IAM users and roles in member accounts, and they also restrict the member account root user. This is powerful because it allows central governance over accounts even if someone has high local privileges inside a member account.

However, SCPs do not affect actions performed by the management account.

SCPs and Service-Linked Roles

SCPs do not restrict service-linked roles. Service-linked roles are used by AWS services to perform required actions on behalf of the service. AWS documents service-linked roles as an exception to SCP restrictions.

This is an important exam trap. An SCP can restrict normal IAM principals in member accounts, but it does not block every AWS-controlled service-linked role behavior.

Tag Policies Versus SCPs

AWS Organizations also supports tag policies. Tag policies are used to standardize tags across AWS accounts, such as enforcing consistent capitalization or approved values for keys like CostCenter, Environment, or Project.

SCPs and tag policies solve different problems.

SCPs control what actions are allowed.

Tag policies control tagging standards and tag compliance.

Example:

An SCP could prevent users from launching EC2 instances outside approved regions.

A tag policy could standardize the Environment tag so teams use Production, Development, and Test consistently.

Tag policies can help with cost allocation, automation, governance, and reporting, but they are not the same thing as IAM permissions or SCP permission guardrails.

Exam-Relevant Takeaways

SCPs define the maximum permissions available in AWS member accounts.

SCPs do not grant access. IAM policies, resource policies, and other permissions mechanisms still grant access.

An action must be allowed by IAM and allowed by the applicable SCPs.

Explicit deny in an SCP overrides allow.

SCPs are inherited through the AWS Organizations hierarchy.

A permission must be allowed at every level from the root through each OU down to the account.

The default FullAWSAccess SCP allows all AWS actions from an SCP perspective, but it does not grant IAM access.

Do not remove FullAWSAccess unless you replace it with a policy that allows required services and actions.

SCPs do not affect users or roles in the management account.

SCPs do affect IAM users, IAM roles, and the root user in member accounts.

SCPs do not restrict service-linked roles.

Use SCPs for centralized guardrails, especially in multi-account AWS environments.

Use tag policies for tag standardization, not permission control.

Architecture Decision Guide

Scenario	Best AWS Choice	Why
Prevent development accounts from launching large EC2 instances	SCP attached to Development OU	Centrally enforces a maximum permission guardrail across all dev accounts
Grant a developer permission to launch EC2 instances	IAM policy	SCPs do not grant permissions; IAM grants the actual access
Prevent all member accounts from disabling security services	SCP attached at root or security-related OU	Explicit deny can block risky actions across many accounts
Standardize tags like CostCenter and Environment	AWS Organizations tag policy	Tag policies help enforce consistent tag keys, values, and capitalization
Give all member accounts unrestricted SCP-level access	FullAWSAccess SCP	Allows all actions from the SCP perspective while IAM still controls actual access
Restrict only one account without impacting sibling accounts	SCP attached directly to that account	Limits blast radius compared to attaching the SCP at a parent OU
Apply a guardrail to every account under an OU	SCP attached to the OU	SCP inheritance applies the restriction to accounts under that OU
Restrict users in the management account	Do not rely on SCPs; use IAM, account separation, and best practices	SCPs do not affect users or roles in the management account
Block expensive AWS services across the organization	SCP deny list	A deny list can prevent usage of specific services even if IAM allows them
Build an allow-only AWS service model	SCP allow list	More restrictive, but requires careful planning because missing allows cause access denial

Common Exam Traps

Do not assume an SCP grants permissions. An SCP with Allow: * only means the SCP is not restricting those actions.

Do not forget IAM. Even if the SCP allows an action, the principal still needs IAM permission.

Do not overlook hierarchy. If an action is denied at the root or parent OU, it is denied in child OUs and accounts.

Do not assume an account-level allow overrides a parent-level deny. Explicit deny always wins.

Do not remove FullAWSAccess casually. If you remove it without replacing the required allows, member accounts may lose access to AWS services.

Do not expect SCPs to restrict the management account. SCPs apply to member accounts, not users or roles in the management account.

Do not confuse tag policies with SCPs. Tag policies standardize tagging. SCPs restrict permissions.

Do not forget the root user in member accounts. SCPs can restrict the root user of a member account.

Do not assume SCPs affect service-linked roles. They do not.

Do not attach broad deny policies at the organization root without testing. A root-level deny affects all member accounts beneath it.

Real-World Engineer Notes

In a real AWS environment, SCPs are one of the most important controls for multi-account governance. They are especially useful when accounts are delegated to application teams, developers, vendors, or business units.

A common real-world pattern is to use OUs for account grouping:

Root
├── Security
├── Log Archive
├── Shared Services
├── Infrastructure
├── Workloads
│   ├── Production
│   └── NonProduction
└── Sandbox

Then SCPs are applied based on risk.

For example, sandbox accounts may deny expensive instance families, GPU instances, or certain regions. Production accounts may deny disabling CloudTrail, AWS Config, GuardDuty, Security Hub, or centralized logging integrations. Security accounts may have fewer restrictions but tighter access control through IAM and privileged access workflows.

From an operations perspective, SCP changes should be treated like firewall rule changes or GPO changes in a Windows domain. They can break production if applied too broadly. Always test SCPs against a small OU or test account before applying them to a larger OU or the root.

For troubleshooting, when a user says, “I have AdministratorAccess but I still get AccessDenied,” check SCPs. In AWS, AdministratorAccess in IAM is not always enough. The account may be restricted by an inherited SCP.

For governance, SCPs are useful for enforcing rules that should not be optional, such as:

Prevent leaving the AWS Organization
Prevent disabling CloudTrail
Prevent deleting centralized log buckets
Prevent creating resources in unapproved regions
Prevent launching unapproved EC2 instance types
Prevent use of services not approved by security or finance
Prevent changes to AWS Config or GuardDuty

For cost control, SCPs can prevent expensive mistakes. Restricting instance families, regions, or services in development accounts can reduce surprise bills.

For security, SCPs should complement IAM, not replace it. IAM still controls user and role access inside each account. SCPs provide the outer guardrail.

Quick Reference Summary

SCP stands for Service Control Policy.

SCPs are configured in AWS Organizations.

SCPs define maximum available permissions for member accounts.

SCPs do not grant permissions.

IAM grants permissions; SCPs limit permissions.

Explicit deny always overrides allow.

Allow must exist at every level in the organization path.

The default FullAWSAccess SCP allows all services and actions from the SCP perspective.

Removing FullAWSAccess without replacement can break access.

SCPs affect member accounts, including the member account root user.

SCPs do not affect users or roles in the management account.

SCPs do not restrict service-linked roles.

Tag policies standardize tags; SCPs control permissions.

Use SCPs for organization-wide guardrails, governance, security, and cost control.

Flashcards

Q: What is the purpose of an AWS Organizations Service Control Policy?
A: An SCP defines the maximum available permissions for IAM users and roles in AWS member accounts.

Q: Does an SCP grant permissions to users or roles?
A: No. SCPs do not grant permissions. IAM or resource-based policies must grant the actual access.

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

Q: What is the default AWS-managed SCP called?
A: FullAWSAccess.

Q: What does FullAWSAccess do in AWS Organizations?
A: It allows all AWS services and actions from the SCP perspective, but it does not grant IAM permissions.

Q: What happens if FullAWSAccess is removed without a replacement allow policy?
A: Member accounts under that hierarchy may be blocked from performing AWS actions.

Q: Do SCPs apply to the AWS Organizations management account?
A: No. SCPs do not affect users or roles in the management account.

Q: Do SCPs apply to member account root users?
A: Yes. SCPs can restrict the root user in member accounts.

Q: Do SCPs restrict service-linked roles?
A: No. SCPs do not affect service-linked roles.

Q: If a parent OU denies an action, can a child account SCP allow it again?
A: No. An explicit deny at a higher level cannot be overridden by a lower-level allow.

Q: What must be true for an action to be allowed through SCP evaluation?
A: The action must be explicitly allowed at every level from the root through each OU to the account, and it must not be explicitly denied.

Q: What AWS Organizations policy type is used to standardize tag keys and values?
A: Tag policies.

Q: What is a common SCP use case for development accounts?
A: Restricting expensive services, regions, or EC2 instance types.

Q: Why should SCPs be tested before applying them broadly?
A: A restrictive SCP can unintentionally block required AWS actions across many accounts.

Q: In troubleshooting, what should you check if a user has AdministratorAccess but still receives AccessDenied?
A: Check inherited SCPs, permission boundaries, resource policies, and other policy layers.

Practice Questions

Question 1:
A developer in a member account has an IAM policy allowing ec2:RunInstances. The account is under an OU with an SCP that denies ec2:RunInstances unless the instance type is t2.micro. The developer attempts to launch an m5.large instance. What happens?

A. The launch succeeds because IAM allows the action
B. The launch fails because the SCP denies the action
C. The launch succeeds because SCPs only apply to root users
D. The launch fails only if the account-level SCP also denies the action

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

Explanation:
IAM grants the user permission, but the SCP sets the maximum allowed permissions for the account. Since the requested instance type does not meet the SCP condition, the explicit deny blocks the launch.

---

Question 2:
An organization administrator attaches an SCP with Allow: * to an OU. A new IAM user in an account under that OU has no IAM policies attached. What can the user do?

A. The user can perform all AWS actions
B. The user can perform only read-only AWS actions
C. The user cannot perform actions until IAM permissions are granted
D. The user automatically receives AdministratorAccess

Correct Answer:
C. The user cannot perform actions until IAM permissions are granted.

Explanation:
SCPs do not grant permissions. They only define the maximum available permissions. IAM permissions are still required.

---

Question 3:
A company wants to prevent all accounts in its Production OU from disabling AWS security logging services, even if local account administrators have broad IAM permissions. Which design is best?

A. Attach an IAM policy to each administrator allowing all services
B. Attach an SCP with explicit deny statements to the Production OU
C. Use a tag policy to prevent logging changes
D. Remove all IAM users from the production accounts

Correct Answer:
B. Attach an SCP with explicit deny statements to the Production OU.

Explanation:
SCPs are designed for centralized guardrails across AWS member accounts. An explicit deny in an SCP overrides IAM allows in the affected accounts.

---

Question 4:
A company wants to enforce consistent use of the CostCenter and Environment tags across AWS accounts. Which AWS Organizations feature is most appropriate?

A. Service Control Policy
B. Tag policy
C. IAM permissions boundary
D. AWS Config only

Correct Answer:
B. Tag policy.

Explanation:
Tag policies are used to standardize tag keys, values, and capitalization across accounts. SCPs are used to restrict permissions.

---

Question 5:
Which statement about SCPs and the AWS Organizations management account is correct?

A. SCPs restrict all users and roles in the management account
B. SCPs restrict only the root user in the management account
C. SCPs do not affect users or roles in the management account
D. SCPs apply only when IAM Identity Center is enabled

Correct Answer:
C. SCPs do not affect users or roles in the management account.

Explanation:
SCPs affect member accounts in the organization. They do not restrict users or roles in the management account.