Purpose of This Lesson

AWS Organizations and AWS Control Tower provide the foundation for managing multiple AWS accounts. This lesson focuses on account hierarchy, consolidated billing, service control policies (SCPs), organization APIs, centralized auditing, Control Tower landing zones, guardrails, and the distinctions that matter when selecting a governance approach for a multi-account AWS environment.

Key Concepts

AWS Organizations

AWS Organizations consolidates multiple AWS accounts into an organization that can be centrally managed. An organization includes:

• A management account, also called the root account in the organization hierarchy. This is the account used to create the organization.
• Organizational units (OUs), which group accounts according to functions such as development, testing, or production.
• Member accounts, which remain separate accounts for resource deployment and account-level administration.
• Policies, including service control policies, tag policies, and backup policies.

Organizations can operate using either consolidated billing or all features. All features is the default and supports the broader organization-management capabilities described in this lesson.

Paying and Linked Accounts

Consolidated billing uses a paying account and linked accounts:

• The paying account receives the consolidated bill.
• Linked accounts remain independent accounts with their own resources and management boundaries.
• The consolidated bill is itemized by account, allowing costs to be attributed to individual linked accounts.
• The paying account does not automatically gain access to resources in the other accounts merely because it pays the bill.

Service Control Policies

An SCP defines the maximum permissions available to accounts in an organization. SCPs can be attached to the organization root, an OU, or an individual account.

An SCP does not grant permissions. An IAM identity-based or resource-based permissions policy must still grant the requested action. The effective permission requires both of the following:

1. The action is granted by an applicable permissions policy.
2. The action is allowed by the applicable SCP hierarchy.

An explicit deny in an SCP overrides an allow. A deny applied to a higher-level OU flows down to nested OUs and member accounts.

Organization APIs

The Organizations API supports automation of organization and account administration. Important actions from this lesson include:

• CreateOrganization: Creates an organization.
• CreateAccount: Creates an account that becomes a member of the organization.
• CreatePolicy: Creates a policy that can be attached to the organization root, an OU, or an account.
• AttachPolicy: Attaches a policy to an account or OU.
• InviteAccountToOrganization: Invites an existing AWS account to join the organization.

Centralized Identity and Auditing

IAM Identity Center can provide single sign-on for accounts in an organization. Control Tower can also use IAM Identity Center, a SAML 2.0 identity provider, or Microsoft Active Directory as its directory source.

CloudTrail can be enabled centrally from the management account and applied to member accounts. The configuration can be designed so member accounts cannot disable the audit trail, supporting continuous organization-wide auditing.

SCP Inheritance and Permission Strategies

Default Deny-List Strategy

The default approach uses the full AWS access SCP at the root, OUs, and accounts. This allows permissions to flow down the hierarchy. Specific actions are then explicitly denied where necessary.

For example, an SCP attached to a development OU can deny ec2:RunInstances unless the requested instance type is t2.micro. Because the deny applies at the OU level, it also affects nested accounts or OUs, including a production account beneath that OU. An IAM policy allowing another instance type cannot override this SCP deny.

The policy logic is effectively:

Deny ec2:RunInstances
unless ec2:InstanceType equals t2.micro

This strategy is generally easier to administer because administrators begin with broad availability and add targeted restrictions.

Allow-List Strategy

In an allow-list strategy, the full AWS access SCP is removed. Actions must then be explicitly allowed at every level in the hierarchy, including the root and each OU between the root and the target account.

For an API action to be available in an account, the action must be allowed continuously through every applicable SCP. Allowing DynamoDB only at a lower OU is insufficient if an ancestor SCP does not also allow DynamoDB.

This approach provides tighter control but is more difficult to administer because every required API action must be allowed throughout the complete hierarchy.

AWS Control Tower Architecture and Governance

Control Tower uses AWS Organizations and extends it with an automated, best-practice multi-account baseline called a landing zone.

A Control Tower landing zone can include:

• A management account.
• A security OU containing an audit account and a log archive account.
• A sandbox OU for development or testing accounts.
• A production OU for production accounts.
• Centralized identity integration.
• Governance controls implemented through guardrails.

Account Factory

Account Factory automates the process of deploying accounts within the Control Tower environment. Instead of manually creating and configuring every account, the organization can use a standardized account-provisioning workflow.

Guardrails

Guardrails apply governance and compliance rules to accounts in the landing zone.

• Preventive guardrails use SCPs to disallow API actions. They prevent selected operations from occurring.
• Detective guardrails use AWS Config rules and Lambda functions to monitor compliance and governance conditions. They identify or report noncompliant behavior rather than serving as the primary preventive control.

The root user in the management account can perform actions that guardrails would otherwise disallow, according to the lesson. This makes protection of the management account especially important.

Exam- or Assessment-Relevant Takeaways

