AWS DOP-C02: CloudFormation StackSets permission models and operation preferences
Pick the permission model from who owns the accounts. Pick the operation preferences from how many failures you can afford per region.
<!-- hal:authoritative:yaml -->
Pick the permission model from who owns the accounts. Pick the operation preferences from how many failures you can afford per region.
§I — Frame
Last DOP fire on SoT taught CloudWatch alarms, metric filters, and X-Ray sampling (09-10). Those stay shelved. EventBridge (08-29), custom resources and change sets (08-17), and CodePipeline (08-05) stay shelved too.
Today the exam grain is multi-account rollout from one template. DOP bootcamp notes: a stack set lives in one region of an administrator account, a stack instance is a reference to a stack in one target account and region, and an operation is a create, update, or delete that fans out across those instances. The DevOps Pro exam-tip notes name StackSets directly as a tested topic. Stems give you an organization shape and a failure budget; you choose the model and the knobs.
§II — Objective map: two permission models
| Model | Trust wiring | Targets | Extras |
|---|---|---|---|
| Self-managed | You create AWSCloudFormationStackSetAdministrationRole in the admin account and AWSCloudFormationStackSetExecutionRole in every target | Account IDs | Works without Organizations |
| Service-managed | Organizations trusted access; CloudFormation creates the roles | OUs or the org root | Automatic deployment; delegated administrator |
SAP bootcamp states the security split in one line: self-managed roles or service-managed roles, and CloudFormation assumes a role to act in the target account. Two service-managed facts carry weight on the exam. A member account registered as delegated administrator can own service-managed sets, calling with CallAs=DELEGATED_ADMIN. And service-managed sets do not deploy into the management account itself, even when it sits inside a targeted OU.
Automatic deployment is service-managed only. When an account joins a targeted OU, CloudFormation creates its instances in the set's regions. When the account leaves, its instances are deleted unless RetainStacksOnAccountRemoval is true.
§III — Exam discriminators: operation preferences
Bootcamp operation-options table, restated as knobs:
- Maximum concurrent accounts (
MaxConcurrentCountorMaxConcurrentPercentage). How many accounts one operation touches at once. - Failure tolerance (
FailureToleranceCountorFailureTolerancePercentage). How many stack failures per region before CloudFormation stops the operation in that region. The per-region scope is the tested detail. - Region order and concurrency (
RegionOrder,RegionConcurrencyTypeSEQUENTIALorPARALLEL). Sequential is the default and gives a canary region. - Retain stacks (
RetainStackson delete). Removes the instance from the set and leaves the stack and its resources running in the target.
Under the default strict mode, concurrency is capped at failure tolerance plus one. A stem asking for "stop after the first failure" wants tolerance 0, which forces one account at a time. Soft failure tolerance (ConcurrencyMode) lifts that cap and lets more accounts run while tolerance still counts failures.
Two traps that come from template design, not knobs:
- Global resource names. DOP notes 02: global resources in a stack set must be unique. A hard-coded IAM role name or S3 bucket name collides in the second region. Suffix with
AWS::RegionandAWS::AccountId, or deploy the global resource to one region only. - Parameter overrides. Overrides apply per account and region to parameters the template already declares, and they persist across later updates until you remove them.
§IV — Study drill
CallAs=DELEGATED_ADMIN.us-east-1 fails, and eu-west-1 must not start until us-east-1 finishes. Answer: FailureToleranceCount=0, RegionConcurrencyType=SEQUENTIAL, RegionOrder starting with us-east-1. Concurrency drops to one account at a time under strict mode.delete_stack_instances with RetainStacks=True, or, when automatic deployment is on, move it out of the targeted OU with RetainStacksOnAccountRemoval set to true.§V — What not to do
Do not pick self-managed when the stem says "every new account in the OU" with no extra work; that phrase points at automatic deployment. Do not read failure tolerance as a global count across all regions. Do not hard-code global resource names in a multi-region set. Do not re-teach CloudWatch alarms (09-10), EventBridge (08-29), change sets (08-17), or CodePipeline (08-05) as the primary drill.
§VI — Closing
Draw two boxes, self-managed and service-managed, and write under each who creates the roles and what the targets are. Then write the knob line: concurrency, per-region tolerance, region order, retain. Pair: Ops censuses stack instance status in a Rust cargo script with aws-sdk-cloudformation; Dev rolls those rows up with slice::chunk_by in a Rust crate that Python calls through PyO3. Maghrib owns the quiz later.
Related
- Prior arc: AWS DOP-C02: CloudWatch alarms, metric filters, and X-Ray sampling
- Domain hub: Cross-References/domains/Cert-Prep
- Grounding tome: DevOps Engineer Professional notes (CloudFormation / StackSets)