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

Purpose of This Lesson

Service Control Policies (SCPs) provide organization-level guardrails for AWS accounts. They define the maximum permissions available to principals in member accounts, including users and roles with administrator access.

This hands-on pattern demonstrates how to:

• Enable and use SCPs in AWS Organizations.
• Create an organizational unit (OU) for production accounts.
• Move a member account into the OU.
• Create an SCP that denies modification of a specific IAM role.
• Attach the SCP to the OU so that it applies to the account inside it.
• Verify that the deny overrides account-level administrator permissions.

An SCP is a governance control. It does not grant permissions by itself.

Key Concepts

SCPs define permission boundaries for accounts

An SCP controls the maximum permissions that IAM principals in member accounts can use. The effective permission for an action depends on both:

1. An IAM identity-based or resource-based policy allowing the action.
2. The applicable SCPs permitting the action.

A simplified model is:

Effective permission = IAM permissions ∩ SCP permissions

If an SCP contains an explicit Deny, the action is blocked even when the principal has AdministratorAccess.

SCPs do not provide permissions. An account still needs IAM policies that allow the action.

The default FullAWSAccess policy

When SCPs are enabled, AWS Organizations commonly uses the FullAWSAccess policy as the initial baseline. This permits actions unless another SCP introduces a restriction.

This is a deny-list approach:

• Keep broad access through FullAWSAccess.
• Add targeted explicit denies for prohibited actions.

A more restrictive allow-list model can be designed by replacing broad access with SCPs that explicitly allow only approved services or actions. That approach requires careful testing because any missing allow can block workloads.

Organizational unit inheritance

SCPs can be attached to the organization root, an OU, or an individual account. Policies attached to a parent OU apply to accounts beneath that OU.

For example:

Organization root
└── Prod OU
    └── Production account

An SCP attached to Prod applies to the production account. Moving an account to a different OU can therefore change its effective governance controls.

Explicit deny of IAM role changes

A common governance pattern is to protect a security, operations, or break-glass role from modification. An SCP can deny actions such as:

• iam:AttachRolePolicy
• iam:DeleteRole
• iam:DeleteRolePermissionsBoundary
• iam:DetachRolePolicy
• Other IAM APIs that could alter or remove the protected role

The policy should target the role with its ARN in the Resource element. Restricting the resource is safer than denying the IAM actions for every role in the account.

Example pattern:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyModificationOfProtectedRole",
      "Effect": "Deny",
      "Action": [
        "iam:AttachRolePolicy",
        "iam:DeleteRole",
        "iam:DeleteRolePermissionsBoundary",
        "iam:DetachRolePolicy",
        "iam:PutRolePermissionsBoundary",
        "iam:UpdateAssumeRolePolicy"
      ],
      "Resource": "arn:aws:iam::111122223333:role/ProtectedRole"
    }
  ]
}

The exact action list must match the ways an attacker or administrator could alter the role. Protecting only one API may leave alternative modification paths open.

Management account behavior

SCPs apply to member accounts, not the AWS Organizations management account. Critical organization-wide controls should therefore be designed with the management account’s separate security posture in mind.

The management account should have tightly restricted access, strong MFA, centralized logging, and carefully controlled administrative roles.

Exam-Relevant Takeaways

• An SCP is a permissions boundary for accounts in AWS Organizations; it does not grant permissions.
• An explicit deny in an applicable SCP overrides an IAM allow, including AdministratorAccess.
• SCPs can be attached to the organization root, an OU, or an account.
• Policies attached to an OU apply to accounts in that OU and can affect accounts when they are moved.
• The default FullAWSAccess policy supports a deny-list strategy until additional restrictions are attached.
• To protect a specific IAM role, target its ARN rather than denying all IAM role operations account-wide.
• A member-account administrator cannot bypass an SCP by adding another IAM policy.
• SCPs do not affect the management account, so it requires separate controls.
• If an SCP blocks an action, removing or changing the SCP requires authorization in the organization management account or a delegated administrator with appropriate Organizations permissions.
• Test SCPs in a nonproduction account before applying them to a production OU.

