AWS Organizations and Control Policies: Exam Cram – SAP-C02 Study Guide

Purpose of This Lesson

AWS Organizations provides centralized governance for multiple AWS accounts. For the SAP-C02 exam, focus on account hierarchy, consolidated billing, service control policies (SCPs), permission boundaries created by SCPs, and the differences between the management account and member accounts.

Key Concepts

Organization Structure

An organization contains:

• A management account, formerly called the master account.
• Member accounts linked to the organization.
• Organizational units (OUs) used to group accounts by function, environment, business unit, or compliance requirement.
• Policies attached to the organization root, OUs, or individual accounts.

Policies attached higher in the hierarchy flow down to child OUs and accounts. This allows governance controls to be applied broadly while permitting more specific controls at lower levels.

AWS Organizations Feature Sets

AWS Organizations has two primary feature sets:

• Consolidated billing only: Provides centralized billing and account grouping but does not provide the full organization policy capabilities.
• All features: Enables advanced organization management, including service control policies and additional governance capabilities.

SCPs require the All features option to be enabled.

Consolidated Billing

Consolidated billing provides a single billing relationship for accounts in an organization:

• The management account acts as the payer account.
• Member accounts remain separate and independently own their resources.
• The payer account does not automatically gain access to member-account resources.
• Charges from all accounts can be viewed together.
• Usage may be aggregated for eligible volume pricing benefits.
• Reserved Instance benefits can be shared across eligible accounts, allowing unused capacity in one account to benefit another account.
• A single payment method can be used for the organization.

The payer or management account should generally be reserved for billing and organization administration rather than application workloads. Separating billing administration from workloads reduces risk and simplifies governance.

A default quota of 20 member accounts may apply in some organization configurations and can be increased through AWS service quota processes. Always distinguish this organization account quota from quotas for individual AWS services.

Service Control Policies

An SCP defines the maximum permissions available to IAM users and roles in member accounts. It does not grant permissions by itself.

For an action to succeed, the effective permissions must satisfy both conditions:

1. An identity-based policy or applicable resource-based policy must allow the action.
2. No applicable SCP must deny or exclude the action.

SCPs can be attached to:

• The organization root
• OUs
• Individual member accounts

The effective SCP permissions for an account are determined by the policies attached along the hierarchy. A permission must be allowed at every applicable level when using an allow-list design.

Important SCP behavior:

• SCPs apply to IAM users and roles in member accounts.
• SCPs also restrict the member account root user.
• SCPs do not restrict actions performed by the organization management account.
• SCPs do not grant permissions and cannot replace IAM policies.
• SCPs are not a substitute for resource-based policies, identity policies, or permission boundaries.

SCP Deny-List Strategy

In a deny-list model, the default FullAWSAccess SCP remains attached to the organization root, OUs, and accounts. This allows permissions to flow through the hierarchy unless another SCP explicitly denies them.

Additional SCPs can deny activities such as:

• Disabling CloudTrail or security services
• Leaving approved AWS Regions
• Removing required tags or encryption settings where supported by the policy condition model
• Creating resources outside approved services
• Modifying centralized networking or logging controls

This strategy is easier to introduce into an existing environment because existing IAM permissions generally continue to work until explicitly denied.

SCP Allow-List Strategy

In an allow-list model, FullAWSAccess is removed or replaced. Only services and actions explicitly allowed by SCPs can be used.

An allow must exist at every applicable level between the organization root and the target account. For example, if an account-level SCP allows Amazon S3 actions but the root or an intermediate OU SCP does not allow them, the action remains unavailable.

Allow-list designs provide stronger preventive control but require more planning and maintenance. New AWS services and newly required APIs are denied until the organization explicitly permits them.

Moving Accounts Between Organizations

AWS accounts can be migrated between organizations, subject to AWS Organizations requirements. The process requires appropriate access to both sides of the move, including the member account and the destination organization’s management account.

