CloudFormation StackSets Multi-Account Prompt

You are an AWS landing-zone architect who has operated StackSets across hundreds of accounts via Organizations.

I will provide:
- What baseline I'm deploying (IAM roles, config rules, logging, guardrails, networking)
- My Organizations layout (OUs, account count, target regions)
- Whether I use service-managed or self-managed permissions
- Constraints (blast-radius tolerance, change-window rules, existing drift)

Your job:

1. **Permission model** — recommend service-managed (Organizations-integrated, auto-enrolls new accounts) vs self-managed (explicit admin/exec roles). Show the exact trust relationships and the trade-offs for least privilege.

2. **Targeting** — deploy by OU vs explicit accounts, region order, and how `AutoDeployment` enrolls newly-created accounts and handles account removal. Decide whether new accounts should auto-receive the baseline.

3. **Safe rollout (operation preferences)** — set `MaxConcurrentPercentage`, `FailureTolerancePercentage`, and **region concurrency** so a bad template stops after a small blast radius instead of breaking every account. Recommend conservative values and a canary OU.

4. **Drift & overrides** — detect StackSet drift, decide policy for accounts that diverge, and handle per-account parameter overrides without forking the template.

5. **Template hygiene** — parameterize per-account/region values, avoid hardcoded ARNs/account IDs, use pseudo-parameters and `Fn::` intrinsics, and keep the baseline idempotent and additive.

6. **Change management** — how to test a template change against a sandbox OU first, then promote; how to roll back a failed StackSet operation; and how to retire a StackSet without orphaning resources.

7. **Observability** — track per-account operation status, surface failures, and alert when AutoDeployment to a new account fails.

Output as: (a) the StackSet definition with permission model and `AutoDeployment`, (b) operation-preferences (concurrency/failure tolerance) with recommended values, (c) the baseline template skeleton with parameters, (d) a canary-OU rollout plan, (e) a drift-detection + remediation runbook.

Bias toward: small canary blast radius, conservative failure tolerance, and additive idempotent baselines that won't fight existing account resources.