What this prompt does
This prompt writes a zero-downtime secrets-rotation runbook that an on-call engineer can follow at 3am — exact commands, real verification, no hand-waving. The structure enforces a safe dual-secret overlap: preflight checks, add the new secret alongside the old, roll consumers to read both, switch writers, verify, and only then remove the old secret. Every stage carries its own verification and rollback step, so a tired engineer never has to improvise.
The variables make the runbook executable. [secret_type] (for example, a database master password) sets what is being rotated and how it is referenced. [consumers] lists every service that reads the secret — api, workers, a reporting job — so the rollout covers each one and nothing is forgotten. [secret_store] determines the exact commands, because rotating in AWS Secrets Manager looks different from Vault or a Kubernetes secret.
When to use it
- You need to rotate a credential without taking the system down
- You want a runbook precise enough to follow under pressure at 3am
- Multiple services read the secret and must all migrate before the old one dies
- You want a dual-secret overlap window so nothing reads a value that no longer exists
- You need per-stage verification and rollback, not a single fragile sequence
- You are rehearsing the rotation in staging before touching production
Example output
The model returns a numbered runbook where each step carries the actual command for your secret store, a verify block, and a rollback block. It moves through preflight (who reads the secret, current version, blast radius), adding the new secret, rolling consumers to read both, switching writers, verifying, and removing the old secret last — with a total expected duration so you know how long the window runs.
Pro tips
- List every reader in
[consumers]; the classic failure is deleting the old secret before one forgotten service has picked up the new one - Set
[secret_store]exactly so the commands match — Secrets Manager, Vault, and Kubernetes secrets each rotate differently - Describe
[secret_type]precisely, since a database password rotation has different verification than an API key - Keep the dual-secret overlap window; never remove the old value until every consumer is confirmed off it
- Rehearse the rollback in staging before you run this in production, so the 3am path is one you have already walked
- Use the per-stage verify blocks as gates — do not advance to the next step until the current one verifies clean
- Note the total expected duration up front so the on-call knows how long the overlap window runs and when it is safe to remove the old secret
- Confirm the blast radius in the preflight step so you know exactly which services break if the rotation goes wrong
