Multi-Account Governance with AWS Organizations and Control Tower

Multi-account governance is the discipline of designing, provisioning, and continuously enforcing guardrails across a fleet of AWS accounts so that security, compliance, cost, and operational standards hold uniformly no matter which team spins up the next workload. On SAP-C02, multi-account governance is not an isolated topic — it threads through Domain 1 (Design for Organizational Complexity), Domain 2 (Design for New Solutions), Domain 3 (Continuous Improvement), and Domain 4 (Accelerate Workload Migration and Modernization). Every scenario that says "the company has 40 AWS accounts" or "a new business unit is onboarding" is really a governance question in disguise.

This guide assumes you already know Associate-level IAM (identity-based vs resource-based policies, sts:AssumeRole, cross-account roles, permissions boundaries) and focuses on the organization-wide control plane: AWS Organizations, service control policies, AWS Control Tower, tag/backup/AI opt-out/chatbot policies, CloudFormation StackSets, and delegated administration. The goal is to give you enough depth to eliminate wrong answers quickly on SAP-C02 and to architect a real landing zone in your day job.

Why Multi-Account Governance Matters on SAP-C02

At Professional tier, AWS expects you to default to multi-account and to justify any single-account answer. The AWS whitepaper "Organizing Your AWS Environment Using Multiple Accounts" lists the standard reasons: blast-radius isolation, independent security boundaries, independent billing, per-team quota, compliance scope reduction, data sovereignty, and workload separation by lifecycle. SAP-C02 questions routinely hinge on a subtle blast-radius or SCP-inheritance detail — miss it and you pick a technically working but governance-inferior answer.

The exam also likes to pit AWS Organizations against AWS Control Tower, or SCPs against IAM permissions boundaries, or StackSets self-managed against service-managed permissions. The fastest way to get these right is to know the responsibilities of each service cold, including what each one specifically cannot do.

Plain-Language Explanation: Multi-Account Governance

Multi-account governance has a lot of jargon. Three distinct analogies make the constructs sticky.

Analogy 1: The Franchise Restaurant Chain

Picture a global franchise chain. The AWS Organizations management account is the franchise headquarters — it signs the master agreement, holds consolidated billing, and publishes brand standards. Each AWS member account is a franchise location with its own kitchen, staff, and local P&L. Organizational units (OUs) are the regional clusters — "North America Restaurants", "Europe Restaurants", "Test Kitchens" — that let HQ issue region-specific rules. Service control policies (SCPs) are the franchise operating manual — they say "no matter how creative your local manager is, you may never sell products X, Y, Z" (deny) or "you may only sell from the approved menu" (allow-list). Importantly, the manual doesn't cook anything — local staff still need their own recipes (IAM policies in the member account) to actually serve food. AWS Control Tower is the franchise onboarding consultant that, in a couple of hours, opens your new location with the standard kitchen layout, POS system, CCTV, and compliance signage, then sends a health inspector back every week to flag drift. The Audit account is the regional health inspector's office; the Log Archive account is the secure filing cabinet where every receipt gets copied for seven years. Delegated administrator is HQ letting the regional VP run Security Hub and GuardDuty on HQ's behalf so the franchise owner doesn't have to log into the ultra-privileged HQ account for daily work.

Analogy 2: The Apartment Building

An AWS organization is like an apartment building. The management account is the building owner — it holds the lease, pays the utility bills (consolidated billing), and sets the building-wide rules. OUs are floors (Floor 3 = Production, Floor 2 = Non-Prod, Floor 1 = Sandbox). Each apartment is a member AWS account. SCPs are the building bylaws posted in the lobby — "no loud music after 10pm, no commercial cooking, no short-term rentals" — they cap what any tenant can do, but a quiet studying tenant (an IAM user with no permissions) still needs a permission from their lease (identity-based IAM policy) to actually do anything. Control Tower guardrails are the smoke detectors and sprinklers — preventive guardrails stop the fire (block the API call), detective guardrails scream when smoke appears (raise an AWS Config non-compliance finding), proactive guardrails inspect the blueprint before renovation starts (CloudFormation Hooks block a non-compliant stack). Drift is what happens when a tenant unscrews a sprinkler head; Control Tower's drift detection is the monthly walk-through that notices and flags it.

Analogy 3: The Airport Security System

AWS Organizations + Control Tower resembles an airport. The management account is airport operations control. Each AWS account is a terminal. OUs are concourses ("International", "Domestic", "Cargo") with different rules. SCPs are TSA checkpoint rules that block forbidden items — no matter which airline (IAM principal) sold your ticket, the checkpoint can still refuse you. The checkpoint itself never gives you a boarding pass (SCPs never grant); your airline IAM policy does. Tag policies are the baggage tagging standard — every bag must carry a specific label format, or the conveyor belt tags it non-compliant. Backup policies are the lost-luggage insurance scheme — HQ defines one policy, every terminal automatically inherits it via AWS Backup. CloudFormation StackSets are the standard airport-wide signage system — one design, deployed across all concourses and updated centrally.

AWS Organizations Deep Dive — Structure, OU Design Patterns, and Trust Model

AWS Organizations is the foundation every other governance service sits on. Before SCPs, Control Tower, or StackSets make sense you need a correct mental model of the structure.

Structure: management account, root, OUs, and member accounts

