Study guide
Technical reference and lesson notes
Purpose of This Lesson
This lesson explains how AWS Organizations and AWS Control Tower help manage multi-account AWS environments. For the SAP-C02 exam, this topic matters because many professional-level architecture scenarios involve account governance, centralized billing, security boundaries, operational control, compliance, and automated account provisioning.
At the Solutions Architect Professional level, you are expected to know more than just what these services do. You need to understand when to use AWS Organizations by itself, when AWS Control Tower is the better answer, how Service Control Policies work, and how governance rules flow through an AWS multi-account structure.
Key Concepts
AWS Organizations Overview
AWS Organizations is the core AWS service for centrally managing multiple AWS accounts. Instead of running everything from one large AWS account, Organizations allows a company to create or invite accounts into a single organization and manage them under a common structure.
A typical AWS Organizations structure includes:
- A management account
- A root organizational container
- Organizational units, or OUs
- Member accounts
- Organization policies
- Consolidated billing
The management account is the account used to create and administer the organization. Member accounts are separate AWS accounts that belong to the organization.
From an exam perspective, AWS Organizations is the foundation for multi-account AWS design. It allows separation of workloads, environments, billing, security controls, and operational ownership.
AWS Organizations Feature Sets
AWS Organizations supports two feature sets:
| Feature Set | Purpose |
|---|---|
| Consolidated billing only | Centralizes billing across accounts but does not provide full governance controls |
| All features | Enables full account management, including Service Control Policies and other organization policies |
For SAP-C02, assume that governance-related features such as Service Control Policies require AWS Organizations to be enabled with all features.
Consolidated billing is useful when a company wants one payer account but still wants each AWS account to remain separate from an access and resource ownership perspective.
Consolidated Billing
With consolidated billing, one management or payer account pays the bill for all linked/member accounts. The payer account can see a consolidated bill and itemized costs by account.
Important point: consolidated billing does not automatically grant the payer account access to resources inside member accounts.
This is a key exam distinction. Billing consolidation and resource access are separate concepts.
For example, a central finance account may pay for all AWS usage, but that does not mean finance administrators can access EC2 instances, S3 buckets, databases, or IAM roles inside production accounts.
Organizational Units
Organizational units, or OUs, are containers used to group AWS accounts. OUs make it easier to apply policies consistently across accounts.
Common OU designs include:
| OU | Example Purpose |
|---|---|
| Production | Accounts running production workloads |
| Development | Developer and test environments |
| Security | Centralized security tooling, audit, and logging |
| Sandbox | Isolated experimentation accounts |
| Shared Services | Networking, directory services, CI/CD, or centralized infrastructure |
The OU structure matters because policies attached higher in the hierarchy flow down to child OUs and accounts.
For the exam, always think about inherited governance. If a policy is applied at the root or parent OU level, it can affect accounts beneath it.
AWS Organizations Policies
AWS Organizations supports several policy types. The most important for SAP-C02 are Service Control Policies, but you should also recognize tag policies and backup policies.
| Policy Type | Purpose |
|---|---|
| Service Control Policies | Define the maximum available permissions for accounts |
| Tag policies | Help standardize tagging rules across accounts |
| Backup policies | Help centrally manage backup plans across accounts |
Service Control Policies are the most heavily tested because they affect security boundaries and account-level permission governance.
Service Control Policies
Service Control Policies, or SCPs, define the maximum permissions available to IAM users and roles within affected accounts.
An SCP does not grant permissions.
This is one of the most important points to remember.
An IAM principal still needs permissions granted through IAM policies, permission boundaries, resource policies, or roles. The SCP only determines whether those permissions are allowed to be used within the account.
Think of an SCP as a guardrail around the account. It says, “Even if IAM allows this action, the account is not permitted to use it unless the SCP allows it.”
SCPs Define Maximum Permissions
SCPs are often misunderstood. They are not identity policies. They do not directly give a user, group, or role access to anything.
For an action to be allowed:
- The IAM principal must have permission.
- The SCP hierarchy must allow the action.
- No explicit deny can block the action.
If IAM allows ec2:RunInstances, but the SCP denies ec2:RunInstances, the user cannot launch EC2 instances.
If the SCP allows ec2:RunInstances, but the IAM user does not have permission, the user still cannot launch EC2 instances.
Explicit Deny Always Wins
A deny in an SCP overrides any allow in IAM or other SCPs.
For example, if a parent OU has an SCP that denies launching EC2 instances except for t2.micro, then accounts under that OU cannot launch larger instance types, even if a child OU or IAM policy appears to allow them.
This is a common SAP-C02 exam pattern. The question may describe a user who has AdministratorAccess in a member account but still cannot perform an action. The likely cause is an SCP deny inherited from the organization hierarchy.
Management Account and SCP Restrictions
SCPs do not restrict users and roles in the AWS Organizations management account.
This is exam-relevant because the management account has special administrative power over the organization. In real-world design, this is why the management account should be tightly protected and not used for normal workloads.
Best practice is to keep the management account isolated and use separate accounts for production, development, security, logging, and shared services.
Default FullAWSAccess SCP
By default, AWS Organizations attaches a policy commonly known as FullAWSAccess. This allows all AWS actions and all resources.
This default model supports a deny list strategy. Everything is allowed unless a more specific SCP denies something.
For example, an organization might allow all AWS services by default but deny:
- Leaving the organization
- Disabling CloudTrail
- Deleting security logs
- Creating public S3 buckets
- Launching expensive EC2 instance families
- Using AWS Regions outside an approved list
Deny List SCP Strategy
A deny list strategy starts with broad access allowed and then blocks specific actions.
This is the default and usually easier to operate.
Example:
| Layer | Policy Behavior |
|---|---|
| Root | Allows all AWS actions |
| Development OU | Denies launching EC2 instances larger than an approved type |
| Account IAM policy | Grants EC2 permissions to developers |
In this design, developers can use EC2 only within the boundaries defined by the SCP.
The deny list strategy is common because teams do not need to explicitly allow every AWS API action at every OU level.
Allow List SCP Strategy
An allow list strategy removes broad access and requires specific actions to be allowed at every level of the AWS Organizations hierarchy.
This is more restrictive but harder to manage.
For an action to be usable in a member account, every level in the hierarchy must allow that action:
- Root
- Parent OU
- Child OU
- Account
If DynamoDB is allowed only at a lower OU but not at the root or parent OU, DynamoDB is effectively blocked.
This is a common exam trap. An allow at the account or child OU level does not matter if the required allow does not exist higher in the hierarchy.
SCP Inheritance
SCPs inherit down the AWS Organizations hierarchy.
A policy attached to the root applies to OUs and accounts below it. A policy attached to an OU applies to accounts and child OUs beneath it.
The effective permissions are the intersection of what is allowed across the hierarchy, with explicit denies taking priority.
This means a child OU cannot override a deny from a parent OU.
Example: Restricting EC2 Instance Types
A common SCP use case is limiting EC2 instance types in non-production accounts.
For example, a development OU might deny ec2:RunInstances unless the requested instance type is t2.micro.
This design can help control cost and reduce risk in development or sandbox environments.
However, remember that this does not grant developers EC2 access. It only limits what they can do if their IAM permissions already allow EC2 instance creation.
Automating Account Creation
AWS Organizations includes APIs that can automate organization and account management.
Important API actions include:
| API Action | Purpose |
|---|---|
CreateOrganization | Creates a new AWS organization |
CreateAccount | Creates a new AWS account inside the organization |
CreatePolicy | Creates an organization policy such as an SCP |
AttachPolicy | Attaches a policy to a root, OU, or account |
InviteAccountToOrganization | Invites an existing AWS account to join the organization |
For the SAP-C02 exam, account automation matters in large-scale environments where accounts are provisioned repeatedly for teams, applications, projects, or environments.
IAM Identity Center with AWS Organizations
IAM Identity Center can be used with AWS Organizations to provide centralized access management across accounts.
Instead of creating IAM users in every AWS account, users can sign in through a centralized identity source and assume roles into assigned accounts.
Possible identity sources can include:
- IAM Identity Center directory
- External SAML 2.0 identity provider
- Microsoft Active Directory
This is important in enterprise environments because centralized identity reduces administrative overhead and improves governance.
Centralized CloudTrail with AWS Organizations
AWS CloudTrail can be enabled from the management account and applied across member accounts.
A strong governance design ensures member accounts cannot disable logging.
This is important for security, auditability, incident response, and compliance.
For exam scenarios, if the question asks for centralized, organization-wide auditing, think about organization trails in CloudTrail and centralized log storage.
AWS Control Tower Overview
AWS Control Tower builds on AWS Organizations. It is not a replacement for Organizations. Instead, it uses AWS Organizations and adds a managed governance framework.
Control Tower provides a standardized way to set up and govern a multi-account AWS environment.
Key Control Tower features include:
- Landing zone
- Account Factory
- Preventive guardrails
- Detective guardrails
- Centralized logging
- Federated access using IAM Identity Center
- Preconfigured organizational structure based on AWS best practices
For SAP-C02, Control Tower is usually the better answer when the scenario asks for a managed, best-practice, multi-account baseline.
Control Tower Landing Zone
A landing zone is a well-architected multi-account baseline environment.
Control Tower creates this landing zone using AWS best practices. It establishes a structured foundation for accounts, identity, logging, and governance.
A typical Control Tower setup includes:
| Account or OU | Purpose |
|---|---|
| Management account | Administers the organization and Control Tower |
| Security OU | Contains security-related accounts |
| Audit account | Used for security and audit access |
| Log archive account | Stores centralized logs |
| Sandbox OU | Used for experimentation and development |
| Production OU | Used for production workloads |
This structure helps separate responsibilities and reduce blast radius.
Account Factory
Control Tower Account Factory automates the creation of new AWS accounts.
Instead of manually creating accounts, applying policies, setting up logging, and configuring access, Account Factory provisions accounts using approved templates and guardrails.
This is useful for organizations that need repeatable account vending.
Common real-world examples include:
- New application account
- New development account
- New sandbox account
- New workload environment
- New business unit account
For exam purposes, if the question asks for automated account provisioning with governance baked in, Control Tower Account Factory is likely the best answer.
Guardrails in AWS Control Tower
Control Tower uses guardrails to enforce or monitor governance requirements.
There are two major types:
| Guardrail Type | Implementation | Purpose |
|---|---|---|
| Preventive guardrails | Service Control Policies | Prevent disallowed actions |
| Detective guardrails | AWS Config rules and AWS Lambda | Detect noncompliant resources or configurations |
Preventive guardrails stop actions from happening.
Detective guardrails monitor the environment and report when something is noncompliant.
Preventive Guardrails
Preventive guardrails are implemented using SCPs.
They disallow certain AWS API actions. For example, a preventive guardrail might prevent users from disabling CloudTrail or making changes that would weaken account security.
Because they use SCPs, preventive guardrails follow SCP behavior:
- They do not grant permissions.
- They define maximum permissions.
- Explicit deny wins.
- They apply through the AWS Organizations hierarchy.
- They do not restrict the management account in the same way as member accounts.
Detective Guardrails
Detective guardrails are implemented using AWS Config rules and Lambda functions.
They do not block the action up front. Instead, they monitor for compliance.
Examples of detective guardrail use cases include detecting:
- Unencrypted resources
- Publicly accessible resources
- Missing required logging
- Noncompliant configuration drift
- Resources deployed outside approved standards
For the exam, detective guardrails are the answer when the requirement is monitoring, reporting, or detecting compliance violations rather than preventing an action.
Control Tower vs AWS Organizations
AWS Organizations gives you the building blocks. AWS Control Tower gives you a managed framework using those building blocks.
| Capability | AWS Organizations | AWS Control Tower |
|---|---|---|
| Multi-account management | Yes | Yes |
| Consolidated billing | Yes | Yes |
| Organizational units | Yes | Yes |
| Service Control Policies | Yes | Yes, through guardrails |
| Tag policies | Yes | Yes, through Organizations |
| Backup policies | Yes | Yes, through Organizations |
| Landing zone | No native landing zone | Yes |
| Account Factory | No | Yes |
| Centralized logging baseline | Manual design | Built in |
| Federated access baseline | Manual design | Built in with IAM Identity Center |
| Guardrails | Manual SCP/config design | Built-in preventive and detective guardrails |
Use Organizations when you want direct control and are comfortable building the governance model yourself.
Use Control Tower when you want a best-practice multi-account foundation with guardrails, logging, identity, and account vending.
Exam-Relevant Takeaways
AWS Organizations is the foundation for multi-account AWS management.
Consolidated billing centralizes payment but does not grant access to member account resources.
Service Control Policies define maximum available permissions. They do not grant permissions.
An IAM user or role must still have permissions through IAM. SCPs only determine whether those permissions are allowed within the account.
Explicit deny always overrides allow.
SCPs inherit down the AWS Organizations hierarchy.
A deny applied at a parent OU affects child OUs and accounts.
In an allow list SCP strategy, permissions must be explicitly allowed at every level of the hierarchy.
The management account is not restricted by SCPs in the same way member accounts are, so it must be heavily protected.
AWS Control Tower extends AWS Organizations by creating a governed landing zone.
Control Tower Account Factory automates governed account creation.
Preventive guardrails use SCPs to block actions.
Detective guardrails use AWS Config rules and Lambda functions to monitor compliance.
If an exam scenario asks for a managed multi-account environment based on AWS best practices, Control Tower is usually the right answer.
If an exam scenario asks for centralized policy control across multiple accounts, AWS Organizations and SCPs are usually involved.
Architecture Decision Guide
| Scenario | Best AWS Choice | Why |
|---|---|---|
| A company wants one bill across many AWS accounts | AWS Organizations consolidated billing | Centralizes payment while keeping accounts independent |
| A company wants to restrict which AWS services can be used in member accounts | AWS Organizations with SCPs | SCPs define maximum available permissions |
| A company wants to prevent developers from launching expensive EC2 instance types | SCP attached to the development OU | SCPs can deny EC2 actions based on conditions such as instance type |
| A company wants a best-practice multi-account AWS foundation | AWS Control Tower | Provides a landing zone, guardrails, logging, and account structure |
| A company wants repeatable account provisioning with governance controls | Control Tower Account Factory | Automates account creation with approved baselines |
| A company wants to detect noncompliant resources after deployment | Control Tower detective guardrails / AWS Config | Detective guardrails monitor compliance instead of blocking actions |
| A company wants to block users from disabling CloudTrail in member accounts | Preventive guardrail / SCP | SCP-based guardrails can deny sensitive API actions |
| A company wants centralized identity across AWS accounts | IAM Identity Center with AWS Organizations or Control Tower | Provides federated access and avoids local IAM users in every account |
| A company wants to invite an existing AWS account into its organization | AWS Organizations InviteAccountToOrganization | Allows existing accounts to join the organization |
| A company wants complete custom control over OU and SCP design | AWS Organizations | Provides the primitives without the managed Control Tower framework |
Common Exam Traps
Trap 1: Thinking SCPs Grant Permissions
SCPs do not grant access.
If an SCP allows S3, that does not mean a user can access S3. The user still needs IAM permissions.
The SCP only says S3 is available to be used if IAM also allows it.
Trap 2: Forgetting That Explicit Deny Wins
If an SCP denies an action, IAM cannot override it.
Even AdministratorAccess in a member account cannot bypass an SCP explicit deny.
Trap 3: Ignoring SCP Inheritance
Policies attached at a parent OU affect child OUs and accounts.
If a parent OU blocks an action, a child OU cannot allow it back.
Trap 4: Misunderstanding Allow List Strategy
In an allow list model, allowing a service at a lower OU is not enough.
The service must be allowed at every level from the root down to the account.
Trap 5: Confusing AWS Organizations and Control Tower
AWS Organizations is the underlying multi-account management service.
AWS Control Tower is the managed governance layer that builds on Organizations.
If the scenario mentions a landing zone, guardrails, Account Factory, or AWS best-practice multi-account baseline, think Control Tower.
Trap 6: Assuming Consolidated Billing Grants Access
The payer account can view and pay bills, but it does not automatically gain access to resources in linked accounts.
Billing and access control are separate.
Trap 7: Thinking Detective Guardrails Prevent Actions
Detective guardrails detect and report noncompliance.
Preventive guardrails block actions.
Trap 8: Using the Management Account for Workloads
The management account has special authority and is not restricted by SCPs the same way member accounts are.
In real architectures, it should be protected and not used for normal application workloads.
Real-World Engineer Notes
In real AWS environments, multi-account design is not just an exam topic. It is one of the most important governance decisions an organization makes.
A single-account AWS environment becomes difficult to secure and manage as the company grows. Separate accounts allow teams to isolate production, development, security tooling, shared services, and experiments. This reduces blast radius and makes cost allocation much easier.
For an infrastructure or cloud engineer, AWS Organizations is where governance starts. You can use OUs to separate workloads and attach SCPs that enforce hard boundaries. For example, you may prevent sandbox accounts from launching GPU instances or prevent production accounts from disabling logging.
Control Tower is helpful when a company wants to mature quickly without manually building every control. It gives you a standard landing zone, account structure, centralized logging, and guardrails. This is especially useful for organizations that need to create accounts repeatedly and consistently.
However, Control Tower does not eliminate the need for design decisions. You still need to think through OU structure, identity integration, logging retention, break-glass access, account vending, cost allocation, and compliance requirements.
From an operations standpoint, SCP troubleshooting can be tricky. A user may have full IAM permissions inside an account but still be blocked by an inherited SCP. When troubleshooting access denied errors, always check both IAM permissions and the effective SCPs applied through the organization hierarchy.
From a security standpoint, the management account should be treated like a Tier 0 asset. It should have strong MFA, minimal users, limited day-to-day use, and monitored activity. In many environments, production workloads should never run in the management account.
From a cost governance standpoint, SCPs can help prevent expensive mistakes. Restricting instance types, approved Regions, or high-cost services in development accounts can reduce financial risk.
From a compliance standpoint, centralized CloudTrail and Control Tower detective guardrails provide visibility across the environment. This matters for audits, investigations, incident response, and operational governance.
Quick Reference Summary
AWS Organizations centrally manages multiple AWS accounts.
Consolidated billing allows one payer account to pay for all member accounts.
Consolidated billing does not grant access to member account resources.
OUs group accounts and allow policies to be applied consistently.
SCPs define the maximum permissions available in affected accounts.
SCPs do not grant permissions.
IAM permissions are still required.
Explicit deny always wins.
SCPs inherit down the organization hierarchy.
The default FullAWSAccess policy supports a deny list strategy.
An allow list strategy requires actions to be allowed at every hierarchy level.
AWS Control Tower extends AWS Organizations.
Control Tower creates a landing zone based on AWS best practices.
Account Factory automates account creation.
Preventive guardrails use SCPs.
Detective guardrails use AWS Config and Lambda.
Use Control Tower when the scenario asks for a governed multi-account landing zone.
Flashcards
Q: What is the purpose of AWS Organizations?
A: AWS Organizations centrally manages multiple AWS accounts, including account structure, consolidated billing, OUs, and organization-level policies.
Q: Does consolidated billing give the payer account access to member account resources?
A: No. Consolidated billing centralizes payment and cost visibility, but it does not automatically grant resource access.
Q: What does a Service Control Policy do?
A: An SCP defines the maximum available permissions for accounts in an organization.
Q: Do SCPs grant permissions?
A: No. SCPs only set permission boundaries at the account or OU level. IAM permissions are still required.
Q: What happens if IAM allows an action but an SCP denies it?
A: The action is denied because an explicit deny in an SCP overrides IAM permissions.
Q: What is the default SCP strategy in AWS Organizations?
A: A deny list strategy using the default FullAWSAccess policy, where everything is allowed unless explicitly denied.
Q: How does an allow list SCP strategy work?
A: Required actions must be explicitly allowed at every level of the hierarchy, including the root, parent OUs, child OUs, and account.
Q: Can a child OU override a deny from a parent OU?
A: No. SCP inheritance means a deny at a higher level flows down and cannot be overridden by a child OU.
Q: Are management account users restricted by SCPs?
A: No. SCPs do not restrict the management account in the same way they restrict member accounts.
Q: What is AWS Control Tower?
A: AWS Control Tower is a managed service that builds on AWS Organizations to create and govern a multi-account AWS landing zone.
Q: What is a landing zone?
A: A landing zone is a well-architected multi-account AWS baseline with identity, logging, account structure, and governance controls.
Q: What is Control Tower Account Factory used for?
A: Account Factory automates the provisioning of new AWS accounts with approved governance baselines.
Q: What is the difference between preventive and detective guardrails?
A: Preventive guardrails block actions using SCPs. Detective guardrails monitor compliance using AWS Config rules and Lambda.
Q: Which service should you choose for a managed best-practice multi-account baseline?
A: AWS Control Tower.
Q: Which service is the foundation for multi-account management in AWS?
A: AWS Organizations.
Practice Questions
Question 1:
A company has multiple AWS accounts for production, development, and security workloads. The company wants one account to pay for all AWS usage while keeping each account administratively independent. Which solution should be used?
A. AWS IAM Identity Center
B. AWS Organizations consolidated billing
C. AWS Control Tower detective guardrails
D. AWS Config aggregator
Correct Answer:
B. AWS Organizations consolidated billing
Explanation:
Consolidated billing allows one payer account to pay for multiple AWS accounts while the member accounts remain separate. It does not automatically grant access to resources in those accounts.
Question 2:
A developer has an IAM policy that allows ec2:RunInstances, but they receive an access denied error when trying to launch an instance type larger than t2.micro. Other EC2 actions work as expected. What is the most likely cause?
A. The developer does not have an IAM permissions boundary
B. AWS Config is blocking the request
C. An SCP inherited from a parent OU denies launching larger instance types
D. Consolidated billing is disabled
Correct Answer:
C. An SCP inherited from a parent OU denies launching larger instance types
Explanation:
SCPs define the maximum permissions available in member accounts. If an SCP denies launching certain EC2 instance types, IAM permissions cannot override that deny.
Question 3:
A company wants to create a standardized multi-account AWS environment with centralized logging, federated access, automated account creation, and governance guardrails based on AWS best practices. Which service is the best fit?
A. AWS Organizations only
B. AWS Control Tower
C. AWS CloudFormation StackSets only
D. AWS IAM Access Analyzer
Correct Answer:
B. AWS Control Tower
Explanation:
AWS Control Tower builds on AWS Organizations and provides a managed landing zone, Account Factory, centralized logging, federated access, and guardrails.
Question 4:
In an AWS Organizations allow list SCP strategy, DynamoDB is allowed at a child OU but not allowed at the root or parent OU. What is the result?
A. DynamoDB is allowed because the child OU has the most specific policy
B. DynamoDB is denied because it is not allowed at every level of the hierarchy
C. DynamoDB is allowed only for IAM administrators
D. DynamoDB is allowed only in the management account
Correct Answer:
B. DynamoDB is denied because it is not allowed at every level of the hierarchy
Explanation:
In an allow list strategy, permissions must be explicitly allowed at every level from the root down to the account. A lower-level allow is not enough if the action is not allowed higher in the hierarchy.
Question 5:
A security team wants to monitor AWS accounts for noncompliant resources, such as resources that do not meet encryption or logging requirements. The team does not need to block the action immediately but wants visibility and compliance reporting. Which Control Tower capability is most appropriate?
A. Preventive guardrails
B. Detective guardrails
C. Consolidated billing
D. IAM access keys
Correct Answer:
B. Detective guardrails
Explanation:
Detective guardrails use AWS Config rules and Lambda functions to monitor and report compliance. Preventive guardrails block actions using SCPs.