Multi-Account Automation — Control Tower, Organizations, and SCPs

Multi-account governance is one of the highest-value DOP-C02 topics. Real-world AWS estates have dozens to thousands of accounts, and the exam tests how AWS Control Tower and AWS Organizations compose to provision, baseline, and continuously police those accounts. Domain 2.2 ("automation to create, onboard, and secure AWS accounts") and Domain 6.1 ("identity and access management at scale") both depend on knowing exactly what Organizations enables, what Control Tower adds on top, and where the boundaries lie.

This guide assumes you have used Organizations to consolidate billing or apply a basic SCP. The DOP-C02 focus: Control Tower vs Organizations selection, landing zone components (logging, audit, IAM Identity Center), account factory and Account Factory for Terraform (AFT), mandatory vs strongly recommended vs elective guardrails, detective vs preventive vs proactive guardrails, SCP semantics (deny by default in Deny, allow lists in Allow), OU design patterns, delegated administrator for multi-service governance, trusted access, and the explicit constraints around what Control Tower will and won't manage.

Why Multi-Account Governance Matters on DOP-C02

DOP-C02 explicitly calls out "creating, consolidating, and centrally managing accounts (for example, AWS Organizations, AWS Control Tower)" as a Domain 2.2 skill. Community pass reports flag multi-account scenarios as one of the top three discriminators between candidates who pass on first try and those who do not. "The team needs new accounts vended in 30 minutes with logging, baseline IAM roles, and budget alarms" - that is account factory, not a Lambda + Organizations API. "The team needs to prevent any account from disabling CloudTrail" - that is an SCP with Deny on cloudtrail:StopLogging, not a Config rule. "The team needs to detect when an S3 bucket goes public and remediate it" - that is a Control Tower detective + proactive guardrail combination, or AWS Config rule + remediation.

The exam also tests Control Tower's scope boundaries: Control Tower will not manage IAM Identity Center if you have an existing one in the management account; it does not auto-onboard accounts created outside the account factory; it cannot deploy custom services into the audit/log archive accounts beyond its own footprint. Knowing these constraints is the difference between a correct answer and a plausible-looking distractor.

Plain-Language Explanation: Multi-Account Governance

The mechanics map well to real-world organizational hierarchies. Three angles cover account vending, policy boundaries, and the Control-Tower-vs-Organizations split.

Analogy 1: The Hotel Chain Property Hierarchy

A hotel chain operates 200 properties. Organizations is the chain's legal corporate structure - parent corporation owns subsidiaries grouped into regional divisions. Each property is a member account. OUs are the regional divisions (North America, EMEA, APAC). The management account is the corporate HQ - it can reach every property but no one can restrict HQ.

SCPs are the chain's brand standards - a deny rule like "no property may serve alcohol after 2 AM" caps every property regardless of local management. The brand standard does not give a property the right to do anything; it only prevents what they could otherwise do. Allow-style SCPs are like an allow-list of approved cleaning chemicals - any chemical not on the list is forbidden.

Control Tower is the chain's standardized property opening playbook - "every new hotel comes with: pre-configured front desk system, audit camera setup, brand-mandated lobby furniture, IAM Identity Center for staff badges, mandatory guardrails like 'no removing the safety camera system'". You can still customize the bar menu (your application stacks) but you cannot remove the cameras (mandatory guardrails).

Account factory is the new property opening kit - one form, branded paperwork, everything baked in. AFT is the GitOps version where the kit is described in version-controlled Terraform and each new property's customizations are tracked in source.

Analogy 2: The Hospital Network Compliance Framework

A hospital network runs 50 facilities. Organizations is the legal corporate entity. The management account is the CEO's office. OUs are the service-line groupings (acute care, ambulatory, research). Each hospital is a member account.

SCPs are the hospital network's regulatory floor - "no facility may operate without HIPAA compliance enabled" - a Deny on s3:DeleteBucketPolicy is the equivalent of "no facility may remove the patient privacy door locks". RCPs are the patient data access rules - "no patient record can be read by an external party regardless of which staff member tries", a resource-side cap.