An organization has exactly one management account (formerly called the master account). The management account owns the organization, creates and invites member accounts, manages OUs, attaches policies, and is the only account that can enable a service across the org. The root is the topmost container — you attach policies to the root to affect every account. Beneath the root sit Organizational Units (OUs), nestable up to five levels deep. Member accounts live inside OUs (or directly under the root, but that is a red flag in any SAP-C02 scenario).

Two feature sets exist:

• All features (the modern default) enables SCPs, tag policies, backup policies, AI opt-out policies, chatbot policies, integration with AWS Control Tower, IAM Identity Center, and delegated administrators.
• Consolidated billing only is the legacy mode that only provides one bill. Any SAP-C02 scenario assumes "all features" unless the question explicitly restricts it.

Canonical OU design pattern (AWS whitepaper)

The AWS whitepaper "Organizing Your AWS Environment Using Multiple Accounts" defines the reference OU pattern that Control Tower implements. Memorize it — it is the correct answer to a huge fraction of SAP-C02 "how should the company structure accounts?" questions:

• Security OU: non-workload accounts that must be strictly protected.
  • Log Archive account: immutable S3 bucket for CloudTrail + Config logs from every account.
  • Security Tooling / Audit account: central home for Security Hub, GuardDuty delegated admin, Config aggregator, Macie, Detective.
• Infrastructure OU: shared foundational workloads.
  • Network account: Transit Gateway, shared VPCs (via AWS RAM), Route 53 private hosted zones, firewall manager.
  • Shared Services account: directory service, CI/CD tooling, centralized AMIs/containers.
• Workloads OU: the application accounts.
  • Split into Prod and Non-Prod sub-OUs, then per-business-unit or per-workload accounts.
• Sandbox OU: individual experimentation accounts with strict budget controls and tight SCPs (e.g., deny production-grade services).
• Suspended OU: closed/decommissioned accounts quarantined behind a deny-all SCP.
• Policy Staging / Exceptions OU: optional container for accounts that need temporary carve-outs; make exceptions visible instead of hidden.
• Deployments OU: optional, home for pipeline/tooling accounts that deploy into workload OUs.

Management account hygiene

The management account deserves a paragraph of its own because SAP-C02 routinely tests it.

• Do not run workloads in the management account. It is the ultimate blast-radius parent.
• SCPs do not apply to the management account. Even if you attach a deny-all SCP to the root, the management account remains fully permissive. Many candidates miss this.
• Enable MFA on the root user and lock the credentials away the same day you create the organization.
• Use delegated administrators so day-to-day security operations (Security Hub, GuardDuty, Config, Macie, Audit Manager, IAM Access Analyzer, Firewall Manager, CloudFormation StackSets service-managed) happen in a member account, not in the management account.
• Enable AWS CloudTrail organization trail from the management account so every member account is logged centrally into the Log Archive account with one configuration.

Service Control Policies — Inheritance, Evaluation, and Effective Permissions

SCPs are the single most tested AWS Organizations feature on SAP-C02. The exam probes both the high-level concept (what SCPs can and cannot do) and the low-level evaluation (what happens when deny-stacking or NotAction is in play).

What SCPs are — and what they are not

An SCP is a JSON policy document attached to the root, an OU, or an individual member account. It defines the maximum permissions that IAM principals in the affected accounts may have. Three crucial properties:

1. SCPs never grant permissions. They only filter. An action requires both an SCP allow and an IAM allow to succeed.
2. SCPs do not apply to service-linked roles. AWS keeps those privileged to avoid bricking AWS services.
3. SCPs do not apply to the management account. See the trap above.

SCP inheritance and evaluation

SCPs flow top-down from the root through every OU to the member account. The effective SCP at any account is the intersection of every SCP on the path from root to that account — every SCP must allow the action, and any one SCP denying it is enough to block. Two SCP styles are possible:

• Allow-list SCPs ("Effect": "Allow" on specific services, or the default FullAWSAccess managed SCP replaced with a narrow allow list). These are strict — only listed services pass.
• Deny-list SCPs ("Effect": "Deny" on specific actions). These are permissive by default and block only the specific risks you enumerate.

The AWS default SCP FullAWSAccess is automatically attached to every new OU and account — it allows everything, making the default posture a deny-list world. If you want an allow-list posture, you must detach FullAWSAccess and attach your own narrow allow SCP.

Allow-list vs deny-list strategy

Most real-world AWS organizations use a deny-list strategy at the root + OU level and an allow-list SCP on the Sandbox and Suspended OUs specifically. SAP-C02 questions that mention "contain a sandbox to a small set of AWS services" are pointing at an allow-list SCP.

Deny-stacking and precedence

Because denies always win, you can stack multiple denies across levels. A common pattern:

• Root-level SCP: deny leaving the organization, deny disabling CloudTrail, deny disabling GuardDuty, deny deleting Config recorders, deny disabling KMS CMKs, deny modifying the default VPC in ways that break landing zone. These are the "never ever" guardrails.
• Production OU SCP: deny iam:CreateAccessKey and iam:UpdateAccessKey to force IAM Identity Center usage, deny ec2:RunInstances on expensive instance families, deny unencrypted S3 uploads.
• Sandbox OU SCP: deny production regions, deny route53:*, deny organizations:*, allow only the cheap services.

NotAction and condition-key gotchas

Two recurring SAP-C02 SCP traps:

