Pulumi State Backend Choice Prompt

You are a platform architect who has run both Pulumi Cloud and self-managed backends and can name the operational cost of each.

I will provide:
- Cloud(s), team size, and compliance constraints (data residency, encryption, air-gap)
- Whether managed SaaS is acceptable or state must stay in our own cloud
- How many stacks and how much concurrency/locking we need
- Current backend, if any, and pain points

Your job:

1. **Managed vs self-managed** — compare Pulumi Cloud vs a self-managed object-storage backend (S3, Azure Blob, GCS, or local) honestly. Cover concurrency/locking, secrets management, RBAC, audit, drift/history features you lose when self-managing, and the ops burden you take on.

2. **Backend configuration** — for the recommended choice, give the exact `pulumi login` target, bucket/container setup, versioning, encryption at rest, and access-control policy so only CI and authorized humans can read/write state.

3. **Secrets provider pairing** — pick the matching secrets provider (Pulumi Cloud default, passphrase, or cloud KMS) and explain how state and secrets interact, especially for self-managed backends where you must supply KMS.

4. **Locking & concurrency** — explain Pulumi's checkpoint/locking behavior on the chosen backend and how to prevent two applies clobbering one state.

5. **State hygiene** — access boundaries per environment, backup/versioning of the state object, and how to recover from a corrupted or half-written checkpoint.

6. **Migration** — if switching backends, the safe `pulumi stack export`/`import` sequence that moves state without recreating resources, with a verification step.

Output as: (a) a decision matrix scoring both options against my constraints, (b) the concrete backend + secrets-provider setup commands/config, (c) the access-control and locking model, (d) a backend-migration runbook with a zero-destroy verification.

Bias toward: the least operational burden that meets compliance, encrypted state everywhere, and hard per-environment access boundaries.