Control Tower is the standard facility opening protocol - audit account is the central compliance office that aggregates findings; log archive account is the medical records archive that no facility can write to except through approved channels. Mandatory guardrails are the JCAHO accreditation must-haves (cannot disable). Strongly recommended guardrails are the best-practice sterile field protocols (overrideable but logged). Elective guardrails are the optional research-mode compliance checks.

IAM Identity Center is the central credentialing office - one badge for every staff member, mapped to roles per facility. Delegated administrator is the regional compliance officer authorized to run org-wide audits for a specific compliance domain (Security Hub, GuardDuty) without being the CEO.

Analogy 3: The University Department Provisioning System

A university has 80 departments, each with its own students, faculty, staff. Organizations is the university registrar's database. OUs are the colleges (Engineering, Arts, Medicine). Management account is the provost's office.

SCPs are the university-wide academic policies - "no department may award a degree without minimum credit requirements". They cap faculty authority but do not grant it. Control Tower is the standard department-opening package - new departments come pre-configured with the central library account, the IT helpdesk account, mandatory accessibility guardrails. Account factory is the department-opening application portal - submit a form, receive a fully baselined account.

Trusted access is the registrar-to-bursar data sharing agreement - the registrar (Organizations) lets the bursar service (Config aggregator, GuardDuty admin) see data org-wide. Delegated administrator is the dean of compliance authorized to run university-wide audits without being the provost.

Organizations: The Foundation

Organizations gives you the org tree, SCPs, RCPs, tag policies, and trusted access. Control Tower builds on top.

OU Design Patterns

The AWS Whitepaper "Organizing Your AWS Environment Using Multiple Accounts" recommends:

• Security OU: log archive, audit, security tooling.
• Sandbox OU: developer experimentation accounts with strict spend caps and full guardrails to prevent data exfiltration.
• Workloads OU: split into Production OU and Non-Production OU with different SCPs.
• Suspended OU: a quarantine for accounts being closed; SCP denies all actions except specific maintenance.
• Policy Staging OU: where new SCPs are tested before promotion.

Account assignments by lifecycle, not by team - teams move, lifecycle stages do not.

SCP Semantics

SCPs are evaluated as a logical AND with IAM policies in member accounts. An action is allowed only if all of (a) the IAM policy allows it, (b) every SCP in the inheritance chain allows it, and (c) no resource policy denies it.

Two SCP styles:

• Deny SCP: explicit Deny on specific actions. Default FullAWSAccess allows everything else. Most common style.
• Allow SCP: explicit Allow on specific actions; everything else is implicitly denied. Use carefully - missing a service from the list breaks it.

SCP Inheritance

SCPs attached to the org root, an OU, and a child OU all apply. The effective permission boundary is the intersection. A Deny anywhere in the chain wins; an Allow must be present at every level for the action to pass.

The management account is exempt from SCPs - they do not apply to the root.

Trusted Access and Delegated Administrator

Trusted access enables a service (config.amazonaws.com, cloudformation.amazonaws.com, securityhub.amazonaws.com, etc.) to operate org-wide. The management account enables this once per service.

Delegated administrator delegates the operational ownership of a specific service to a member account: that account can administer the service org-wide without being the management account. As of 2026, most security and governance services support delegated admin: Security Hub, GuardDuty, Config aggregator, Detective, Macie, Inspector, IAM Access Analyzer, CloudFormation StackSets, FMS, Audit Manager.

Control Tower: Managed Landing Zone

Control Tower deploys a managed landing zone with opinionated defaults.

Landing Zone Components

When you set up Control Tower, it provisions:

• Management account: where Control Tower itself runs; you must not deploy workloads here.
• Log archive account: receives CloudTrail org trail logs and Config snapshots; designed to be write-mostly with read-only access for auditors.
• Audit account: hosts cross-account roles for security tooling, SNS topics for guardrail violations, and is the typical home for delegated admin services.
• Foundational OUs: Security (containing log archive and audit), Sandbox (defaults).
• IAM Identity Center: with default permission sets (AWSAdministratorAccess, AWSPowerUserAccess, AWSReadOnlyAccess, etc.).
• Org trail in CloudTrail: writes to the log archive bucket.
• Org-wide Config aggregator: in the audit account.
• Default mandatory guardrails: SCPs and Config rules.

