This chapter covers AWS Organizations and Service Control Policies (SCPs), a critical topic for the SOA-C02 exam under Domain 4: Security, Objective 4.1. Organizations allow you to centrally govern multiple AWS accounts as a group, while SCPs provide fine-grained permission guardrails. Expect 3-5 exam questions on this topic, often focusing on SCP evaluation logic, the difference between allow lists and deny lists, and integration with IAM. Mastering these concepts is essential for designing secure multi-account architectures.
Jump to a section
Think of a large corporate holding company, like Berkshire Hathaway, which owns multiple subsidiary companies (e.g., GEICO, Duracell). Each subsidiary operates independently with its own bank accounts, policies, and employees. However, the parent company sets overarching rules: no subsidiary may take on debt beyond a certain limit, all subsidiaries must use the same accounting software, and executives must approve any acquisition over $10 million. These rules are enforced through a central compliance department that audits each subsidiary's books and can freeze accounts if violations occur. In AWS Organizations, the parent company is the management account (formerly master account), and subsidiaries are member accounts. Service Control Policies (SCPs) are the central compliance rules: they define which AWS services and actions are allowed or denied across all accounts, regardless of what IAM policies within each account say. Just as a subsidiary's internal policies cannot override the holding company's rules, IAM policies in member accounts cannot allow actions that an SCP denies. The management account itself is exempt from SCPs, like the holding company's own headquarters not being bound by the same compliance rules it imposes on subsidiaries. Organizations also supports consolidated billing, akin to the holding company paying all subsidiaries' expenses from a central treasury, and using volume discounts (like Reserved Instances) across the entire group.
What is AWS Organizations?
AWS Organizations is a service that enables you to consolidate multiple AWS accounts into an organization that you create and centrally manage. It provides hierarchical grouping of accounts using Organizational Units (OUs) and enables policy-based management across accounts. The service is free to use and is a foundational component for multi-account strategies. Organizations was launched in 2016 and has evolved to support features like consolidated billing, account creation via API, and SCPs.
Why Use AWS Organizations?
Before Organizations, managing multiple accounts required separate billing, manual cross-account IAM roles, and inconsistent security policies. Organizations solves these problems by providing: - Consolidated Billing: All accounts' usage is aggregated, allowing you to benefit from volume discounts and Reserved Instance sharing. - Centralized Account Management: Create and manage accounts programmatically. - Policy-Based Governance: Apply SCPs to restrict actions across accounts. - Single Sign-On Integration: Use AWS SSO to manage user access across accounts.
Key Components
Management Account: The account that creates the organization. It has full administrative control and is not affected by SCPs. There can only be one management account per organization.
Member Accounts: All other accounts in the organization. They are subject to SCPs and can be organized into OUs.
Organizational Units (OUs): Logical containers for grouping accounts. OUs can be nested up to five levels deep. Policies applied to an OU flow down to all child OUs and accounts.
Service Control Policies (SCPs): JSON policies that specify the maximum permissions for member accounts. They do not grant permissions; they define a guardrail that IAM policies cannot exceed.
Root: The top-level container for all accounts in the organization. Policies attached to the root affect the entire organization.
How SCPs Work – The Evaluation Logic
SCPs are evaluated before IAM policies. The effective permissions for a principal in a member account are the intersection of the SCP allow set and the IAM allow set. In other words, an action is allowed only if it is allowed by both the SCP and the IAM policy. The default SCP is FullAWSAccess, which allows all actions. When you attach a custom SCP, you must either explicitly allow actions (allow list) or explicitly deny actions (deny list). Crucially, an explicit deny in an SCP overrides any allow, similar to IAM.
SCPs support two strategies:
- Allow List: Start by denying everything (attach a Deny-All SCP), then attach SCPs that explicitly allow specific services/actions. This is more restrictive and secure.
- Deny List: Start with the default FullAWSAccess (allow all), then attach SCPs that explicitly deny certain actions. This is more permissive and common for gradual restriction.
SCP Syntax and Examples
SCPs use the IAM policy language, but with a few differences:
The Principal element is not used; SCPs apply to all principals in the account.
The Effect can be Allow or Deny.
The Action element specifies service actions (e.g., ec2:*).
The Resource element typically uses "*" but can be specific for some services.
The Condition element works similarly to IAM.
Example Deny List SCP – Deny terminating EC2 instances:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:TerminateInstances",
"Resource": "*"
}
]
}Example Allow List SCP – Allow only S3 and DynamoDB:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": ["s3:*", "dynamodb:*"],
"Resource": "*"
}
]
}Note: In an allow list, you must first explicitly deny all actions, then allow the desired ones. The deny-all statement ensures that any action not explicitly allowed is denied.
SCP Effects on IAM Policies
An IAM policy in a member account cannot grant permissions that are not allowed by the SCP. For example, if an SCP denies ec2:RunInstances, even if an IAM policy explicitly allows it, the action is denied. However, if an SCP allows ec2:*, an IAM policy can further restrict permissions. This is why SCPs are described as "permission guardrails" – they set the upper boundary.
Important Defaults and Limits
Maximum number of SCPs per organization: 1,000.
Maximum number of SCPs per account/OU/root: 5.
Maximum policy document size: 5,120 characters (including whitespace).
Maximum nesting depth of OUs: 5 levels.
Maximum number of accounts in an organization: Default is 10, but can be increased via support ticket.
SCPs do not affect the management account: The management account has full access regardless of SCPs.
SCPs do not affect resource-based policies: For example, an S3 bucket policy that grants access to a user in another account is not restricted by SCPs (only by the resource-based policy and IAM).
SCPs do not affect service-linked roles: These roles are created by AWS services and are exempt from SCPs.
Enabling and Configuring Organizations
To use SCPs, you must enable all features in your organization. The steps are: 1. Create an organization from the management account using the AWS Organizations console, CLI, or API. 2. Invite existing accounts or create new accounts. 3. Organize accounts into OUs. 4. Enable SCPs by choosing "Service control policies" in the console or using the CLI command:
aws organizations enable-policy-type --root-id <root-id> --policy-type SERVICE_CONTROL_POLICYCreate and attach SCPs to roots, OUs, or directly to accounts.
Verification Commands
List policies:
aws organizations list-policies --filter SERVICE_CONTROL_POLICYAttach policy to an OU:
aws organizations attach-policy --policy-id <policy-id> --target-id <ou-id>List effective policies for an account:
aws organizations list-policies-for-target --target-id <account-id> --filter SERVICE_CONTROL_POLICYSimulate SCP effects (using IAM simulator): You can test SCPs with the IAM policy simulator, but note that SCPs are evaluated first.
Integration with Other AWS Services
AWS CloudTrail: API calls made by Organizations are logged in CloudTrail.
AWS Config: Config rules can evaluate compliance with SCPs.
AWS Control Tower: Control Tower leverages Organizations and SCPs to enforce mandatory guardrails.
AWS SSO: SSO integrates with Organizations to manage access across accounts.
AWS CloudFormation StackSets: Deploy resources across multiple accounts in an organization.
SCP Evaluation Order
When multiple SCPs apply to an account (from root, OU, and direct attachment), they are evaluated according to a hierarchical merge. The effective policy is the union of all allow statements and the union of all deny statements. Deny always overrides allow. The order of evaluation is:
- First, all SCPs attached to the root are evaluated. - Then, SCPs attached to each OU in the path from root to account. - Finally, SCPs attached directly to the account. If there is a conflict, a deny in any SCP overrides an allow in any other SCP.
Best Practices
Start with a deny list strategy: Use FullAWSAccess as a baseline and add deny statements for high-risk actions (e.g., deleting CloudTrail logs, modifying IAM roles).
Use OUs for environment separation: Create OUs for Production, Development, and Sandbox, with different SCPs.
Test SCPs in a sandbox account: Before applying to production, test in a non-critical account.
Use AWS CloudFormation Guard or custom scripts to validate SCPs before deployment.
Monitor SCP changes using CloudTrail and set up alerts for changes to SCPs.
Common Pitfalls
Forgetting that SCPs do not affect the management account: The management account can bypass SCPs, so it must be secured with strong IAM policies and MFA.
Assuming SCPs grant permissions: SCPs only deny or allow; they never grant permissions by themselves.
Using an allow list without a deny-all statement: Without a deny-all, the default FullAWSAccess still applies, making the allow list ineffective.
Exceeding the 5,120 character limit: Large SCPs may need to be split into multiple policies.
Summary of SCP Behavior
SCPs are account-level permissions boundaries.
They affect all users and roles in member accounts, including the root user.
They do not affect resource-based policies or service-linked roles.
The management account is immune to SCPs.
SCPs can be used to enforce compliance requirements, such as preventing access to certain regions or services.
Advanced: SCPs and Resource-Based Policies
If a resource-based policy (e.g., S3 bucket policy) grants access to a user in another account, SCPs in the user's account can still deny the action. For example, if Account A has an S3 bucket policy allowing Account B's user to read objects, and Account B has an SCP denying s3:GetObject, the user in Account B will be denied. However, if the resource-based policy grants access to a principal in the same account, SCPs apply normally.
SCPs and AWS Managed Policies
AWS managed policies are not affected by SCPs in the sense that they are still evaluated; but SCPs can override them. For example, if an IAM user has the AdministratorAccess managed policy attached, but an SCP denies all actions, the user is denied.
SCPs and Tags
SCPs can use condition keys like aws:RequestTag or aws:ResourceTag to control actions based on tags. This is useful for enforcing tagging policies.
SCPs and AWS KMS
SCPs can restrict KMS key usage, but note that KMS has its own key policies that also affect permissions. The effective permission is the intersection of the key policy and IAM/SCP.
Exam Tips
Remember that SCPs do not grant permissions; they only set boundaries.
Understand the difference between allow list and deny list strategies.
Know that the default SCP is FullAWSAccess.
Be able to interpret SCP JSON and determine if an action is allowed.
Recognize that the management account is not subject to SCPs.
Know that SCPs apply to all principals, including the root user of member accounts.
Be aware of the 5,120 character limit and 5 SCPs per target limit.
Conclusion
AWS Organizations and SCPs are essential for managing multi-account environments securely. For the SOA-C02 exam, focus on SCP evaluation logic, the distinction between allow and deny lists, and common exam scenarios like blocking regions or services. Practice writing and interpreting SCP statements, and understand how they interact with IAM policies.
Create an Organization
From the management account, you create an organization using the AWS Organizations console, AWS CLI, or API. When you create the organization, AWS automatically creates a root container and attaches the default SCP `FullAWSAccess`. The management account is designated and cannot be changed later. The organization is identified by a unique ID (e.g., `o-xxxxxx`). This step is a one-time action; after creation, you can invite or create member accounts.
Add Member Accounts
You can add accounts by inviting existing AWS accounts or creating new ones. Invitations are sent to the account email; the invited account must accept. Creating accounts via the Organizations API automatically creates a new account with a unique email and IAM role (OrganizationAccountAccessRole) that grants admin access to the management account. Each account gets a unique 12-digit ID. You can also move accounts between OUs.
Organize Accounts into OUs
Create OUs to group accounts based on function, environment, or security requirements. OUs can be nested up to 5 levels deep. For example, you might have a root OU "Production" with child OUs "App" and "Database". Policies attached to a parent OU apply to all child OUs and accounts under it. This hierarchical structure simplifies policy management.
Enable SCPs
By default, Organizations supports only consolidated billing. To use SCPs, you must enable all features (including SCPs) in the organization. This is done via the console or CLI: `aws organizations enable-policy-type --root-id <root-id> --policy-type SERVICE_CONTROL_POLICY`. Once enabled, you cannot revert to consolidated billing only without contacting AWS support. After enabling, you can create and attach SCPs.
Create and Attach SCPs
Design SCPs as JSON documents. You can create allow-list or deny-list policies. Attach SCPs to the root, OUs, or individual accounts. Each target can have up to 5 SCPs attached. The effective policy is the union of all allows and denies from all attached SCPs. Deny always wins. For example, to block all actions except S3, you would attach a deny-all SCP and an allow S3 SCP to the same target.
In a large enterprise with hundreds of AWS accounts, AWS Organizations and SCPs are used to enforce security baselines. For example, a financial services company uses SCPs to prevent any account from launching EC2 instances outside of approved regions (e.g., us-east-1 and eu-west-1). This is done with an SCP that denies ec2:RunInstances if the region is not in an allow list. Another common use is to block the deletion of CloudTrail logs or S3 bucket policies that disable encryption. In production, SCPs are applied at the OU level: a "Production" OU might have stricter SCPs than a "Development" OU. Performance is not a concern because SCPs are evaluated in milliseconds and have no impact on runtime. A common misconfiguration is forgetting that the management account is exempt; an attacker who gains access to the management account can bypass all SCPs. Another issue is exceeding the 5,120 character limit, requiring SCPs to be split into multiple policies. For example, a policy that lists many regions or services can quickly hit the limit. In practice, engineers use tools like AWS CloudFormation Guard to lint SCPs and ensure they are syntactically correct. They also use the IAM policy simulator to test SCP effects before deployment. When misconfigured, SCPs can cause widespread outages; for instance, denying iam:PassRole can break Lambda functions that rely on execution roles. Therefore, changes are always tested in a sandbox OU first.
The SOA-C02 exam tests AWS Organizations and SCPs under Domain 4.1: "Implement and manage security and compliance controls." Expect questions that present a scenario and ask you to identify the correct SCP or explain why an action is blocked. Common wrong answers: (1) Thinking that SCPs grant permissions – they only set boundaries. Candidates often choose an answer that says "SCP allows the action" when the correct answer is that the action is allowed by IAM within the SCP boundary. (2) Assuming that the management account is affected by SCPs – it is not. (3) Confusing SCPs with IAM permissions boundaries – both are similar but SCPs are for accounts, permissions boundaries are for IAM entities. (4) Thinking that SCPs can be applied to individual IAM users – they apply to all principals in an account. Exam-specific values: The default SCP is FullAWSAccess. Maximum 5 SCPs per target. Maximum policy size 5,120 characters. SCPs do not affect resource-based policies or service-linked roles. Edge cases: When an SCP denies an action that is required for AWS services to function (e.g., denying ec2:DescribeInstances for AWS Systems Manager), the service may fail. The exam loves to test that an explicit deny in any SCP overrides allows in other SCPs. Also, remember that SCPs are evaluated before IAM; if an SCP denies, IAM cannot allow. To eliminate wrong answers, trace the permissions flow: first check if any SCP denies the action; if yes, the action is denied regardless of IAM. If no deny, check if any SCP allows the action; if none, the default deny applies (unless using allow list). Then check IAM.
SCPs set permission boundaries for member accounts; they do not grant permissions.
The management account is immune to SCPs.
Default SCP is FullAWSAccess, which allows all actions.
Maximum 5 SCPs per target (root, OU, account).
Maximum SCP size is 5,120 characters.
SCPs affect all principals in a member account, including root.
SCPs do not affect resource-based policies or service-linked roles.
An explicit deny in any SCP overrides any allow.
SCPs are evaluated before IAM policies.
Use allow list for strict security; use deny list for gradual restrictions.
These come up on the exam all the time. Here's how to tell them apart.
Allow List SCP Strategy
Start with an explicit Deny-All statement.
Then add Allow statements for permitted actions.
More restrictive; default is deny.
Requires careful planning to avoid breaking services.
Best for high-security environments.
Deny List SCP Strategy
Start with FullAWSAccess (allow all).
Then add Deny statements for prohibited actions.
More permissive; default is allow.
Easier to implement incrementally.
Common for most organizations.
Mistake
SCPs can grant permissions to users in member accounts.
Correct
SCPs never grant permissions; they only define the maximum allowed permissions. Actual permissions are granted by IAM policies within the account.
Mistake
The management account is subject to SCPs like any other account.
Correct
The management account is not affected by SCPs. It can perform any action regardless of SCPs attached to the root.
Mistake
SCPs apply to resource-based policies across accounts.
Correct
SCPs apply only to principals in the account. Resource-based policies (e.g., S3 bucket policies) are not restricted by SCPs, though the principal's SCP may still deny the action.
Mistake
You can attach unlimited SCPs to an OU or account.
Correct
Each target (root, OU, account) can have up to 5 SCPs attached. The entire organization can have up to 1,000 SCPs.
Mistake
SCPs can be used to restrict the root user of a member account.
Correct
SCPs apply to all principals in a member account, including the root user. However, the root user can still perform actions that are not restricted by SCPs (e.g., account recovery via root credentials).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, SCPs apply to all principals in the account, including the root user, IAM users, and roles. They cannot be scoped to individual entities. To restrict specific users, use IAM policies or permissions boundaries.
The service will fail to perform that action. For example, if you deny `ec2:DescribeInstances`, AWS Systems Manager cannot list instances. Always test SCPs in a sandbox to avoid breaking services.
Yes, you can use condition keys like `aws:RequestedRegion` in an SCP to deny actions in certain regions. For example, deny all actions if the region is not in an allow list.
StackSets deploy resources across accounts. SCPs can restrict the resources that StackSets can create. For example, an SCP denying `ec2:RunInstances` will prevent StackSets from launching EC2 instances in that account.
Yes, you can attach SCPs directly to accounts. However, it's best practice to use OUs for easier management. Direct attachment is useful for exceptions.
No, the order does not matter. The effective policy is the union of all allows and denies from all attached SCPs. Deny overrides allow regardless of order.
Yes, you can use condition keys like `aws:RequestTag` or `aws:ResourceTag` in SCPs to require specific tags on resources. For example, deny `ec2:RunInstances` if the tag "Environment" is not set.
You've just covered AWS Organizations and Service Control Policies — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?