• NotAction with "Effect": "Deny" is not a blocklist of those actions — it denies everything except those actions. So "Deny" + "NotAction": ["s3:*", "ec2:*"] denies every API call that is not S3 or EC2, which silently breaks IAM, KMS, CloudWatch, and more. The correct allow-list pattern is "Effect": "Allow" + "Action": [...], not "Effect": "Deny" + "NotAction": [...].
• aws:PrincipalOrgID vs aws:PrincipalOrgPaths. Use aws:PrincipalOrgID in S3 bucket policies and KMS key policies to restrict cross-account access to your organization. Use aws:PrincipalOrgPaths when you need to limit by a specific OU path.
• aws:SourceOrgID and aws:SourceOrgPaths appear in AWS service principals (cross-service confused deputy protection) — different condition keys than the principal-org keys above.

Effective permissions and the IAM policy simulator

Calculating effective permissions across SCPs + permissions boundaries + identity-based + resource-based + session policies is a real operational burden. AWS provides two tools:

• IAM Policy Simulator: simulate a principal's effective permissions, including SCP evaluation, for a given action and resource. Use this in troubleshooting workflows.
• IAM Access Analyzer — Unused Access and custom policy checks: can validate that a new or updated IAM policy is no more permissive than a reference policy, and flag unused permissions across the organization when configured as an organization-wide analyzer.

When an SAP-C02 scenario says "a developer in Account X cannot do Y even though IAM permits it", the first diagnostic is: check SCPs on Account X's path and check permissions boundaries.

AWS Control Tower — Landing Zone, Account Factory, and Account Factory Customization (AFC)

AWS Control Tower is the opinionated wrapper around AWS Organizations that stands up a best-practice landing zone and keeps it healthy. SAP-C02 expects you to know when to choose Control Tower vs building your own landing zone on AWS Organizations alone.

Landing Zone components (what Control Tower provisions)

When you launch Control Tower in a new management account, it deploys a complete landing zone in about an hour:

• An AWS Organizations structure with a Security OU (containing Log Archive and Audit accounts) and a Sandbox OU as starter OUs. You extend with your own OUs after launch.
• A Log Archive account with a centralized S3 bucket receiving organization-wide CloudTrail logs and AWS Config snapshots/configuration items.
• An Audit account hosting the Config aggregator and default SNS topics for compliance notifications.
• IAM Identity Center (formerly AWS SSO) configured with pre-built permission sets mapped to each OU.
• A baseline set of mandatory guardrails applied to every OU.
• AWS KMS CMKs for encryption of logs and AWS Config data (optionally customer-managed).
• Organization-wide AWS Config rules and CloudTrail trail.

Account Factory — the provisioning pipeline

Account Factory is Control Tower's provisioning mechanism for new member accounts. It wraps AWS Service Catalog: administrators or delegated users launch the "AWS Control Tower Account Factory" Service Catalog product, provide account name, email, target OU, and IAM Identity Center access, and the factory:

1. Creates a new AWS account under the target OU.
2. Applies the OU's guardrails, inheriting SCPs and Config rules.
3. Bootstraps IAM Identity Center access for the specified users/groups.
4. Sets up a baseline VPC if configured (you can disable this — SAP-C02 scenarios often want the default VPC deleted).
5. Adds the account to the organization-wide CloudTrail and Config data pipeline.

Account Factory is the correct SAP-C02 answer whenever the scenario says "new business unit requests a new AWS account that must come up compliant with existing guardrails".

Account Factory Customization (AFC)

Account Factory Customization (AFC) is the 2023+ capability that lets you attach a CloudFormation template (and supporting Terraform via the AWS Customizations for Control Tower / AFT pattern) to the Account Factory product so that every newly provisioned account also runs your baseline workload infrastructure (e.g., VPC with private endpoints, baseline IAM roles, GuardDuty detector custom tuning, Amazon Inspector enablement, Backup Vault).

AFC complements but does not replace AWS Control Tower Account Factory for Terraform (AFT), which is the Terraform-pipeline-based alternative for organizations already invested in Terraform. SAP-C02 favors AFC as the AWS-native answer unless Terraform is explicitly in the scenario.

Customizations for AWS Control Tower (CfCT)

CfCT is the older but still relevant framework that pipelines SCPs, CloudFormation StackSets, and Account Factory customizations through AWS CodePipeline. It runs in the management account and is the pattern used when you need to apply changes in response to Control Tower lifecycle events (account created, OU registered). Use AFC for baseline per-account resources; use CfCT for organization-wide policy and StackSet changes that need pipeline approvals.

Control Tower Controls (Guardrails) — Preventive, Detective, Proactive, and Categories

Controls (the modern name for "guardrails") are the enforced policies Control Tower applies to OUs. SAP-C02 tests that you can pick the right control type for a scenario.

Control types

• Preventive controls block non-compliant API calls. They are implemented as SCPs attached by Control Tower to the OU. Example: "Disallow deletion of log archive".
• Detective controls flag non-compliant resources after creation. They are implemented as AWS Config rules that emit non-compliance findings. Example: "Detect whether CloudTrail is enabled in all accounts".
• Proactive controls check planned resources before deployment. They are implemented as AWS CloudFormation Hooks that evaluate templates during CREATE/UPDATE. Example: "Require that encryption is enabled on new Amazon RDS DB instances".

Control categories (formerly "strength")

Control Tower labels each control by business category:

• Mandatory controls are applied automatically to every OU and cannot be removed. They guard the landing zone itself — deleting the log archive, disabling CloudTrail, etc.
• Strongly recommended controls are opt-in, but AWS recommends turning them on for most organizations. Example: deny public read to S3 for Log Archive, require MFA for root.
• Elective controls are opt-in for specific compliance needs. Example: disallow Amazon S3 buckets without versioning, require Amazon EBS encryption by default.