Account Factory

Account factory is exposed as a Service Catalog product in the management account. Vending a new account:

1. Submit a request via Service Catalog (name, OU, email, optional VPC config).
2. Account factory creates the account, places it in the chosen OU, applies guardrails.
3. Sets up baseline IAM Identity Center permission set assignments.
4. Optional: provisions a default VPC with the configured CIDR.

For complex baselines (custom roles, GuardDuty enabled, baseline Config rules), use Customizations for Control Tower (CfCT) or Account Factory for Terraform (AFT):

• CfCT: CloudFormation-based, deploys post-vending stacks via StackSets.
• AFT: Terraform-based GitOps; each account has a customization repo.

Guardrail Types and Behaviors

Guardrails come in three behaviors:

• Preventive: implemented as an SCP. Blocks the action at the API call. Examples: "Disallow creating an S3 bucket without server-side encryption", "Disallow deletion of CloudTrail".
• Detective: implemented as a Config rule + CloudWatch event. Reports non-compliance but does not block. Examples: "Detect EC2 instances without IMDSv2".
• Proactive: implemented as a CloudFormation hook. Validates a CloudFormation template at synth/deploy time and rejects non-compliant resources before they are created.

And three categories:

• Mandatory: applied to every account in every OU; cannot be removed.
• Strongly recommended: AWS-curated best practices; opt-in but recommended.
• Elective: situational controls.

Drift in Control Tower

Control Tower detects landing zone drift: SCPs modified outside Control Tower, OUs renamed manually, IAM Identity Center deleted. The remediation is a one-click landing zone re-baseline from the Control Tower console. Heavy drift may require manual cleanup before re-baseline succeeds.

IAM Identity Center

IAM Identity Center (formerly AWS SSO) is Control Tower's preferred identity surface:

• Identity sources: Identity Center directory (built-in), Active Directory (via AD Connector or Managed AD), or external IdP (Okta, Azure AD) via SAML 2.0.
• Permission sets: collections of IAM policies (managed + inline + permission boundary). Assigned to (user-or-group, account) pairs.
• Session credentials: user starts a session via the Identity Center portal; Identity Center assumes a role in the target account and issues short-lived credentials.

For DOP-C02 scenarios, Identity Center replaces per-account IAM users; "the org wants centralized SSO with role-based access to 50 accounts" maps to Identity Center.

Control Tower vs Organizations Selection

Decision Tree — When To Pick Which Tool

For DOP-C02 scenario stems, the multi-account governance decision tree falls into four shapes. Greenfield + standard guardrails: Control Tower with the default landing zone gives the fastest path to a compliant baseline. Greenfield + bespoke OU model: Organizations directly with hand-rolled SCP and StackSet baseline; gives full flexibility at the cost of operational ownership. Brownfield + Control Tower-compatible: enroll new OUs into Control Tower, leave legacy OUs on Organizations-only governance, then migrate gradually. Brownfield + incompatible: stay on Organizations, build SCP and StackSet baselines that match your conventions, and revisit Control Tower at the next major reorg.

The exam often plants stems where a candidate picks Control Tower but the brownfield environment is incompatible. Read for signals: existing IAM Identity Center configuration, multiple competing CloudTrail trails, customer-specific OU names that conflict with Control Tower's default OUs. Each is a flag that Control Tower will fight the existing setup. Match the tool to the constraint, not to the convenience.

Common Pitfalls (常考陷阱)