• Choose AWS Organizations when the requirement centers on centralized multi-account management, consolidated billing, OUs, SCPs, tag policies, backup policies, or organization-level automation.
• Choose Control Tower when the requirement includes Organizations capabilities plus an automated, well-architected multi-account baseline, landing zone, account provisioning, centralized logging, identity integration, and governance guardrails.
• Remember that SCPs set permission boundaries for accounts; they do not provide IAM permissions.
• An explicit SCP deny overrides an allow, and a deny at a parent OU affects nested accounts and OUs.
• In a deny-list design, full AWS access is allowed by default and selected actions are denied.
• In an allow-list design, every required action must be allowed at every level from the root to the target account.
• Consolidated billing does not mean the paying account can access resources in linked accounts.
• Preventive Control Tower guardrails are associated with SCP-based prevention; detective guardrails use AWS Config rules and Lambda functions for monitoring and governance.
• Control Tower creates a landing zone; Organizations alone does not provide that complete best-practice baseline and account-factory workflow.

Tool / Feature Decision Guide

Requirement	Best-fit capability	Decisive reason
Combine billing across multiple independent AWS accounts	AWS Organizations with consolidated billing	A paying account receives an itemized consolidated bill for linked accounts.
Group accounts by environment or business function	Organizational units	OUs organize accounts and provide a scope for policies.
Limit which API actions accounts can use	Service control policies	SCPs define the maximum available permissions.
Standardize resource tags across accounts	Tag policies	Tag policies support organization-wide tagging standards.
Automate organization and account administration	Organizations API	Actions such as CreateAccount, CreatePolicy, and AttachPolicy support automation.
Build a standardized multi-account AWS environment	Control Tower landing zone	Control Tower creates a well-architected multi-account baseline.
Provision standardized accounts repeatedly	Control Tower Account Factory	Account Factory automates account deployment within the landing zone.
Stop disallowed API operations before they occur	Preventive guardrails	They use SCPs to disallow selected API actions.
Monitor account compliance	Detective guardrails	They use AWS Config rules and Lambda functions to detect governance or compliance issues.
Provide federated sign-on across accounts	IAM Identity Center or a supported external directory source	Control Tower supports IAM Identity Center, SAML 2.0, and Microsoft Active Directory directory sources.
Maintain organization-wide audit coverage	Centrally enabled CloudTrail	CloudTrail can be applied to member accounts and configured so members cannot disable it.

Common Traps / Misconceptions

• An SCP grants access: False. An SCP only limits the maximum permissions; another permissions policy must grant access.
• An IAM allow overrides an SCP deny: False. An explicit deny takes precedence.
• A child OU can restore a permission denied by a parent OU: False. A parent-level deny flows down to nested OUs and accounts.
• Allowing an action at the target OU is enough in an allow-list design: False. The action must be allowed at every level in the applicable hierarchy.
• Consolidated billing gives the paying account resource access: False. Billing consolidation and resource access are separate concerns.
• Control Tower replaces Organizations: False. Control Tower uses Organizations and extends it with landing zones, Account Factory, centralized logging, identity integration, and guardrails.
• Preventive and detective guardrails are interchangeable: False. Preventive guardrails disallow actions through SCPs; detective guardrails monitor compliance using AWS Config rules and Lambda functions.
• A deny condition using StringNotEquals for t2.micro denies t2.micro: False. The deny applies when the instance type is not t2.micro, so the exception is the allowed instance type from the SCP perspective.
• All users in the management account are restricted by SCPs in the same way as member accounts: The lesson identifies management-account users as not restricted by the organization SCP model described, making management-account protection a critical consideration.

Real-World Engineer / Analyst Notes

• Design OUs around policy boundaries, not merely reporting structure. Accounts that need different restrictions should not be placed under the same restrictive OU unless that inheritance is intentional.
• Treat the management account as a high-impact administrative boundary. It controls organization-level configuration, centralized auditing, billing, and potentially Control Tower governance.
• Prefer targeted explicit denies when operating a deny-list SCP model. Broad denies can unintentionally affect nested production, development, or security accounts.
• When troubleshooting an authorization failure, check both sides of the permission equation: the IAM permissions policy and the SCP path from the organization root through every applicable OU to the account.
• In an allow-list model, document the entire SCP inheritance path. A missing allow at any ancestor can make a lower-level policy appear ineffective.
• Use centralized CloudTrail and a protected logging design to reduce the chance that member-account administrators can remove evidence of activity.
• Control Tower is most useful when the organization needs repeatable account provisioning and governance controls rather than only consolidated billing or basic account grouping.

Quick Reference Summary

• Organizations: Centralized management for multiple AWS accounts.
• Management account: Creates and administers the organization and serves as the paying account in the consolidated-billing model described.
• OUs: Group accounts and provide policy-attachment boundaries.
• SCPs: Limit maximum API permissions; they do not grant permissions.
• Default SCP model: Full AWS access flows down, with explicit denies added where needed.
• Allow-list SCP model: Every desired action must be explicitly allowed at every hierarchy level.
• Consolidated billing: One paying account receives itemized costs for linked accounts, without automatic resource access.
• Control Tower: Organizations plus a landing zone, Account Factory, centralized logging, identity integration, and guardrails.
• Preventive guardrails: SCP-based action prevention.
• Detective guardrails: AWS Config and Lambda-based compliance monitoring.

Flashcards

Q: A company needs consolidated billing and separate AWS accounts for development and production. Which AWS capability should it begin with, and why?