Beyond the Control Tower catalog, you also get Security Hub controls and Compliance Framework controls (NIST 800-53, PCI, CIS) that can be enabled at OU level through Control Tower's unified control catalog.

Drift detection and remediation

Drift is any state that diverges from Control Tower's baseline — someone manually detached an SCP, someone deleted the Log Archive bucket policy, someone moved an account outside an enrolled OU. Control Tower continuously evaluates drift in the landing zone and raises findings visible in the Control Tower console.

Remediation paths:

• Automatic re-enrollment: for most drift categories, clicking "Re-register OU" or "Update account" re-applies the baseline.
• Landing zone update: when AWS ships a new Control Tower version, you update the landing zone so new baselines, guardrails, and policies propagate.
• Manual remediation + re-enrollment: if someone deleted a resource Control Tower expects, restore it and re-enroll.

SCP Design Patterns — Allow-list, Deny-list, and Production Examples

This section distills battle-tested SCPs you should recognize on SAP-C02.

Pattern A: Organization-wide "never allow" deny SCP (root level)

A small, targeted deny-list attached to the root, applying to every non-management account:

• Deny organizations:LeaveOrganization — prevents an admin in a member account from detaching.
• Deny cloudtrail:StopLogging, cloudtrail:DeleteTrail, cloudtrail:UpdateTrail on the org trail — protects audit.
• Deny config:DeleteConfigurationRecorder, config:StopConfigurationRecorder, config:DeleteDeliveryChannel — protects compliance posture.
• Deny guardduty:DeleteDetector, guardduty:DisassociateFromMasterAccount — protects threat detection.
• Deny kms:ScheduleKeyDeletion on tag-filtered critical keys.
• Deny iam:* on the default IAM role that Control Tower uses (AWSControlTowerExecution).

Pattern B: Region restriction SCP

Restrict workloads to approved regions. Use aws:RequestedRegion and aws:PrincipalArn — but carefully exclude global AWS services (IAM, CloudFront, Route 53, WAF-classic global, STS, Support) which look like us-east-1 calls. The canonical AWS-published template:

"Effect": "Deny",
"NotAction": [
  "iam:*", "organizations:*", "route53:*",
  "cloudfront:*", "waf:*", "waf-regional:*",
  "sts:*", "support:*", "globalaccelerator:*",
  "budgets:*", "ce:*", "health:*", "tag:*"
],
"Resource": "*",
"Condition": { "StringNotEquals": { "aws:RequestedRegion": ["us-east-1","eu-west-1"] } }

This uses Deny + NotAction correctly — note how the NotAction list enumerates the global services so they are not denied, while the condition restricts everything else to approved regions. Getting the NotAction list wrong here bricks the account; this is the most common SCP bug.

Pattern C: Deny-root-user SCP

Forbid use of the root user in member accounts:

• "Effect": "Deny", "Action": "*", with "Condition": { "StringLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" } }.

Combined with the Control Tower mandatory MFA-for-root control, this forces the root user to be effectively unused.

Pattern D: Data perimeter SCPs

A data perimeter is the architectural boundary that ensures only trusted identities access trusted resources from trusted networks. SCPs implement the identity side:

• Deny access to S3/KMS/Secrets Manager when the principal is not inside the organization (aws:PrincipalOrgID condition) — prevents confused-deputy exfiltration.
• Deny access when aws:SourceVpc, aws:SourceVpce, or aws:ViaAWSService indicates an untrusted network.

These pair with resource-based policies on S3 buckets and KMS keys using the same condition keys, producing a complete data perimeter.

Tag Policies and AI Services Opt-Out Policies

Beyond SCPs, AWS Organizations supports four other organization policy types, each enforcing a different dimension of governance.

Tag policies

Tag policies enforce standardized tagging across the organization. A tag policy can:

• Require specific tag keys (e.g., CostCenter, DataClassification, Owner).
• Enforce tag case (e.g., CostCenter not costcenter).
• Enforce allowed values per key (e.g., Environment: {Prod | Staging | Dev | Sandbox}).
• Target specific resource types where enforcement applies.

Tag policies by themselves do not block non-compliant tagging — they report non-compliance via AWS Config and the Tag Editor. To enforce, set the "@@assign" and "enforced_for" operators, which cause tag creation with non-compliant values to fail for supported resource types. This is subtle and frequently confused: tag policies are by default reporting, not blocking.

Pair tag policies with:

• An SCP that requires certain tags on RunInstances, CreateDBInstance, etc., using aws:RequestTag conditions — this is what actually blocks non-compliant creation for unsupported resource types.
• AWS Config rules (required-tags) for post-creation detection.
• Cost Allocation Tags activation in the management account so tagged costs show up in Cost Explorer and AWS Cost and Usage Report.

AI Services Opt-Out policies

AWS AI services (Rekognition, Comprehend, Textract, Lex, Polly, Transcribe, Translate, Connect Voice ID, Q Business, CodeWhisperer, Bedrock) may by default store and use customer content to improve their models. An AI services opt-out policy attached at the root or OU disables this storage and model improvement participation for all accounts in scope.

This matters for:

• Data sovereignty and GDPR compliance.
• Highly regulated industries (healthcare, finance).
• Enterprises with proprietary content that cannot be used for training.

