By the time an organization runs dozens or hundreds of AWS accounts, “just launch a stack” stops being an answer. A DevOps engineer’s real job becomes provisioning at scale: vending new accounts with guardrails already baked in, giving development teams self-service infrastructure that can’t drift outside policy, and pushing a security baseline into every account and region at once. The DOP-C02 exam tests this constantly, and it’s the domain where candidates who only know single-account CI/CD get caught out.
This guide connects the four services that make multi-account provisioning work — AWS Organizations, AWS Control Tower, AWS Service Catalog, and CloudFormation StackSets — into one coherent story, with the CLI and the exam scenarios that go with each. It pairs naturally with the AWS DevOps Configuration Management & IaC guide and the multi-account, cross-region CI/CD guide; those cover the pipelines, while this covers the account and governance layer they run inside. If you’re still mapping the exam, the AWS DevOps Engineer Professional Exam Guide 2026 lays out all six domains.
The Multi-Account Building Blocks
Before the services, get the vocabulary straight — the exam phrases scenarios in these terms.
| Concept | What it is | Why DevOps cares |
|---|---|---|
| Management account | The root account that owns the Organization | Where you enable Organizations, Control Tower, and delegated admins |
| Organizational Unit (OU) | A container grouping accounts | The unit you attach policies and StackSets to |
| Service Control Policy (SCP) | Org-level guardrail that sets the maximum permissions | Blocks actions no IAM policy can re-grant |
| Landing zone | A pre-built, secure multi-account baseline | What Control Tower stands up for you |
| Account Factory | Control Tower’s account-vending mechanism | Provisions new accounts with the baseline applied |
The mental model: Organizations is the account tree and policy engine, Control Tower is the opinionated automation that sets up and governs that tree, Service Catalog is how you hand out approved infrastructure, and StackSets is how you push CloudFormation into many accounts and regions at once.
AWS Organizations: The Foundation
AWS Organizations is the substrate everything else sits on. It groups accounts into a hierarchy of OUs and lets you apply Service Control Policies as guardrails.
The DevOps-relevant points the exam presses on:
- SCPs set a permissions ceiling, they don’t grant anything. An action is only allowed if it’s permitted by both the SCP and the account’s IAM policies. If an SCP denies
s3:DeleteBucket, no administrator in that account can perform it — useful for enforcing non-negotiable guardrails. - SCPs don’t apply to the management account. A frequent trap: attaching a restrictive SCP and expecting it to constrain the root/management account. It won’t. Keep workloads out of the management account for this reason.
- OUs are how you scope policy at scale. Attach an SCP (or a StackSet, or a tag policy) to an OU and it flows to every account beneath it, including nested OUs.
# List the OU structure under the root
aws organizations list-roots
aws organizations list-organizational-units-for-parent \
--parent-id r-abcd
# Attach an SCP to an OU (guardrail flows to all member accounts)
aws organizations attach-policy \
--policy-id p-examplescp \
--target-id ou-abcd-11111111Organizations also enables trusted access and delegated administration, letting you run services like Config, GuardDuty, or CloudFormation StackSets from a dedicated account instead of the management account — a best practice the exam rewards.
AWS Control Tower: The Landing Zone and Account Factory
If Organizations is the raw material, Control Tower is the factory that assembles a governed environment for you. It stands up a landing zone: a multi-account baseline with a log-archive account, an audit/security account, centralized CloudTrail and Config, and a set of controls (formerly “guardrails”).
Two ideas dominate exam questions:
Controls come in behavior types. Know these three:
| Control type | Enforced by | Behavior |
|---|---|---|
| Preventive | SCPs | Stops non-compliant actions before they happen (e.g. “disallow public S3”) |
| Detective | AWS Config rules | Detects and reports non-compliance after the fact |
| Proactive | CloudFormation hooks | Blocks non-compliant resources at deployment time, before creation |
Account Factory is the account-vending machine. Instead of hand-creating accounts, Account Factory provisions a new account with the landing-zone baseline, controls, and networking already applied. It’s surfaced as a Service Catalog product, which is the bridge to the next section. For teams that want infrastructure-as-code over the console, Account Factory for Terraform (AFT) provides a GitOps pipeline that vends and customizes accounts from a repository.
The exam angle: when a scenario says “developers need new accounts frequently, each pre-configured with our security baseline and network, with minimal manual effort,” the answer is Control Tower Account Factory — not writing your own account-creation Lambda, and not manual create-account calls.
# Under the hood, Organizations can create an account, but Control Tower's
# Account Factory wraps this with baseline + guardrails automatically.
aws organizations create-account \
--email [email protected] \
--account-name "payments-prod"
# ^ raw Organizations call — no baseline. Account Factory is preferred at scale.AWS Service Catalog: Governed Self-Service
Service Catalog solves a different problem: how do you let developers provision infrastructure themselves without handing them broad IAM permissions or letting them drift from approved patterns?
The model has a few moving parts:
- A product is a CloudFormation template (or Terraform config) packaged as something end users can launch — a compliant VPC, an RDS instance with encryption on, a standardized ECS service.
- A portfolio is a collection of products plus the IAM principals allowed to use them and the constraints applied.
- A launch constraint lets a user launch a product using a specified IAM role’s permissions rather than their own. This is the key: a developer with almost no direct permissions can still provision a fully-configured, encrypted database — because Service Catalog assumes the launch role on their behalf.
- TagOptions enforce consistent tagging on everything provisioned.
# List portfolios a user can see
aws servicecatalog list-portfolios
# Launch a provisioned product from an approved product template
aws servicecatalog provision-product \
--product-id prod-abc123 \
--provisioning-artifact-id pa-xyz789 \
--provisioned-product-name "team-a-vpc" \
--provisioning-parameters Key=CidrBlock,Value=10.20.0.0/16Why the exam loves Service Catalog: it’s the canonical answer to “let teams self-serve infrastructure while guaranteeing it matches security and tagging standards, without granting them the underlying permissions.” That combination — self-service plus governance plus least privilege — is exactly the DevOps-Pro sweet spot. Pair it with the security-baseline thinking in the security & compliance automation guide.
CloudFormation StackSets: One Template, Many Accounts and Regions
Where Service Catalog is pull-based (users launch products), StackSets are push-based: you deploy a single CloudFormation template across multiple accounts and multiple regions from one operation. This is how you roll a baseline — an IAM role, a Config rule, a GuardDuty enablement, a VPC — into every account at once.
StackSets have two permission models, and the exam tests the distinction:
| Permission model | How trust is set up | When to use |
|---|---|---|
| Self-managed | You manually create AWSCloudFormationStackSetAdministrationRole in the admin account and ...ExecutionRole in each target account | Targets aren’t in your Organization, or you need custom trust |
| Service-managed | StackSets integrates with Organizations and handles roles automatically; deploy to OUs | Targets are in your AWS Organization (the common case) |
With service-managed permissions you get the feature that shows up constantly on the exam: automatic deployment to new accounts. Enable auto-deployment on a StackSet targeted at an OU, and any account later added to that OU automatically receives the stack. That’s how you guarantee a brand-new account — even one vended tomorrow by Account Factory — already has your baseline.
# Create a service-managed StackSet with auto-deployment to an OU
aws cloudformation create-stack-set \
--stack-set-name org-security-baseline \
--template-body file://baseline.yaml \
--permission-model SERVICE_MANAGED \
--auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false \
--capabilities CAPABILITY_NAMED_IAM
# Deploy it to an entire OU (all member accounts, chosen regions)
aws cloudformation create-stack-instances \
--stack-set-name org-security-baseline \
--deployment-targets OrganizationalUnitIds=ou-abcd-11111111 \
--regions us-east-1 eu-west-1Operational knobs the exam may reference: MaxConcurrentPercentage and FailureTolerancePercentage control how aggressively a StackSet rolls out and how many account failures it tolerates before stopping — the same rollout-safety mindset you apply to deployment strategies applied to fleet-wide provisioning.
StackSets vs Service Catalog vs Control Tower: Choosing the Right Tool
This is the comparison DOP-C02 questions hinge on. All three “provision things across accounts,” but they answer different questions.
| Need | Reach for |
|---|---|
| Vend new accounts with a governed baseline and networking | Control Tower Account Factory |
| Let developers self-serve approved infrastructure with least privilege | Service Catalog |
| Push the same template into many existing accounts/regions, including future ones | CloudFormation StackSets |
| Enforce a permissions ceiling no one can exceed | SCPs in Organizations |
| Detect ongoing non-compliance across the org | Control Tower detective controls / Config |
A worked example ties them together: Control Tower vends a new account via Account Factory; a service-managed StackSet with auto-deployment immediately drops the security baseline into it; developers in that account then use Service Catalog to launch approved workloads — all under SCP guardrails that cap what anyone can do. That end-to-end flow is a model DOP-C02 answer.
Common Exam Traps
- SCPs don’t grant permissions. They cap them. An action needs an
Allowin IAM and noDenyfrom any applicable SCP. And SCPs never restrict the management account. - Account Factory over custom automation. “Provision governed accounts at scale with minimal effort” is Control Tower Account Factory, not a home-grown Lambda calling
create-account. - Service-managed StackSets for Org targets. If accounts are in your Organization, use the service-managed model and target OUs — don’t manually wire self-managed roles unless the targets are outside the Org.
- Auto-deployment catches future accounts. Only service-managed StackSets with auto-deployment enabled automatically cover accounts added to an OU later. This is the go-to answer for “new accounts must always get the baseline.”
- Launch constraints enable least privilege. Service Catalog’s value is letting low-privilege users provision high-privilege resources via a launch role — not just a template library.
- Preventive vs detective vs proactive controls. Preventive = SCP (blocks the action), detective = Config (reports after), proactive = CFN hooks (blocks at deploy time). Mixing these up loses easy points.
- Delegated administration. Run StackSets, Config, and GuardDuty from a delegated admin account, not the management account.
Practice Multi-Account Scenarios Before Exam Day
The provisioning-and-governance domain rewards recognizing which service fits a scenario in seconds — Account Factory vs StackSets vs Service Catalog vs raw Organizations — because the wrong-but-plausible option is always on offer. The AWS Certified DevOps Engineer Professional (DOP-C02) Mock Exam Bundle drills exactly these multi-account decisions with realistic, scenario-based questions and explanations that spell out why one governance tool beats the others. Pair it with the AWS DevOps Engineer study plan to build the pattern-matching speed the exam demands, and review the configuration management & IaC guide and CloudFormation guide so the templating layer beneath all of this is second nature.
Frequently Asked Questions
What is the difference between AWS Organizations and AWS Control Tower?
Organizations is the underlying service that groups accounts into OUs and applies Service Control Policies. Control Tower is an opinionated automation layer on top of Organizations that stands up a secure multi-account landing zone — log archive and audit accounts, centralized logging, preventive/detective/proactive controls, and Account Factory for vending new accounts. You can use Organizations alone, but Control Tower gives you a governed baseline out of the box.
When should I use CloudFormation StackSets instead of Service Catalog?
Use StackSets when you need to push the same template into many accounts and regions centrally — a security baseline, an IAM role, a Config rule — especially with auto-deployment to future accounts in an OU. Use Service Catalog when you want developers to self-serve approved infrastructure on demand, with least-privilege launch constraints and enforced tagging. StackSets is push; Service Catalog is governed pull.
How do StackSets deploy to new accounts automatically?
With the service-managed permission model and auto-deployment enabled, a StackSet targeted at an Organizational Unit automatically creates its stack instances in any account later moved into that OU. This is the standard way to guarantee every newly vended account receives your baseline without manual steps.
Do Service Control Policies grant permissions?
No. SCPs only set the maximum available permissions (a ceiling). An action is allowed only if IAM permits it and no applicable SCP denies it. SCPs also do not affect the Organization’s management account, which is why you should keep workloads out of that account.
What is Account Factory in AWS Control Tower?
Account Factory is Control Tower’s account-vending mechanism, exposed as a Service Catalog product. It provisions new AWS accounts with the landing-zone baseline, controls, and networking already applied, so teams get governed accounts quickly. Account Factory for Terraform (AFT) adds a GitOps pipeline for provisioning and customizing accounts from a repository.
What are preventive, detective, and proactive controls in Control Tower?
Preventive controls are enforced with SCPs and stop non-compliant actions before they happen. Detective controls use AWS Config rules to flag non-compliance after resources exist. Proactive controls use CloudFormation hooks to block non-compliant resources at deployment time, before they’re created. A strong governance posture uses all three together.