Reusable modules, nested stacks, and StackSets

Exam alignment: Domain 2 tasks covering reusable infrastructure, automated account/resource onboarding, and configuration management.

Learning objective

Design, implement, and troubleshoot component interfaces, composition, multi-account distribution, rollout controls in a repeatable, secure, and operationally scalable way.

Professional scenario

A growing organization has many teams, AWS accounts, and Regions. Manual provisioning and configuration have created drift, inconsistent controls, unclear ownership, and slow onboarding. The platform team must standardize the environment without becoming a manual bottleneck.

Core concepts

• Define a clear desired state and version it.
• Separate control-plane permissions from execution permissions.
• Prefer managed, organization-aware capabilities over large custom scripts when they satisfy the requirement.
• Test at small scope before broad rollout.
• Make failure tolerance, concurrency, rollback, and exception handling explicit.
• Record evidence so configuration and governance decisions are auditable.

Architecture walkthrough

1. Define the standard and its owner.
2. Package the standard as infrastructure code, configuration, policy, or approved product.
3. Validate syntax, behavior, permissions, and replacement risk.
4. Deploy to a sandbox or small organizational unit.
5. Observe events, compliance, and operational metrics.
6. Expand in controlled waves.
7. Detect drift and process exceptions.
8. Version and improve the standard.

Decision guide

Requirement	Preferred direction	Why
Reusable infrastructure	Versioned component with a stable interface	Reduces duplication
Multi-account deployment	Organization-aware managed deployment	Central control at scale
Large fleet operation	Rate controls and staged waves	Limits blast radius
Temporary exception	Owner, reason, approval, and expiry	Prevents permanent hidden drift
Sensitive execution	Scoped role and protected configuration	Enforces least privilege

Failure modes and troubleshooting

• A permission is allowed by IAM but denied by an SCP, resource policy, KMS key policy, or permissions boundary.
• A broad rollout exceeds concurrency or failure-tolerance settings.
• A component changes without versioning and breaks consumers.
• A retained or imported resource has no clear cleanup owner.
• Drift is detected, but the team cannot determine whether the template or the live setting is approved.
• An automatic remediation repeats a destructive action.

Security and operations

• Use scoped deployment and automation roles.
• Protect parameters, secrets, logs, templates, and account metadata.
• Audit changes to policies, baselines, products, and controls.
• Do not store secrets directly in templates or source.
• Test backup, recovery, and cleanup for stateful resources.

Hands-on lab

Goal: Create a controlled design or small implementation for Reusable modules, nested stacks, and StackSets.

Tasks

1. Write functional, security, and operational requirements.
2. Draw the control plane, target accounts or nodes, and execution roles.
3. Build a minimal template, construct, document, rule, or policy.
4. Introduce one controlled failure.
5. Diagnose it from service events and logs.
6. Define staged rollout and rollback.
7. Document cost and cleanup.

Validation

• The workflow is repeatable and idempotent.
• The result can be audited.
• Failure is contained by scope, concurrency, or tolerance settings.
• No secret is exposed.
• Cleanup ownership is explicit.

Cost control: Prefer design simulation for organization-wide services. Keep deployments small and remove all test resources.

Cleanup

1. Delete test stacks, rules, associations, products, documents, and roles.
2. Remove retained resources only after checking dependencies.
3. Delete temporary logs and artifacts according to policy.

Exam traps

• Confusing a guardrail with a permission grant.
• Choosing a custom Lambda workflow when StackSets, Systems Manager, Config, or Control Tower already provides the required capability.
• Assuming that drift should always be overwritten immediately.
• Rolling out to every account at once.
• Ignoring replacement, retention, or cleanup behavior.

Key takeaways

• Configuration management is continuous, not a one-time deployment.
• Reusable standards require stable interfaces, ownership, and versioning.
• Organization-scale automation requires controlled failure behavior.
• Governance combines preventive, detective, and corrective mechanisms.

Review questions

1. What is the desired state in this lesson?
2. Which service or component owns execution?
3. Which permission layers can affect the action?
4. How is rollout limited?
5. How is drift detected?
6. How are exceptions governed?
7. What is the rollback or recovery path?
8. Which evidence proves success?

Answers

1. The approved versioned configuration.
2. The scoped managed-service role or automation workflow.
3. IAM, resource policies, SCPs, permissions boundaries, and KMS where applicable.
4. By OUs, Regions, waves, concurrency, and failure tolerance.
5. Through CloudFormation, AWS Config, Control Tower, or operational-state comparison.
6. With owner, reason, approval, scope, and expiry.
7. Revert the managed change, restore state, or return to the previous version.
8. Events, compliance results, outputs, logs, and change history.