The policy can be global ("@@assign": { "optOut": true } for all services) or per-service. Enabling the policy type must happen from the management account. On SAP-C02, "prevent AI services from using organization content for model improvement" always maps to AI services opt-out.

Backup policies

Organization backup policies declare centralized AWS Backup plans that propagate to every member account and create AWS Backup plans with the same schedules, lifecycle, cross-account copy, and cross-region copy rules. Combined with an AWS Backup delegated administrator, this gives you one-org-one-backup-posture governance without touching each account.

Key capabilities:

• Cross-account copy into a central Backup Vault (in an isolated Backup account).
• Cross-region copy for DR.
• Vault Lock (WORM) for compliance-grade immutability, including a governance mode vs compliance mode — compliance mode cannot be removed even by root.
• Resource assignment by tag, so tag policies feed backup scope.

Chatbot policies

The newest policy type. Chatbot policies control how AWS Chatbot integrations with Slack/Microsoft Teams/Amazon Chime are authorized across the organization — specifically which channels can be associated to accounts and which permissions the channel IAM roles may assume. Attach a chatbot policy to restrict that only approved chat workspaces and channels can be linked to member accounts, preventing rogue ChatOps bots.

Delegated Administrator — Avoiding the Management-Account Trap

Running security and governance services from the management account is an anti-pattern. AWS Organizations' delegated administrator feature lets a member account assume administrative control of an integrated AWS service on behalf of the organization.

Services that support delegated admin (frequently tested)

As of 2026, more than 30 services support delegated administration, including:

• AWS Security Hub — aggregate findings organization-wide in a dedicated Security/Audit account.
• Amazon GuardDuty — enable and tune detectors across the org.
• AWS Config — aggregator for multi-account multi-region config data.
• AWS IAM Access Analyzer — organization-wide external access analyzer.
• Amazon Macie — organization-wide S3 data classification.
• AWS Firewall Manager — centralized AWS WAF, Network Firewall, Security Group, Shield rules.
• AWS Audit Manager, AWS Backup, AWS CloudFormation StackSets (service-managed), AWS License Manager, Amazon Detective, Amazon Inspector, AWS Trusted Advisor organizational view, AWS Compute Optimizer, AWS Systems Manager (Quick Setup).

The canonical pattern is to dedicate the Security / Audit account as the delegated admin for Security Hub, GuardDuty, Macie, Inspector, Detective, IAM Access Analyzer, and Audit Manager; and the Network account as the delegated admin for Firewall Manager; and the Shared Services / Deployments account as the delegated admin for StackSets service-managed permissions.

Why delegated admin matters on SAP-C02

Any scenario that says "reduce the blast radius of the management account" or "security team should manage GuardDuty without having management-account credentials" expects delegated admin. The answer is never "give the security team IAM roles in the management account".

CloudFormation StackSets — Self-Managed vs Service-Managed Permissions

CloudFormation StackSets deploy the same CloudFormation template to many accounts and regions in a single operation. On SAP-C02, StackSets are the infrastructure-as-code backbone of multi-account governance.

Two permission models

• Self-managed permissions require you to pre-create an AWSCloudFormationStackSetAdministrationRole in the administrator account and AWSCloudFormationStackSetExecutionRole in every target account. You specify accounts and regions by ID. Self-managed is the right model when the organization is not using AWS Organizations, or when targets live outside the organization.

• Service-managed permissions integrate with AWS Organizations. AWS creates the necessary service-linked roles automatically, and you specify targets by OU rather than by account ID. New accounts added to the OU receive the stack automatically via automatic deployment. Service-managed permissions is almost always the SAP-C02 answer for organization-wide deployment.

Target strategies (service-managed)

• Specific OUs — deploy to Workloads/Prod and Workloads/Non-Prod but not to Security.
• Organizational root — deploy to every account in the org.
• Automatic deployment — new accounts under chosen OUs automatically get the stack.
• Deletion behavior on removal — when an account is removed from the OU, choose whether to delete or retain the stack instance.

Concurrency and failure tolerance

StackSets expose operational guardrails that matter on exam and in production:

• Maximum concurrent accounts — how many accounts get the operation at once (higher = faster but riskier).
• Failure tolerance — how many failures to allow before halting the whole operation.
• Region order — rollout regions sequentially to test blast radius (e.g., us-west-2 first, then us-east-1, then Europe).
• Parameter and tag overrides per account — stack instances can carry per-account overrides.

Common multi-account StackSet use cases

• Deploy the AWS IAM baseline (break-glass roles, password policy, Access Analyzer) to every account.
• Deploy the AWS Config aggregator authorization into every account so the Audit account can aggregate.
• Deploy AWS GuardDuty cross-region detector configuration (delegated admin combined with StackSets).
• Deploy the VPC baseline (or delete the default VPC) in every account + region.
• Deploy CloudWatch Logs subscription to a central log aggregator.

Scenario Patterns — Multi-Account Governance on SAP-C02

SAP-C02 rarely asks "what is an SCP". It asks a 400-word scenario and expects you to map the situation to the right governance construct. Here are the patterns that show up over and over.

Scenario Pattern 1: "New acquisition joining the organization"

A company acquires another company with 15 AWS accounts already in place. Goal: bring them into governance quickly without disruption.

Best pattern:

