AWS Organizations Service Control Policies (SCPs) – SAP-C02 Study Guide

Purpose of This Lesson

Service Control Policies (SCPs) are organization-level guardrails in AWS Organizations. They define the maximum permissions available to identities in member accounts, helping centralize governance across development, production, and other organizational units (OUs).

SCPs are permission boundaries for AWS accounts—not permission grants. A user or role must still receive permission through an IAM identity policy, resource policy, or another applicable authorization mechanism.

Key Concepts

SCPs limit permissions; they do not grant them

An action is authorized only when both of these conditions are true:

1. The identity has the required IAM permissions.
2. No applicable SCP explicitly denies the action or excludes it from the account’s maximum permissions.

An SCP containing Allow does not give a user access by itself. It only defines what could be allowed by IAM.

For example, the following policy is commonly associated with the default FullAWSAccess SCP concept:

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

This does not make every principal an administrator. It permits IAM policies to grant actions, subject to any other restrictions.

SCPs apply to member accounts, OUs, and the organization hierarchy

SCPs can be attached to the organization root, an OU, or an individual member account. Policies attached higher in the hierarchy affect descendant OUs and accounts.

A typical structure might look like this:

Organization root
├── Development OU
│   └── Development account
└── Production OU
    └── Production account

An SCP attached to the organization root can affect all member accounts beneath it. An SCP attached to an OU affects accounts and child OUs within that OU. An SCP attached directly to an account affects only that member account.

SCPs do not restrict the management account

SCPs do not apply to principals in the AWS Organizations management account. This is an important distinction when designing centralized governance: critical workloads should run in member accounts, where SCP guardrails apply.

The management account should generally be protected through strong IAM controls, MFA, limited access, delegated administration, and operational procedures because it is not constrained by SCPs.

Explicit denies are powerful guardrails

An explicit Deny in an SCP overrides an Allow from an IAM policy. This makes SCPs useful for enforcing organization-wide restrictions such as:

• Preventing use of unsupported AWS Regions
• Blocking certain services or APIs
• Requiring encryption-related conditions
• Preventing changes to centralized logging
• Restricting resource creation to approved configurations

An explicit deny also affects administrators in member accounts. Having AdministratorAccess does not override an SCP deny.

Example: restricting EC2 instance types

A deny policy can prevent RunInstances unless the requested instance type is permitted. Conceptually, the policy uses a condition such as ec2:InstanceType and denies requests where the value does not equal t2.micro.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnapprovedInstanceTypes",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "ec2:InstanceType": "t2.micro"
        }
      }
    }
  ]
}

The exact policy design should be validated against the relevant EC2 condition keys and all resources involved in RunInstances. The important authorization behavior is that the deny propagates to descendant accounts and blocks the action even when the caller has broad IAM permissions.

A production account placed under an OU that inherits this policy would also be restricted unless a different hierarchy is used or the policy is removed or changed at the applicable level.

SCPs and tag policies are different

AWS Organizations tag policies help standardize tag keys, values, and tagging practices. They are not the same as SCPs and should not be treated as an authorization mechanism.

Use:

• SCPs for maximum-permission guardrails and explicit organization-level denies.
• Tag policies for tag standardization and governance.
• IAM policies for granting permissions to users and roles.

Exam-Relevant Takeaways

• SCPs define the maximum permissions available in member accounts.
• SCPs never grant permissions by themselves.
• IAM permissions are still required for an action to succeed.
• An explicit SCP deny overrides IAM allows, including AdministratorAccess in a member account.
• SCPs attached to the root or an OU flow down to descendant OUs and accounts.
• SCPs do not apply to the AWS Organizations management account.
• The default organization configuration typically includes an allow-all SCP, but it does not grant access to every principal.
• A restrictive SCP must be considered for every account beneath its attachment point.
• Tag policies standardize tags; they do not replace SCPs or IAM authorization.
• Removing an explicit deny does not automatically grant access. The caller must still have a suitable IAM permission.

Architecture Decision Guide

Requirement	Appropriate control	Important detail
Grant a developer permission to launch EC2 instances	IAM identity policy or role policy	The SCP must also permit the action.
Prevent all member accounts from using a Region	SCP attached at the organization root or suitable OU	Use an explicit deny with an appropriate Region condition.
Restrict a production OU to approved services	SCP attached to the production OU	The restriction propagates to child accounts.
Ensure administrators cannot delete centralized logging	SCP explicit deny	Member-account administrators cannot override it.
Standardize required tag keys and values	AWS Organizations tag policy	Tag policies are separate from authorization controls.
Protect the organization management account	MFA, tightly controlled IAM, separation of duties, monitoring	SCPs do not restrict the management account.
Permit a specific API only after IAM grants it	Allow in SCP plus IAM permission	An SCP allow is not an authorization grant.