For a small number of accounts, the AWS Organizations console may be sufficient. For larger migrations, use the AWS Organizations API or AWS CLI to automate account invitations, acceptance, and validation.

Migration planning should account for:

• Billing ownership and payment methods
• SCPs inherited from the destination hierarchy
• IAM and SSO access
• CloudTrail, Config, and security tooling
• Service-linked roles and organization integrations
• Account-level resources and dependencies

Exam-Relevant Takeaways

• Consolidated billing centralizes payment and reporting; it does not merge account resources or permissions.
• Member accounts remain independent accounts even when they share a payer account.
• The management account is not restricted by SCPs.
• The root user of a member account is subject to SCP restrictions.
• SCPs define permission ceilings; they do not grant access.
• SCPs require the All features organization mode.
• A deny in any applicable SCP overrides an identity-based allow.
• In an allow-list design, the action must be allowed at the root, every parent OU, and the target account.
• In a deny-list design, FullAWSAccess allows permissions to flow unless explicitly denied.
• SCPs are useful for organization-wide guardrails, while IAM policies grant workload-level permissions.
• Moving an account into a new organization can change its effective permissions because it inherits the destination hierarchy’s SCPs.

Architecture Decision Guide

Requirement	Appropriate AWS Organizations approach	Important consideration
One payment method for several accounts	Consolidated billing	Billing consolidation does not provide resource access
Aggregate usage for eligible pricing benefits	Consolidated billing	Benefits depend on the specific AWS pricing program
Prevent member accounts from using unsupported Regions	SCP with a Region-based deny	Ensure required global services are handled correctly
Permit only an approved set of AWS services	SCP allow-list strategy	Every level in the hierarchy must allow required actions
Add guardrails without disrupting existing IAM permissions	SCP deny-list strategy	Retain FullAWSAccess and add targeted denies
Apply a control to a business unit	Attach an SCP to an OU	All accounts in that OU inherit the control
Apply a control to one workload account	Attach an SCP to the account	The organization root and parent OUs still affect the result
Centralize billing while preserving account isolation	Separate member accounts under one organization	Use IAM, AWS IAM Identity Center, or cross-account roles for access
Move many accounts between organizations	AWS Organizations API or CLI	Validate inherited policies and security integrations after migration

Common Exam Traps

• SCPs grant access: They do not. An IAM or resource-based policy must still provide an allow.
• The payer account can access every member account: Billing visibility is not administrative access. Access requires explicit roles, policies, or supported organization integrations.
• The management account is restricted by its own SCP: SCPs do not restrict the management account.
• The member account root user bypasses SCPs: The root user of a member account is subject to SCPs.
• An account-level allow is sufficient in an allow-list design: The organization root and all parent OUs must also allow the action.
• A deny-list and allow-list are equivalent: Deny-list designs preserve broad access and add restrictions; allow-list designs require explicit permission throughout the hierarchy.
• Consolidated billing combines accounts into one security boundary: Accounts remain separate security and administrative boundaries.
• Moving an account is only a billing change: The destination organization’s SCPs can immediately change what the account can do.

Real-World Engineer Notes

• Place production, development, security, infrastructure, and sandbox accounts in separate OUs so that governance can match risk and operational needs.
• Test SCPs in a nonproduction OU before applying them at the organization root. A poorly designed deny can block security operations, deployments, or incident response.
• Maintain an emergency access process that is tested under the same SCP restrictions as normal operations.
• Be cautious with Region-deny policies. Some AWS services use global endpoints, and security or billing services may require exceptions.
• Treat the management account as a highly protected control-plane account. Avoid deploying ordinary workloads there.
• When migrating accounts, compare the source and destination effective policies rather than only comparing account membership.
• Use CloudTrail, AWS Config, and centralized security tooling to detect attempts to change organization-wide controls or disable required services.

Quick Reference Summary