1. Send an AWS Organizations invitation from the management account to each of the 15 accounts.
2. Move invited accounts initially into a Policy Staging OU with permissive SCPs so workloads don't break on day one.
3. Run AWS Config conformance packs and Security Hub to baseline their posture from the Audit account (delegated admin).
4. Gradually move accounts into Prod / Non-Prod OUs as they pass readiness checks, picking up the full SCP and guardrail set.
5. Enroll the accounts into Control Tower (via "Enroll account" when prerequisites are met).
6. Use CloudFormation StackSets with service-managed permissions to roll out the baseline IAM roles and logging config.

Wrong-answer patterns: "close the acquired accounts and recreate them" (too disruptive); "consolidate all 15 accounts into one" (destroys blast-radius isolation).

Scenario Pattern 2: "Developer needs to experiment with a new AWS service"

A developer in a Sandbox account wants to try a new AWS service that the organization has never approved. The Sandbox OU has an allow-list SCP.

Best pattern:

1. Evaluate the service for security and cost risk.
2. Update the allow-list SCP on the Sandbox OU to add the service (and only the specific APIs needed).
3. Propagate via Control Tower landing-zone update if applicable.
4. Require a tag (Experiment: true, Owner: email) enforced by an SCP so the sandbox resource is identifiable and budget-tagged.

Wrong-answer pattern: attaching an IAM allow policy to the developer — it won't help because the SCP blocks the action at the account boundary.

Scenario Pattern 3: "Central security team cannot manage GuardDuty"

Security engineers complain they need to log into the management account to manage GuardDuty findings across 40 accounts.

Best pattern:

1. From the management account, register the Security/Audit account as GuardDuty delegated administrator.
2. Grant security engineers access to the Security account via IAM Identity Center permission sets (e.g., SecurityAuditor, SecurityAdmin).
3. Enable auto-enable for new accounts so every newly provisioned member account gets a GuardDuty detector automatically.

Wrong-answer pattern: sharing management-account credentials, or creating an IAM user in the management account for every engineer. Both increase blast radius.

Scenario Pattern 4: "Compliance officer needs centralized, tamper-proof audit logs"

A regulated company must retain CloudTrail logs for seven years with immutability.

Best pattern:

1. Enable AWS Organizations CloudTrail organization trail from the management account.
2. Deliver to the Log Archive S3 bucket in the dedicated Log Archive account (separate account reduces insider risk).
3. Apply an S3 bucket policy requiring aws:PrincipalOrgID and denying s3:DeleteObject* + s3:PutBucketPolicy except by a break-glass role.
4. Enable S3 Object Lock in compliance mode on the bucket for seven-year retention.
5. Enable S3 replication to a second region for durability.
6. Enable AWS Config organization aggregator in the Audit account for point-in-time resource state.
7. Attach a root-level SCP denying cloudtrail:StopLogging/DeleteTrail so no member admin can tamper.

Wrong-answer pattern: per-account trails delivered to per-account buckets — this makes tamper-protection impossible.

Scenario Pattern 5: "Cost runaway in Non-Prod"

Non-Prod accounts are burning budget on expensive GPU instances during off-hours.

Best pattern:

1. Attach an SCP to the Non-Prod OU denying ec2:RunInstances on expensive families (p*, g*, inf*, dl*) except via a specific IAM role used by approved pipelines — use ec2:InstanceType condition.
2. Enforce tag policies requiring AutoStop: true + Owner: <email>.
3. Deploy via CloudFormation StackSets an EventBridge + Lambda that stops untagged or tagged-as-AutoStop EC2/RDS outside business hours.
4. Enable AWS Budgets organization-wide with SNS alerts routed to the owner tag.
5. Use AWS Cost Anomaly Detection at the organization level.

Scenario Pattern 6: "Data perimeter for sensitive S3 buckets"

Protect a set of S3 buckets so only identities inside the organization from approved VPCs can access them, even if bucket policies are misconfigured.

Best pattern:

1. Attach an organization-wide SCP with aws:PrincipalOrgID condition denying S3 access to principals outside the org.
2. Attach bucket policies with aws:SourceVpce or aws:SourceVpc conditions for VPC-only access.
3. Enable S3 Block Public Access at the account level via a Control Tower detective control and/or SCP denying s3:PutBucketPublicAccessBlock with aws:RequestedPublicAccessBlockConfiguration off.
4. Use VPC endpoint policies referencing aws:PrincipalOrgID on gateway/interface endpoints for S3.

Decision Matrix — Which Governance Control for Which Goal

SAP-C02 rewards fast recognition. Use this decision matrix as a mental lookup.

Common Traps — Multi-Account Governance

Expect to see at least two of these distractors on every SAP-C02 attempt.

Trap 1: Thinking SCPs grant permissions

SCPs never grant. An action only succeeds if an IAM allow exists in the member account and no SCP denies. If an exam answer says "attach an SCP that allows the developer to call s3:PutObject", it is misleading — the SCP only opens the outer boundary; the developer still needs an IAM policy.

Trap 2: Thinking SCPs restrict the management account

SCPs do not apply to the management account's principals. The correct mitigation is to not run workloads there.

Trap 3: Using Deny + NotAction as an allow-list

Deny + NotAction denies everything not listed, and the list usually forgets global services, breaking IAM/KMS/CloudTrail. The safe allow-list is Allow + Action.

Trap 4: Confusing Control Tower vs AWS Organizations

AWS Organizations is the API; Control Tower is the opinionated wrapper. You can run Organizations without Control Tower, but Control Tower cannot run without Organizations. Control Tower adds Account Factory, guardrails, drift detection, Log Archive, Audit account, and IAM Identity Center baseline — features you otherwise build yourself.

