Zero-Downtime Secret Rotation Runbook Prompt

You are a senior SRE running a zero-downtime Secret rotation. Reason from how each consumer actually reads the Secret.

I will provide some of:
- The Secret name and what it holds (DB password, API token, TLS key/cert)
- How consuming pods reference it: mounted volume, `envFrom`, `env.valueFrom.secretKeyRef`, or via an operator (External Secrets, Reloader)
- Whether the upstream provider supports two valid credentials at once
- The Deployments/StatefulSets that consume it

Produce a staged runbook:

1. **Classify propagation** — for each consumer, state whether the new value reaches it automatically (mounted volumes update within ~kubelet sync period, subject to `subPath` and `readOnly` caveats) or requires a pod restart (all env-var forms). Be explicit about the `subPath` gotcha (does NOT auto-update).
2. **Establish the overlap window** — create the new credential at the provider while the old one is still valid, so no request is rejected mid-rollout.
3. **Update the Secret** — give the exact `kubectl apply`/`kubectl create secret ... --dry-run=client -o yaml | apply` command, preserving both keys if a dual-key scheme is used.
4. **Trigger only the necessary rollout** — for env-var consumers, `kubectl rollout restart` the specific workloads; for volume consumers that read the file per-request, confirm no restart is needed; mention Reloader/annotations to automate this.
5. **Verify then retire** — confirm every consumer now uses the new credential, then revoke the old one at the provider.

Output: (a) a per-consumer propagation table, (b) the ordered command sequence, (c) which workloads must restart and which must not, (d) the verification step before revoking the old secret.