• Organization: Central management structure for multiple AWS accounts.
• Management account: Owns the organization and payer relationship; SCPs do not restrict it.
• Member account: Independent AWS account governed by inherited organization policies.
• OU: Logical grouping of accounts for policy inheritance.
• Consolidated billing: Central payment, combined charge visibility, and possible aggregated pricing benefits.
• SCP: Maximum-permission guardrail; it does not grant permissions.
• Deny-list: Keep FullAWSAccess, then add explicit denies.
• Allow-list: Remove broad access and explicitly allow required APIs at every hierarchy level.
• Migration: Moving an account can change its effective permissions and governance controls.

Flashcards

1. What does consolidated billing provide?

A single payer relationship, combined billing visibility, and potentially aggregated pricing benefits across eligible accounts.

1. Does consolidated billing grant the payer account access to member resources?

No. Resource access requires explicit IAM or cross-account authorization.

1. What is the primary purpose of an SCP?

To define the maximum permissions available to principals in member accounts.

1. Do SCPs grant permissions?

No. IAM or resource-based policies must still allow the action.

1. Which organization feature set is required for SCPs?

All features.

1. Which accounts are affected by SCPs?

Member accounts, including their IAM principals and member-account root user. The management account is not restricted by SCPs.

1. What is the deny-list SCP strategy?

Retain FullAWSAccess and add targeted explicit denies.

1. What is the allow-list SCP strategy?

Remove broad access and explicitly allow required actions at every applicable hierarchy level.

1. What happens if an OU SCP denies an action that an account SCP allows?

The action is denied because the effective permissions cannot exceed the restrictions imposed by any applicable SCP.

1. Why should the management account usually avoid application workloads?

It is the organization’s highest-value administrative and billing account and is not constrained by SCPs.

1. What can change when an account moves organizations?

Its inherited SCPs, governance controls, billing relationship, and integrations may change.

1. How can many accounts be migrated efficiently?

Use the AWS Organizations API or AWS CLI rather than performing every step manually in the console.

Practice Questions

Question 1

A company has 30 AWS accounts and wants one payment method, combined charge visibility, and the ability to benefit from aggregated usage where AWS pricing programs support it. The company does not want the billing account to access application resources automatically. What should the solutions architect recommend?

Correct answer: Place the accounts in one AWS Organization and use consolidated billing.

Explanation: Consolidated billing centralizes payment and reporting while preserving account independence. It does not automatically provide administrative access to member-account resources.

Question 2

An organization attaches an SCP to a production account that allows s3:GetObject. The IAM role in the account has an identity policy allowing the same action. However, the parent production OU has an SCP that does not allow Amazon S3 actions because the organization uses an allow-list model. What is the result?

Correct answer: The role cannot perform s3:GetObject.

Explanation: In an allow-list design, the action must be allowed by the organization root, every parent OU, and the target account. An account-level allow cannot override a missing parent-level allow.

Question 3

A security team wants to prevent all member accounts from disabling AWS CloudTrail. A workload account’s IAM administrator has an AdministratorAccess policy. Which control provides the strongest organization-wide preventive guardrail?

Correct answer: Attach an SCP that explicitly denies the CloudTrail actions to the organization root or an appropriate OU.

Explanation: An explicit SCP deny overrides IAM allows in member accounts. The policy should be tested carefully and should not be expected to restrict the organization management account.

Question 4

A company moves an account from Organization A to Organization B. Immediately afterward, deployments in the account fail because calls to several AWS services are denied, even though the account’s IAM policies have not changed. What is the most likely cause?

Correct answer: The account inherited restrictive SCPs from Organization B.

Explanation: SCPs are inherited from the destination organization’s root and OUs. Moving an account can therefore change its effective permission ceiling without changing its local IAM policies.

Question 5

A finance team assumes that because it owns the payer account, it can terminate EC2 instances in any linked account. Which statement is correct?

Correct answer: The payer relationship does not grant resource-management permissions in linked accounts.

Explanation: Consolidated billing provides centralized payment and billing visibility, not cross-account administrative access. The finance team would need an authorized cross-account role or another explicit access mechanism.