1. Assuming SCPs grant permissions: SCPs only cap. A user still needs an IAM policy granting the action.
2. Using Allow-style SCPs without listing all needed services: any service not in the Allow list is implicitly denied. Use Deny SCPs unless you really need an allow-list.
3. Forgetting the management account is exempt from SCPs: testing SCPs in the management account always shows them passing - test in a member account.
4. Trying to disable a mandatory guardrail: it cannot be done; move the workload to an OU outside Control Tower or accept the constraint.
5. Single delegated administrator for everything: each service requires separate registration with its specific service principal.
6. Treating Control Tower as a one-way door: you can decommission it, but the audit and log archive accounts are non-trivial to clean up; production rollback can take days.
7. Forgetting that account factory does not retroactively baseline existing accounts: accounts created before Control Tower must be enrolled (they go through a separate enrollment process); accounts created via Service Catalog after enrollment get the full baseline.

FAQ

Q1: When should I prefer Organizations alone over Control Tower?

When you have an existing complex multi-account estate that conflicts with Control Tower's prescribed landing zone (custom IAM Identity Center, complex CloudTrail trails, non-standard OUs), or when you need fine control over every component AWS chooses defaults for. Pure Organizations gives you SCPs, OUs, trusted access, delegated admin - all the policy primitives - without the prescribed architecture.

Q2: What happens to existing accounts when I enable Control Tower?

Control Tower starts with a fresh landing zone (creates new log archive and audit accounts, default OUs). Existing accounts are not auto-enrolled. You enroll them via the Control Tower console one at a time; enrollment moves them under a Control Tower-managed OU and applies guardrails. Accounts cannot be in conflicting states (e.g., already running their own CloudTrail with the same name as the Control Tower trail).

Q3: Can I use Service Catalog independently of Control Tower account factory?

Yes. Service Catalog is a general service for governed self-service launches; account factory is one specific product. You can have a Service Catalog portfolio of CloudFormation templates for VPCs, RDS instances, EKS clusters, etc., entirely independent of Control Tower.

Q4: How do RCPs differ from SCPs?

SCPs cap principal permissions - what IAM users/roles in member accounts can do. RCPs cap resource permissions - what any caller (including external accounts) can do to resources owned by the account. RCPs are useful for closing cross-account access loopholes that SCPs cannot reach (e.g., preventing an external party from reading an S3 bucket even if the bucket policy allows it).

Q5: Can SCPs apply to specific tags or conditions?

Yes. SCPs use the standard IAM policy language including Condition blocks. Common patterns: aws:ResourceTag/Environment, aws:RequestTag, aws:PrincipalTag. This enables attribute-based control patterns like "deny EC2 launches in production OUs unless the request includes a CostCenter tag".

Q6: What is the relationship between Control Tower and AWS Config?

Control Tower deploys an org-wide Config aggregator in the audit account, plus Config rules implementing detective guardrails. Detective guardrails are AWS Config managed rules + custom rules. Control Tower owns the rules it deploys; you can add additional Config rules independently as long as they do not conflict.

Q7: How do I migrate from a non-Control-Tower org to Control Tower?

Step 1: Verify Control Tower prerequisites (no conflicting CloudTrail trails, no existing complex IAM Identity Center, etc.). Step 2: Set up Control Tower in the management account; it creates new log archive and audit accounts. Step 3: Enroll existing accounts one OU at a time via the Account Factory enrollment process. Step 4: Migrate workloads from any existing log archive/audit accounts to the Control Tower-managed ones. Many large estates do this over months, with explicit communication to account owners about new guardrail enforcement timelines.

Wrap-Up

Multi-account governance on DOP-C02 is the composition of Organizations and Control Tower with IAM Identity Center as the human access surface. Organizations provides the policy primitives (OUs, SCPs, RCPs, trusted access, delegated admin); Control Tower delivers the prescriptive landing zone (log archive, audit, mandatory guardrails, account factory). Pick Organizations alone for brownfield estates with conflicting prerequisites; pick Control Tower for greenfield or when you want the prescribed architecture. Memorise SCP semantics ("caps not grants", "Deny anywhere wins"), guardrail behaviors (preventive/detective/proactive) and categories (mandatory/strongly-recommended/elective), and the per-service nature of trusted access and delegated administrator. With those, multi-account scenarios resolve quickly.