Trap 5: Forgetting delegated administrator

Answers that keep security operations in the management account are governance anti-patterns. The exam prefers answers that delegate to the Security/Audit account.

Trap 6: Using self-managed StackSets when service-managed is available

If the accounts are in an organization with all features enabled, service-managed is correct. Self-managed is for organizations without AWS Organizations or for cross-organization deployment.

Trap 7: Tag policies blocking things by default

Tag policies report non-compliance by default; they don't block. To block, you need enforced_for inside the policy plus either supported resource types or an SCP using aws:RequestTag / aws:TagKeys.

Trap 8: Five-level OU nesting limit

AWS Organizations allows up to five levels of OU nesting beneath the root. Answer choices suggesting deeply nested trees (10+ levels) are wrong. In practice, two to three levels suffice.

Trap 9: Cross-region Control Tower home region

You pick one home region for Control Tower at launch. It cannot be moved later; the Log Archive and Audit accounts anchor there. SAP-C02 sometimes probes this by asking about moving the landing zone — you can add regions as "governed regions" but not change the home region.

Trap 10: IAM permissions boundary vs SCP

Permissions boundaries are IAM-level caps on IAM users/roles within a single account. SCPs are organization-level caps across accounts. Both restrict maximum permissions but operate at different layers. They are complementary, not interchangeable.

Diagnostic Entry Point — "Why is this API call failing?"

When a scenario says "user X in account Y cannot perform action Z even though IAM says they can", walk the evaluation ladder in this order:

1. SCP on the path from root to Y — any deny on the chain blocks. Is there an explicit deny or a missing allow in an allow-list SCP? The management account is exempt, so if Y is management, skip.
2. Permissions boundary on the IAM principal — if present, it caps what identity-based policies can grant.
3. Identity-based IAM policy on the user/role in Y — must contain an allow for Z on the resource.
4. Resource-based policy on the target resource (S3 bucket policy, KMS key policy, SQS queue policy) — if present, it must also allow.
5. Session policy (if the role was assumed with one) — narrows but never expands.
6. Access point policy / Lambda resource policy / endpoint policy — additional restrictions.
7. VPC endpoint policy — if the call goes through a VPC endpoint, its policy must allow.
8. Condition keys — aws:PrincipalOrgID, aws:SourceVpc, aws:SourceVpce, aws:SecureTransport, aws:RequestedRegion, aws:MultiFactorAuthPresent can all silently block.
9. Service-specific policies — KMS key grants, Secrets Manager resource policies, Lake Formation permissions.
10. Service Control Plane issues — is the service enabled in the region? Is the account in a Suspended OU? Did Control Tower drift remediation detach something?

IAM Policy Simulator plus CloudTrail's errorCode / errorMessage on the failed call give you the fastest answer in production. On SAP-C02, the choice between "add IAM permission" and "update SCP" hinges on whether a deny exists upstream.

AWS Organizations and Control Tower Cost Model

Governance comes with cost nuance that SAP-C02 occasionally tests.

• AWS Organizations itself is free. There is no charge for creating the organization, OUs, SCPs, tag policies, backup policies, AI opt-out, or chatbot policies.
• AWS Control Tower has no direct service charge, but it enables AWS Config, CloudTrail, and KMS, all of which are billed per the usual pricing of those services. At scale (50+ accounts with many Config resources), Config cost can dominate.
• CloudFormation StackSets is free; you pay for the provisioned resources.
• Security services enabled by delegated admin (Security Hub, GuardDuty, Macie, Inspector, Detective) are each billed individually; they are not "bundled" by governance.
• AWS Backup bills per GB of backup storage + cross-region copy data transfer.
• IAM Identity Center is free.

If a scenario asks "how can we reduce the cost of multi-account governance?", typical answers include: tune AWS Config recorder scope to record only core resource types in low-activity accounts; use Config aggregator instead of per-account Config dashboards; scope Security Hub standards to only necessary frameworks.

FAQ — Multi-Account Governance Top Questions

Q1: When do I choose AWS Control Tower vs building my own landing zone on AWS Organizations?

Choose AWS Control Tower whenever the organization is new to multi-account AWS, wants an AWS-supported and continuously updated baseline, and is comfortable with Control Tower's opinions (Security OU + Log Archive + Audit + IAM Identity Center). Control Tower saves months of engineering for a landing zone that is good enough for 90 percent of enterprises. Choose a hand-rolled AWS Organizations landing zone only when Control Tower does not support a required region, when you already have a mature Terraform/AFT pipeline with significant investment, or when the organization has unusual OU semantics Control Tower cannot enroll. Even in hand-rolled cases, the AWS reference "Organizing Your AWS Environment Using Multiple Accounts" whitepaper architecture should guide you — it is the same one Control Tower implements.

Q2: How do SCPs, IAM permissions, permissions boundaries, and resource policies interact?

Every API call must survive the full evaluation chain. SCPs on the organization path set the outer cap per member account. Permissions boundaries on the IAM principal set a second cap inside that account. Identity-based IAM policies on the principal grant the actual action. Resource-based policies on the target can additionally allow cross-account access and can add their own caps. Session policies narrow an AssumeRole session's effective permissions. Every explicit deny at any layer wins. The simplest mental model: SCPs and boundaries define the maximum; IAM policies fill inside; resource policies can open additional doors; denies are absolute. The IAM Policy Simulator can evaluate the full chain, but for SAP-C02 scenarios you want to recognize which layer is failing from the question's clues.

