Study guide
4.2 Cross-Account & Multi-Region StackSets & Drift Detection
AWS Certified DevOps Engineer – Professional Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CI/CD Pipeline Architecture & Source Integration
1.1 Multi-Stage & Multi-Account CodePipeline Design 1.2 CodeBuild Projects, Build Environments & Pipeline Secrets 1.3 Source Control Workflows, Webhooks & Branching Models
2 Chapter 2: Automated Testing, Test Gates & Quality Verification
2.1 Automated Unit, Integration & Acceptance Testing in Pipelines 2.2 Load Testing, Performance Benchmarking & Synthetic Canaries 2.3 Security Scanning, SAST/DAST & Approval Gates
3 Chapter 3: Artifact Management & Multi-Platform Deployment Strategies
3.1 Artifact Lifecycle Management with CodeArtifact, ECR & S3 3.2 Automated Image Baking with EC2 Image Builder 3.3 In-Place, Rolling & Immutable Deployments on EC2 3.4 Blue/Green & Canary Deployments for ECS, EKS & Lambda
4 Chapter 4: CloudFormation, CDK & Reusable IaC Components
4.1 Advanced CloudFormation: Nested Stacks, Change Sets & Custom Resources 4.2 Cross-Account & Multi-Region StackSets & Drift Detection 4.3 Modern IaC: AWS CDK, SAM & Service Catalog Governance
5 Chapter 5: Multi-Account Architecture, Organizations & Control Tower
5.1 AWS Organizations Hierarchy, OUs & Account Provisioning 5.2 Service Control Policies (SCPs) & Multi-Account Guardrails 5.3 AWS Control Tower, Account Factory & Landing Zone Automation
6 Chapter 6: Systems Manager & Large-Scale Fleet Configuration
6.1 SSM Agent, Hybrid Activation & Session Manager 6.2 Systems Manager Run Command, State Manager & Associations 6.3 Patch Manager, Parameter Store vs Secrets Manager & AppConfig
7 Chapter 7: High Availability & Multi-Region Resiliency
7.1 Designing Resilient Multi-AZ & Multi-Region Architectures 7.2 Route 53 Traffic Flow, Health Checks & DNS Failover 7.3 Data Replication: Aurora Global DB, DynamoDB Global Tables & S3 CRR
8 Chapter 8: Scalability, Auto Scaling & Disaster Recovery Automation
8.1 EC2 Auto Scaling Policies, Lifecycle Hooks & Warm Pools 8.2 Container & Serverless Scalability: ECS Capacity Providers, EKS & API Gateway 8.3 Disaster Recovery Strategies: RTO, RPO & Architecture Tiers 8.4 Automated Backup & Recovery with AWS Backup & Elastic Disaster Recovery
9 Chapter 9: CloudWatch Metrics, Agent Collection & Log Aggregation
9.1 CloudWatch Metrics, Dimensions, Metric Math & High Resolution 9.2 Unified CloudWatch Agent & Custom Metric Collection 9.3 Centralized Log Aggregation, Retention & Cross-Account Subscriptions
10 Chapter 10: Log Analysis, Dashboards & Distributed Tracing with X-Ray
10.1 CloudWatch Logs Insights, Filter Syntax & Query Optimization 10.2 CloudWatch Dashboards, Composite Alarms & Anomaly Detection 10.3 Distributed Tracing with AWS X-Ray & Service Maps
11 Chapter 11: Automated Observability & Event-Driven Monitoring
11.1 Application & Infrastructure Health Checks with Route 53 & ALB 11.2 Centralized Observability with Amazon OpenSearch & Athena 11.3 Synthetic Monitoring with CloudWatch Synthetics Canaries
12 Chapter 12: Event-Driven Incident Detection & Notification Pipelines
12.1 AWS Health, CloudTrail Events & Operational Notification 12.2 EventBridge Event Routing, Patterns & Multi-Account Buses 12.3 Asynchronous Event Processing: SNS, SQS Queues & Dead-Letter Handling
13 Chapter 13: Automated Remediation & Deployment Troubleshooting
13.1 AWS Config Managed Rules & Automated Remediation with SSM 13.2 Event-Driven Infrastructure Self-Healing with Lambda & Step Functions 13.3 Troubleshooting CI/CD Pipeline & Deployment Failures 13.4 Root Cause Analysis for Auto Scaling & Container Failures
14 Chapter 14: Identity, Access Management & Secrets at Scale
14.1 IAM Policy Evaluation Logic, NotAction & Explicit Denies 14.2 IAM Permissions Boundaries & Delegated Administration 14.3 IAM Identity Center, Cross-Account Roles & STS Session Policies 14.4 Automated Secrets Management & Secret Rotation with Secrets Manager
15 Chapter 15: Security Automation, Data Protection & Compliance Auditing
15.1 Network Security Automation: Security Groups, NACLs, Network Firewall & WAF 15.2 Cryptographic Controls & Key Management with AWS KMS & ACM 15.3 Automated Threat Detection: GuardDuty, Inspector & Security Hub 15.4 Continuous Compliance Auditing & Log Integrity with CloudTrail & Config
4.2 Cross-Account & Multi-Region StackSets & Drift Detection
Key Takeaways Explain This Topic AI
AWS CloudFormation StackSets centrally deploy and manage stacks across multiple AWS accounts and regions in a single operation, utilizing either service-managed permissions (AWS Organizations) or self-managed permissions (IAM execution roles).
Service-managed StackSets support automatic deployments (AutoDeployment) to provision stack instances when new accounts join target Organizational Units (OUs), and support Delegated Administration to isolate deployment capabilities outside the management account.
Deployment concurrency and operational blast radius are governed by MaxConcurrentCount/Percentage and FailureToleranceCount/Percentage, with regional execution configurable as SEQUENTIAL or PARALLEL.
Drift detection compares the expected properties declared in CloudFormation templates against actual runtime configurations returned by AWS describe APIs, reporting statuses of IN_SYNC, DRIFTED, NOT_CHECKED, or UNKNOWN.
Drift remediation is accomplished either by pushing stack updates to overwrite out-of-band modifications or by using resource import (ChangeSetType: IMPORT) to incorporate unmanaged or altered resources into the template without recreation.
Last updated: September 2026
Enterprise Multi-Account IaC Orchestration
In modern cloud architectures governed by AWS Organizations, infrastructure is distributed across dozens or hundreds of dedicated AWS accounts and multiple geographic regions. Managing foundational infrastructure—such as IAM roles, AWS Config rules, Amazon GuardDuty enablers, centralized logging, and VPC network baselines—cannot be achieved through manual, per-account stack deployments.
AWS CloudFormation StackSets extends CloudFormation stacks by allowing DevOps engineers to create, update, or delete stacks across multiple accounts and regions in a single, coordinated operation. Simultaneously, maintaining configuration integrity across this distributed footprint requires continuous Drift Detection and robust remediation workflows.
AWS CloudFormation StackSets Architecture & Core Concepts
Understanding the StackSets mental model requires distinguishing between four distinct entities: +-------------------------------------------------------------------------+
- | StackSet Definition |
- | - Template: Baseline IAM / Security / VPC Rules |
- | - Permission Model: SERVICE_MANAGED or SELF_MANAGED |
- | - Parameters & Deployment Options |
- +------------------------------------+------------------------------------+
- |
- v Orchestrates Operations
- +-----------------------+-----------------------+
- | |
- v (Region: us-east-1) v (Region: eu-west-1)
- +-------------------------+ +-------------------------+
- | Stack Instance | | Stack Instance |
- | Account: 111122223333 | | Account: 111122223333 |
- | (Pointer & Status) | | (Pointer & Status) |
- +------------+------------+ +------------+------------+
- | |
- v Creates Live Stack v Creates Live Stack
- +-------------------------+ +-------------------------+
- | CloudFormation Stack | | CloudFormation Stack |
- | (Physical AWS Resources)| | (Physical AWS Resources)|
- +-------------------------+ +-------------------------+
StackSet: The central template and configuration container defined in the administrator account. It specifies the template, parameters, capabilities, and permission model.
Stack Instance: A logical pointer created by the StackSet representing a stack in a specific target account and region. A Stack Instance cannot exist without its parent StackSet.
Stack: The actual, physical AWS CloudFormation stack deployed inside the target account and region. Modifying this stack directly creates configuration drift against the StackSet.
StackSet Operation: An asynchronous background process executing a creation, update, or deletion across designated stack instances. Only one operation can execute on a given StackSet at a time .
Service-Managed vs. Self-Managed Permissions
StackSets supports two distinct security and permission architectures:
1. Service-Managed Permissions ( PERMISSION_MODEL: SERVICE_MANAGED )
Service-managed permissions integrate natively with AWS Organizations . CloudFormation automatically manages the underlying IAM trust relationships using AWS Organizations service-linked roles.
Targeting Flexibility: You target entire AWS Organizations roots, specific Organizational Units (OUs), or lists of account IDs within OUs.
Automatic Deployments ( AutoDeployment ):
Enabled: true : When a new AWS account is created or moved into a target OU, StackSets automatically provisions stack instances into the new account.
RetainStacksOnAccountRemoval : If an account is detached or moved out of the OU, you configure whether CloudFormation automatically purges the deployed stacks ( false ) or leaves them as orphaned standalone stacks ( true ).
Zero IAM Role Overhead: You do not need to create or maintain cross-account IAM roles in member accounts.
The Delegated Administrator Pattern
By default, service-managed StackSets must be created from the AWS Organizations Management Account. However, security best practices mandate restricting access to the management account. Using the Delegated Administrator feature, the management account delegates StackSet permissions to a designated member account (e.g., a central DevOps Tooling or Security account): # Executed from Organizations Management Account
- aws organizations register-delegated-administrator \
- -account-id 123456789012 \
- -service-principal member.org.stacksets.cloudformation.amazonaws.com
The delegated account can deploy and manage service-managed StackSets across the entire enterprise without possessing administrative privileges in the management account.
2. Self-Managed Permissions ( PERMISSION_MODEL: SELF_MANAGED )
Self-managed permissions are required when deploying across accounts not bound by the same AWS Organization (e.g., multi-vendor accounts, distinct organizational partitions, or GovCloud/commercial cross-deployments).
Self-managed StackSets require explicit configuration of two cross-account IAM roles:
AWSCloudFormationStackSetAdministrationRole (in the Admin Account): Must possess an IAM policy allowing sts:AssumeRole targeting AWSCloudFormationStackSetExecutionRole in all target member accounts.
AWSCloudFormationStackSetExecutionRole (in each Target Member Account): Must have a trust relationship allowing the admin account's administration role to assume it, and an attached permissions policy granting rights to provision the specific resources defined in the StackSet template.
Architectural Comparison: Service-Managed vs. Self-Managed
Capability Service-Managed Permissions Self-Managed Permissions
Account Scope Restricted to accounts within the AWS Organization Any AWS account across any AWS Organization or standalone
IAM Maintenance Fully automated via AWS Organizations service-linked roles Manual provisioning of Administration and Execution IAM roles
Automatic Account Onboarding Supported ( AutoDeployment: Enabled ) Not supported (Manual stack instance addition required)
- Delegated Admin Supported (Deploy from member accounts) Not supported (Role trust dictates deployer account)
- Deployment Targeting By Organization Root, OU ID, or Member Account ID Explicit list of AWS Account IDs
- Deployment Options & Operational Tuning
When deploying a StackSet update across 100 accounts and 5 regions (500 stack instances), an unconstrained update could exceed AWS API rate limits or spread an undetected template flaw across the entire enterprise. StackSets provides granular controls over concurrency, failure thresholds, and regional ordering.
Concurrency Control
You define how many stack instances update simultaneously using either of two mutually exclusive parameters:
MaxConcurrentCount : An absolute integer (e.g., 10 ) specifying the maximum number of accounts per region undergoing updates simultaneously.
MaxConcurrentPercentage : A percentage (e.g., 25% ) of target accounts updated concurrently. StackSets rounds down to the nearest integer (minimum of 1).
Failure Tolerance & Circuit Breaking
Failure tolerance parameters specify when CloudFormation must automatically abort the entire StackSet operation:
FailureToleranceCount : The absolute number of stack instance failures allowed before the operation halts.
FailureTolerancePercentage : The percentage of stack instances allowed to fail before the operation terminates.
Once the failure threshold is exceeded in any region or account, CloudFormation stops initiating updates on remaining pending instances, marks the operation as FAILED , and leaves already-updated stacks untouched.
Region Concurrency & Regional Sequencing
RegionConcurrencyType : Governs how multi-region deployments are sequenced:
SEQUENTIAL : Deploys to one region at a time in the exact sequence specified by RegionOrder .
PARALLEL : Deploys to all specified regions simultaneously within the concurrency limits.
RegionOrder : An ordered array of regions (e.g., ["us-east-1", "us-west-2", "eu-west-1"] ). # Example CLI deployment parameters enforcing safe enterprise canary rollouts
OperationPreferences:
RegionConcurrencyType: SEQUENTIAL
RegionOrder:
- us-east-1 # Primary canary region
- us-west-2 # Secondary region
- eu-west-1 # Global rollout
- MaxConcurrentPercentage: 20
- FailureToleranceCount: 0 # Abort immediately on a single failure in any account
- Drift Detection on Stacks and StackSets
Configuration Drift occurs when live AWS resource properties are altered outside of CloudFormation—via the AWS Management Console, AWS CLI, direct SDK scripts, or external automation tools. Drift breaks the IaC source-of-truth model and can cause subsequent CloudFormation updates to fail or unexpectedly overwrite manual emergency fixes.
How Drift Detection Operates
Initiation: Triggered on-demand via DetectStackDrift (for single stacks) or DetectStackSetDrift (for entire StackSets).
Property Comparison: CloudFormation calls the respective AWS service read APIs (such as ec2:DescribeSecurityGroups or s3:GetBucketEncryption ) and executes a deep property comparison against the expected resource properties recorded in the stack's template snapshot.
Status Assignment: CloudFormation assigns drift statuses across multiple levels:
Drift Status Hierarchies
Resource Drift Status:
IN_SYNC : Live properties match the CloudFormation template specification exactly.
MODIFIED : One or more property values have been changed out-of-band.
DELETED : The physical AWS resource was deleted out-of-band outside CloudFormation.
NOT_CHECKED : The resource type is not currently supported by drift detection.
Stack Drift Status:
IN_SYNC : All supported resources are IN_SYNC .
DRIFTED : One or more resources are MODIFIED or DELETED .
StackSet Drift Status:
Aggregates drift across all stack instances. Reports DRIFTED if any stack instance in any account/region is drifted.
Exam Watchout: Drift detection is a read-only diagnostic operation . Detecting drift never alters live resources, rolls back changes, or updates the template automatically. Drift remediation requires explicit DevOps action.
Drift Remediation & Resource Import
When drift is identified on the DOP-C02 exam, you must select the appropriate remediation strategy based on whether the out-of-band change was authorized or unauthorized. [Drift Detected: Status DRIFTED]
│
Is the out-of-band modification intentional / authorized?
- │
- ┌─────────────────┴─────────────────┐
- ▼ YES ▼ NO
- [Reconcile IaC Template] [Overwrite Live Drift]
- │ │
- Update CloudFormation template to Execute Stack Update using
- reflect live properties (or run existing template to force
Resource Import change set). live state back to IaC.
- │ │
- ▼ ▼
- [State: IN_SYNC] [State: IN_SYNC]
- Strategy 1: Remediating Unauthorized Drift (Overwriting)
If the modification was unauthorized (e.g., an engineer opened port 22 to 0.0.0.0/0 on a security group), execute an UpdateStack operation using the existing template. CloudFormation re-evaluates the desired state, detects the discrepancy, and re-applies the template properties, closing the security vulnerability.
Strategy 2: Remediating Authorized Drift (Updating Template)
If the out-of-band change was an authorized emergency hotfix (e.g., adjusting an Auto Scaling Group maximum capacity during a flash sale), update the CloudFormation template in git to match the new live configuration and deploy the updated template. This clears the drifted state while maintaining the fix.
Resource Import into Existing Stacks
Historically, if a resource was created outside of CloudFormation (manually or via third-party scripts), bringing it under IaC required deleting the live resource and recreating it through a stack—causing unacceptable production downtime.
CloudFormation Resource Import enables you to import existing, unmanaged AWS resources into an existing or new CloudFormation stack without disruption:
Identify Existing Resources: Identify the live resource identifier (e.g., S3 bucket name prod-assets-12345 , VPC ID vpc-0abc123 , or IAM Role name).
Update Template: Add the exact resource declaration to the CloudFormation template. Ensure the declared properties match the live resource configuration.
Create Import Change Set: Execute CreateChangeSet specifying ChangeSetType: IMPORT : aws cloudformation create-change-set \
- -stack-name Production-Infrastructure \
- -change-set-name ImportExistingBucket \
- -change-set-type IMPORT \
--resources-to-import '[{"ResourceType":"AWS::S3::Bucket","LogicalResourceId":"ApplicationBucket","ResourceIdentifier":{"BucketName":"prod-assets-12345"}}]' \
--template-body file://updated-template.yaml
Inspect & Execute: Run describe-change-set to verify the action displays Action: Import . Execute the change set via execute-change-set . CloudFormation links the existing physical resource to the logical resource ID without recreating or modifying the resource.
Verify Sync: Run drift detection to confirm the newly imported resource reports IN_SYNC .
Exam Trap: When importing resources, always specify DeletionPolicy: Retain on the resource in the template. If the import process is canceled or fails during refactoring, a Retain policy prevents CloudFormation from inadvertently deleting the live production resource.