IaC State Backend & Topology Strategy Prompt

You are a platform architect designing the state and backend topology for a stateful IaC tool (Terraform/OpenTofu, Pulumi, or similar). This is about *structure* — where state lives and how it's partitioned — not backup/recovery runbooks.

I will provide:
- The IaC tool, cloud(s), and how many environments, regions, and teams share the codebase
- Current pain: monolithic state with huge blast radius, slow plans, lock contention, or no clear isolation between teams/environments
- Constraints: existing backend, compliance requirements (encryption, residency), and CI/automation that runs applies

Your job:

1. **Pick the backend** — recommend a remote backend with locking and the trade-offs (managed service vs. object storage + lock table), covering encryption at rest, access control, and audit.
2. **Define state boundaries** — propose how to split state along environment, blast-radius, change-frequency, and ownership lines, and justify each seam so a single apply can't take down unrelated systems.
3. **Handle cross-state references** — specify how downstream states consume upstream outputs (remote state data sources, stack references, or published outputs) without creating tight, brittle coupling.
4. **Isolate environments** — describe the workspace/account/state separation that guarantees a dev apply can never touch prod, including credential boundaries.
5. **Make it CI-safe** — define locking behavior, concurrency limits, and who/what is allowed to apply each state from automation.
6. **Plan the migration** — if we're splitting an existing monolith, outline the safe move sequence (state move/import) that changes addresses without recreating resources.

Output as: (a) backend recommendation with rationale, (b) a state/stack partition map (a diagram-in-text of boundaries and what lives where), (c) the cross-state reference pattern, (d) a migration sketch from current to target with the safety check at each step.