A: AWS Organizations, using consolidated billing and OUs. Organizations provides centralized account management while keeping linked accounts independent.

Q: What is the decisive difference between an SCP and an IAM permissions policy?

A: An SCP limits the maximum permissions available to an account but does not grant permissions. An IAM or resource-based policy must still authorize the action.

Q: A parent OU denies ec2:RunInstances for all instance types except t2.micro. A child production OU has an IAM policy allowing larger instances. What happens?

A: Larger instance launches remain denied because the parent OU’s explicit SCP deny flows down and overrides the IAM allow.

Q: When is an allow-list SCP strategy appropriate, and what is its main operational cost?

A: It is appropriate when tightly restricting the API surface is more important than administrative simplicity. Every required action must be allowed at each level from the root to the account, increasing administration effort.

Q: How does the default deny-list SCP strategy differ from an allow-list strategy?

A: Deny-list begins with full AWS access flowing down and adds targeted denies. Allow-list removes full access and requires explicit allows for every required action at every level.

Q: An existing AWS account must join an organization. Which Organizations API action supports this workflow?

A: InviteAccountToOrganization, which sends an invitation to the existing account.

Q: Which Organizations API action creates a new member account rather than inviting an existing account?

A: CreateAccount. It creates an account that becomes a member of the organization.

Q: What does Control Tower add to AWS Organizations for a new multi-account environment?

A: Control Tower creates a best-practice landing zone and adds capabilities such as Account Factory, centralized logging, identity integration, and preventive and detective guardrails.

Q: An organization wants to prevent a prohibited API operation before it occurs. Which Control Tower control type should it use?

A: A preventive guardrail, because preventive guardrails use SCPs to disallow API actions.

Q: An organization wants to identify accounts that drift from compliance requirements. Which Control Tower control type is the better fit?

A: A detective guardrail, which uses AWS Config rules and Lambda functions to monitor and govern compliance.

Q: What is the purpose of the Control Tower landing zone?

A: It is a well-architected multi-account baseline that establishes standardized accounts, OUs, logging, identity integration, and governance controls.

Q: Why can a paying account not be assumed to have access to resources in linked accounts?

A: Consolidated billing concerns cost aggregation, not resource authorization. Linked accounts remain independent management and resource boundaries.

Q: What is the operational risk of placing development and production accounts beneath an OU with a restrictive SCP?

A: The restriction inherits into both environments. A policy intended for development can unintentionally constrain production if the OU hierarchy is designed poorly.

Practice Questions

Question 1

A cloud team attaches an SCP to a development OU that denies ec2:RunInstances when ec2:InstanceType is not t2.micro. A developer has an IAM policy allowing ec2:RunInstances for m5.large. The launch fails. What is the best explanation?

A. IAM policies cannot authorize EC2 actions.

B. The SCP denies the action for instance types other than t2.micro, and the deny overrides the IAM allow.

C. OUs cannot contain EC2 permissions.

D. The management account must approve every EC2 launch.

Correct answer: B

The decisive clue is the explicit SCP deny inherited from the OU. SCPs limit maximum permissions and override an IAM allow when they explicitly deny the request.

Question 2

An organization removes the full AWS access SCP and wants accounts in a nested OU to use DynamoDB. DynamoDB is allowed only in the nested OU, not in the root or its parent OU. What will happen?

A. DynamoDB will work because the closest SCP takes precedence.

B. DynamoDB will work only for the management account.

C. DynamoDB will not be available because the action must be allowed at every applicable hierarchy level.

D. DynamoDB will be allowed automatically by Control Tower.

Correct answer: C

This is an allow-list design. The required action must be explicitly allowed from the root through every OU to the target account.

Question 3

A company already uses Organizations for OUs, SCPs, consolidated billing, and tag policies. It now wants a standardized multi-account baseline, automated account provisioning, and preconfigured governance controls. Which service best matches the requirement?

A. AWS CloudTrail

B. AWS IAM Identity Center

C. AWS Control Tower

D. AWS Config only

Correct answer: C

Control Tower uses Organizations and adds a landing zone, Account Factory, centralized logging, identity integration, and guardrails.

Question 4

A security team wants member accounts to retain an organization-wide audit trail and prevents those accounts from disabling CloudTrail. Which approach is supported by the lesson?

A. Enable CloudTrail only in each production workload account.

B. Enable CloudTrail in the management account and apply it to member accounts with member-account disablement prevented.

C. Use consolidated billing to create audit logs automatically.

D. Attach an allow-only tag policy to the security OU.

Correct answer: B

The key requirement is centralized, protected auditing. The lesson describes enabling CloudTrail from the management account and applying it to members so member accounts cannot disable it.

WordPress Metadata

Suggested Slug:
aws-organizations-control-tower-soa-c03

Meta Description:
Study AWS Organizations and Control Tower account structures, SCP inheritance, consolidated billing, guardrails, landing zones, and governance decisions for the SOA-C03 exam.

Tags:
AWS Organizations, AWS Control Tower, AWS Certified CloudOps Engineer, SOA-C03, Service Control Policies, AWS IAM Identity Center, AWS CloudTrail, AWS Config, Multi-account AWS, AWS governance