Common Exam Traps

• Assuming an SCP grants access: An allow statement in an SCP does not provide permissions to a user or role.
• Assuming AdministratorAccess bypasses SCPs: Administrators in member accounts remain subject to SCPs.
• Applying SCP logic to the management account: SCPs do not restrict the management account.
• Overlooking inheritance: A deny attached to a parent OU affects accounts in child OUs.
• Confusing tag policies with SCPs: Tag policies address tag governance, not general API authorization.
• Assuming a child OU can override a parent deny: A lower-level allow cannot counteract an explicit deny inherited from a parent.
• Assuming an SCP deny is enough to enable an action: Once the deny is removed, IAM permissions are still necessary.
• Ignoring policy scope: An SCP attached to one OU or account does not automatically affect unrelated branches of the organization.

Real-World Engineer Notes

• Design SCPs centrally and test them in a dedicated organizational branch before broad rollout. A deny on a shared API can affect deployments, automation, and incident response.
• Keep emergency access procedures separate from assumptions about account administrators. An administrator cannot recover from an SCP deny within the affected member account.
• Use narrow conditions and carefully review API documentation. Actions such as ec2:RunInstances can involve multiple resource types and condition keys.
• Treat the management account as a high-value control plane account, not as a normal workload account.
• Use AWS Organizations policy simulation, IAM Access Analyzer capabilities, CloudTrail, and staged deployment processes to validate the practical effect of organization guardrails.
• Document which OUs inherit each SCP. Organizational restructuring can unintentionally move accounts under a restrictive policy.
• Prefer explicit organization-wide denies for non-negotiable controls and use IAM roles for day-to-day access grants.

Quick Reference Summary

• SCP purpose: Limit the maximum permissions in member accounts.
• Permission grant: IAM or another applicable AWS authorization policy.
• Explicit deny: Overrides IAM allows in affected member accounts.
• Inheritance: Root and OU policies apply to descendant OUs and accounts.
• Management account: Not restricted by SCPs.
• Administrators: Subject to SCPs when operating in member accounts.
• Tag policy: Standardizes tags; it is not an SCP.
• Core evaluation idea: Required IAM permission plus no applicable SCP denial.

Flashcards

1. Q: What does an SCP control?

A: The maximum permissions available to principals in member accounts.

1. Q: Does an SCP grant permissions?

A: No. IAM or another applicable policy must grant the permission.

1. Q: What happens when an SCP explicitly denies an action allowed by IAM?

A: The action is denied.

1. Q: Are member-account administrators exempt from SCPs?

A: No. SCPs can restrict administrators in member accounts.

1. Q: Do SCPs restrict the Organizations management account?

A: No.

1. Q: What is the effect of attaching an SCP to an OU?

A: It affects accounts in that OU and descendant OUs.

1. Q: Can an IAM Allow override an inherited SCP Deny?

A: No.

1. Q: Can an SCP Allow compensate for missing IAM permission?

A: No.

1. Q: What service policy helps standardize tags across an organization?

A: AWS Organizations tag policies.

1. Q: What is a common use for an SCP explicit deny?

A: Blocking unapproved Regions, services, APIs, or resource configurations across member accounts.

Practice Questions

Question 1

A company grants AdministratorAccess to a role in every development account. Security attaches an SCP to the Development OU that denies ec2:RunInstances when ec2:InstanceType is not t2.micro. What happens when the role attempts to launch a m5.large instance?

Correct answer: The request is denied.

Explanation: An explicit SCP deny overrides the IAM administrator allow. The policy is attached to the OU, so it affects accounts beneath that OU.

Question 2

A user in a member account receives an IAM policy allowing s3:CreateBucket. The account has an inherited SCP containing only an allow for EC2 actions. What is the result when the user tries to create an S3 bucket?

Correct answer: The request is denied because the SCP does not allow the S3 action within the account’s maximum permissions.

Explanation: The user needs IAM permission and the action must also be permitted by the applicable SCP set. An SCP allow is not a grant, but an SCP that does not provide the required allowed path can restrict the action.

Question 3

An organization attaches an SCP denying use of a specific AWS Region to the organization root. A new account is created under a child OU. Which accounts are affected?

Correct answer: All applicable member accounts under that organization root, including the new account.

Explanation: Policies attached at the root flow down through OUs to member accounts. The restriction also applies to administrators operating in those member accounts.

Question 4

A security architect wants to enforce a standard set of cost-center and environment tags across accounts. Which AWS Organizations feature is most directly suited to this requirement?

Correct answer: An Organizations tag policy.

Explanation: Tag policies govern tag standardization. SCPs are intended to limit permissions and deny actions, not to define the organization’s tagging standard.