Architecture Decision Guide

Requirement	Recommended SCP design	Important consideration
Block a dangerous operation everywhere	Attach an explicit-deny SCP to the organization root	It affects every member account; validate exceptions first
Apply controls only to production	Create a Prod OU and attach the SCP there	Moving an account changes its inherited controls
Protect one IAM role	Deny relevant IAM modification APIs with the role ARN as Resource	Include all meaningful modification and deletion paths
Permit most services but block a few	Retain FullAWSAccess and add targeted denies	This is simpler but requires identifying bypass paths
Restrict accounts to an approved service set	Use carefully designed allow-list SCPs	Missing an allow can break dependencies and operations
Prevent account administrators from removing guardrails	Manage the SCP from the organization management account or delegated administration model	Member-account administrators cannot override an SCP
Validate a new restriction	Apply it to a test OU or account first	Check deployment, logging, backup, support, and security workflows

Common Exam Traps

Confusing SCPs with IAM policies

An SCP does not grant access to Amazon S3, IAM, or any other service. An IAM policy must still allow the action. An SCP only limits the maximum available permissions.

Assuming administrator access bypasses an SCP

AdministratorAccess is still subject to explicit denies in applicable SCPs. A member-account administrator cannot override an organization-level deny with an IAM policy.

Applying an SCP to the wrong location

An SCP attached to an OU affects only accounts in that OU and its child OUs. An SCP attached to an individual account does not automatically apply to sibling accounts.

Forgetting policy inheritance

A restrictive SCP on the root or a parent OU can block actions in every descendant account. Account-level troubleshooting must include inherited policies, not just policies visible at the account itself.

Protecting a role incompletely

Denying iam:DeleteRole alone may not prevent an administrator from detaching policies, changing the trust policy, or modifying the permissions boundary. The deny statement should cover all relevant modification paths.

Expecting SCPs to protect the management account

SCPs do not restrict the management account. Separate IAM, MFA, logging, and operational controls are required.

Using a broad deny without considering service dependencies

A deny on an API or service can disrupt deployment pipelines, AWS Backup, security tooling, or automation. Prefer narrowly scoped resources and conditions where practical.

Real-World Engineer Notes

• Use separate OUs for organizational intent, such as Security, Infrastructure, Prod, NonProd, and Sandbox.
• Keep SCPs modular and named by control purpose, such as DenyUnsupportedRegions or ProtectSecurityRoles.
• Store policy JSON in version control and review changes through a controlled process.
• Use AWS CloudTrail and AWS Organizations activity to investigate denied operations and policy changes.
• Include automation roles in the design. A policy that blocks a role modification may also block legitimate provisioning or rotation workflows.
• Protect break-glass roles, but ensure the organization has a documented and tested recovery process for changing the SCP.
• Prefer conditions such as aws:PrincipalArn, aws:RequestedRegion, or resource tags when they produce a more precise control.
• SCPs are one layer of governance. Combine them with IAM controls, AWS IAM Identity Center, AWS Config, CloudTrail, centralized security services, and preventive or detective controls in AWS Control Tower.

Quick Reference Summary

• Purpose: Limit the maximum permissions available in member accounts.
• Scope: Organization root, OU, or account.
• Inheritance: Parent policies apply to descendant accounts and OUs.
• Default baseline: FullAWSAccess commonly enables a deny-list model.
• Explicit deny: Overrides IAM allows, including administrator permissions.
• Granting access: Still requires IAM policies; SCPs never grant access.
• Role protection: Deny all relevant IAM modification APIs for the protected role ARN.
• Management account: Not governed by SCPs.
• Operational practice: Test in a lower-risk OU before production deployment.

Flashcards

1. What does an SCP do?

It defines the maximum permissions available to IAM principals in member accounts.

1. Does an SCP grant permissions?