Q3: What is the difference between service-managed and self-managed CloudFormation StackSets?

Service-managed StackSets integrate with AWS Organizations and target OUs, automatically deploying into member accounts as they are added (via auto-deployment). AWS creates the service-linked execution roles for you. Self-managed StackSets require you to pre-create the AWSCloudFormationStackSetAdministrationRole in the administrator account and AWSCloudFormationStackSetExecutionRole in every target account, and you specify accounts by ID. For organization-wide governance on SAP-C02 use service-managed. Self-managed still has a place for deployments that cross organizations, that need AWS accounts not in the organization, or when policy forbids the service-linked role model.

Q4: How do I prevent a rogue admin in a member account from leaving the organization or tampering with guardrails?

Apply a root-level SCP that denies the high-risk actions regardless of IAM policy. The canonical deny list: organizations:LeaveOrganization, cloudtrail:StopLogging, cloudtrail:DeleteTrail, config:DeleteConfigurationRecorder, config:StopConfigurationRecorder, guardduty:DeleteDetector, iam:DeleteRole on the AWSControlTowerExecution role, kms:ScheduleKeyDeletion on tag-filtered critical keys. Combine with Control Tower drift detection, an EventBridge rule on drift events notifying SecOps, and a break-glass role in the management account accessible only via hardware MFA and approval workflow. Remember: SCPs do not restrict the management account, so the management account itself must be tightly controlled by IAM Identity Center permission sets + MFA + approval workflow, not by SCP.

Q5: How do I apply the same security baseline — logging, IAM roles, GuardDuty tuning — to every account, including new ones?

Use a three-layer approach. (1) Control Tower guardrails for mandatory baselines that AWS maintains — log archive protection, CloudTrail enablement, Config enablement. (2) CloudFormation StackSets with service-managed permissions and auto-deployment targeting the OU, for organization-specific resources like break-glass roles and Config aggregator authorization. (3) Account Factory Customization (AFC) for resources that must exist on day zero of a new account — baseline VPC, endpoint configuration, Inspector enablement. For existing accounts, a one-time StackSet operation plus future auto-deployment covers everything. Delegate GuardDuty, Security Hub, Macie, Inspector, IAM Access Analyzer, and Config aggregator to the Audit account via delegated admin so their organization-wide settings propagate automatically.

Q6: Can I use AWS Organizations without AWS Control Tower?

Yes. AWS Organizations is the underlying service; Control Tower sits on top. Many mature AWS customers run Organizations without Control Tower and build their own landing zone with CloudFormation StackSets, AWS CDK, Terraform (with AFT), or the older Customizations for AWS Control Tower (CfCT). You still get SCPs, tag policies, backup policies, AI opt-out, chatbot policies, and delegated administrator — those are Organizations features, not Control Tower. Control Tower adds Account Factory, the pre-built guardrails catalog, drift detection, the Log Archive/Audit account pattern, and a console UI for all of it. For SAP-C02, when a scenario asks for "the fastest path to a best-practice multi-account baseline" the answer is Control Tower; when it asks "the most flexible multi-account setup for an organization with a custom pipeline" the answer can be AWS Organizations alone.

Q7: How do tag policies actually enforce tagging?

Tag policies by default report non-compliance via AWS Config and the Resource Groups Tagging API — they do not block tag creation. To enforce, a tag policy must use the "@@assign" operator on allowed values combined with "@@enforce" (the enforced_for field) listing the specific resource types where enforcement applies. Even then, only selected AWS resource types honor enforced_for — check the current list in the AWS Organizations User Guide before relying on this. For hard enforcement across every resource type, combine tag policies with an SCP that uses aws:RequestTag and aws:TagKeys conditions to deny resource creation without the required tags. This belt-and-suspenders pattern is the SAP-C02 answer for "prevent developers from creating untagged resources organization-wide".

Q8: What does Control Tower drift detection cover, and what does it not?

Control Tower drift detection watches the landing zone's own state: SCPs attached by Control Tower, OU membership, IAM Identity Center permission set baselines, Log Archive and Audit account resources, and mandatory control enablement. It does not watch your application resources (that is AWS Config's job), nor every bucket policy in every account. When drift is detected, Control Tower marks the affected account or OU as drifted in the console and you resolve it by re-registering the OU, updating the account, or updating the landing zone. If someone directly edits an SCP Control Tower created, drift is raised; if someone creates a new SCP alongside, that is a customer SCP and does not drift. Pair drift detection with EventBridge to SNS/Slack for real-time alerting.

Further Reading

• AWS Organizations User Guide
• AWS Organizations — Service Control Policies
• AWS Organizations — SCP Evaluation Logic
• AWS Organizations — SCP Strategies
• AWS Control Tower User Guide
• AWS Control Tower — Account Factory
• AWS Control Tower — Account Factory Customization (AFC)
• AWS Control Tower — Controls (Guardrails) Reference
• AWS Control Tower — Drift
• AWS Organizations — Tag Policies
• AWS Organizations — Backup Policies
• AWS Organizations — AI Services Opt-Out Policies
• AWS Organizations — Chatbot Policies
• AWS CloudFormation StackSets
• Organizing Your AWS Environment Using Multiple Accounts (Whitepaper)
• AWS Services Integrating with AWS Organizations (Delegated Admin)
• AWS SAP-C02 Exam Guide (PDF)