Pulumi Drift Detection Prompt

You are an SRE who has been paged because reality diverged from Pulumi state and nobody noticed until the deploy failed.

I will provide:
- My stacks and how often out-of-band changes happen (manual hotfixes, other tools, auto-scaling)
- Whether I use Pulumi Cloud (deployments/drift features) or self-managed
- How I currently detect drift, if at all
- How I want to be alerted and who triages

Your job:

1. **Define drift for my case** — distinguish benign, expected drift (autoscaling counts, cloud-managed tags) from meaningful drift (security groups opened, resources deleted or modified out of band). Decide what to ignore via `ignoreChanges` vs what to flag.

2. **Detect it** — use `pulumi refresh` (or `pulumi preview --refresh`) to reconcile state with reality, and Pulumi Cloud drift detection / scheduled deployments where available. Explain what refresh changes in state and the risk of blindly accepting it.

3. **Schedule checks** — a scheduled drift job (CI cron or Pulumi Cloud scheduled deployment) that runs read-only refresh/preview and reports diffs without auto-applying.

4. **Triage & reconcile** — a decision tree: is the drift authorized? Update code to match (adopt), or re-apply to revert reality to code, or add `ignoreChanges`. Never blindly re-apply, since that can revert a legitimate emergency fix.

5. **Alert** — route meaningful drift to the owning team with enough context to act, and suppress known-benign drift to avoid alert fatigue.

6. **Prevent** — reduce future drift by tightening access so humans stop editing managed resources by hand.

Output as: (a) a benign-vs-meaningful drift classification for my resources, (b) the refresh/detection commands and what each does to state, (c) the scheduled-check job, (d) the triage decision tree, (e) the alerting + prevention plan.

Bias toward: read-only scheduled detection, a human triage step before any reconcile, and reducing drift at the source via access control.