No. IAM policies must still allow the action.

1. What wins when an SCP explicitly denies an action but IAM allows it?

The explicit SCP deny wins.

1. Can AdministratorAccess bypass an SCP?

No, not when the applicable SCP explicitly denies the action.

1. Where can an SCP be attached?

To the organization root, an OU, or an individual account.

1. What happens when an account moves between OUs?

Its inherited SCPs can change according to the destination OU hierarchy.

1. What is the purpose of FullAWSAccess in a deny-list design?

It provides broad baseline access while additional SCPs explicitly deny prohibited actions.

1. Which account is not affected by SCPs?

The AWS Organizations management account.

1. How should an SCP protect one IAM role instead of every role?

Set the protected role ARN as the policy resource.

1. Why might denying only iam:DeleteRole be insufficient?

The role could still be altered through policy attachment, trust-policy changes, boundary changes, or other IAM APIs.

1. What happens if an SCP blocks an action but no IAM policy allows it anyway?

The action remains unauthorized; both IAM permission and SCP permission are required.

1. Why test an SCP in a nonproduction OU?

To identify blocked dependencies and operational workflows before affecting production accounts.

Practice Questions

Question 1

A security architect must prevent administrators in all production accounts from deleting a centrally managed IAM role. Administrators currently have AdministratorAccess. What is the most effective solution?

A. Add an explicit deny to the role’s identity policy.
B. Attach an SCP to the production OU that denies relevant IAM modification actions for the role ARN.
C. Remove AdministratorAccess from all administrators.
D. Add a permissions boundary to each administrator that allows only read-only IAM actions.

Correct answer: B

Explanation: An SCP attached to the production OU applies to member accounts beneath it and overrides IAM allows through an explicit deny. Targeting the role ARN avoids unnecessarily blocking changes to unrelated roles.

Question 2

An organization has FullAWSAccess attached to the root. It wants to block the use of a particular AWS service in a sandbox OU while leaving other services available. Which approach best matches a deny-list strategy?

A. Remove all IAM policies from users in the sandbox accounts.
B. Attach an SCP to the sandbox OU with an explicit deny for the service actions.
C. Add an allow-only SCP to the management account.
D. Create a permissions boundary for every role in the sandbox accounts.

Correct answer: B

Explanation: With broad baseline access retained, a targeted explicit-deny SCP at the sandbox OU blocks the selected service for accounts in that OU. IAM changes alone do not provide an organization-level guardrail.

Question 3

An administrator in a member account cannot attach a policy to an IAM role. The administrator has AdministratorAccess, and IAM policy simulation shows an allow. What should be checked first?

A. Whether the role has a permissions boundary.
B. Whether the account is governed by an SCP with an explicit deny for the operation.
C. Whether the management account has FullAWSAccess.
D. Whether the user is in the same AWS Region as the role.

Correct answer: B

Explanation: An applicable SCP can explicitly deny the IAM API despite the administrator’s IAM permissions. The account’s OU and inherited SCPs should be inspected.

Question 4

A company attaches a restrictive SCP to the organization root and discovers that the organization management account can still perform the blocked action. What explains this behavior?

A. Root-level SCPs apply only to the root user.
B. The management account is not affected by SCPs.
C. SCPs apply only to IAM users, not roles.
D. FullAWSAccess always overrides explicit denies.

Correct answer: B

Explanation: SCPs govern member accounts. The management account requires separate IAM and governance controls.

Question 5

A production account is moved from the Prod OU to a general-purpose OU. The account can now perform an operation that was previously denied. What is the most likely cause?

A. SCPs are evaluated only once when an account is created.
B. The account no longer inherits the restrictive SCP attached to the Prod OU.
C. Moving an account automatically removes all IAM policies.
D. SCPs cannot deny administrator actions.

Correct answer: B

Explanation: OU membership determines inherited SCPs. Moving the account can remove controls attached only to the former OU, changing its effective permissions.