GitOps Secret Rotation Automation Design Prompt
Design an automated secret rotation flow that fits a GitOps model, keeping plaintext out of Git while rotating credentials, resyncing consumers, and rolling back cleanly if a rotated secret breaks a workload.
- Target user
- Platform engineers running GitOps with sealed or external secrets
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a platform engineer whose cluster is reconciled from Git, where a hand-rotated database credential once left half the pods on the old secret and half on the new one until a painful manual resync. I will provide: - The GitOps controller (Argo CD, Flux) and the secret mechanism (Sealed Secrets, External Secrets Operator, SOPS, Vault agent) - The credential(s) to rotate, their consumers, and how each consumer picks up a change - The rotation trigger (schedule, on-demand, breach) and the target rotation interval - The blast radius if a consumer is left on a stale or bad credential Your job: 1. **Source of truth** — define where the new secret material originates and how it reaches the cluster WITHOUT plaintext ever landing in Git for [SECRET_MECHANISM]. 2. **Two-phase rotation** — design a make-before-break flow: provision the new credential and grant it before revoking the old, so both are valid during the transition window. 3. **Consumer resync** — specify how each consumer reloads the secret (rolling restart, reloader annotation, sidecar refresh) and how the controller drives it deterministically. 4. **Reconciliation ordering** — order the Git commit, controller sync, consumer restart, and old-credential revocation so no consumer is ever left without a valid credential. 5. **Verification gate** — define the health check that must pass on the new credential before the old one is revoked, and what blocks revocation if it fails. 6. **Rollback** — describe how to revert to the previous credential if the rotation breaks a workload, given that Git is the source of truth. Output as: a phased rotation sequence, the secret-flow diagram (origin -> encrypted-in-Git -> cluster), the verification and revocation gates, and a rollback runbook. Test the full rotation on a non-production namespace and confirm every consumer is serving on the new credential before revoking the old one anywhere.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
Secret rotation and GitOps pull in opposite directions unless you design the seam between them. GitOps wants the desired state in Git; secrets must never sit in Git as plaintext. The failure this prompt targets is the classic half-rotation: someone updates the credential, the controller reconciles, and some pods restart onto the new secret while others keep the old — or worse, the old credential is revoked before the last consumer has picked up the new one. The prompt makes the model commit to a secret mechanism first, so the “how does new material reach the cluster without touching Git in plaintext” question is answered concretely rather than waved away.
The center of the design is two-phase, make-before-break rotation. A credential rotation is not a single atomic swap; it is provision-new, verify, then revoke-old, with a window where both are valid. Forcing that ordering — plus explicit consumer resync semantics, because a Kubernetes secret update does not restart pods by itself — is what prevents the stranded-pod outage. The prompt ties revocation to a verification gate rather than a timer, which is the single most common rotation mistake: revoking the old secret on a schedule while a slow or unhealthy consumer is still using it turns a routine rotation into an incident.
Because Git is the source of truth, rollback has to be a first-class, explicit path, not “edit it back and hope.” The model can lay out the phased sequence and gates quickly, but you rehearse the whole thing in a non-production namespace and confirm every consumer is on the new credential before revoking anywhere, since a rotation bug surfaces as authentication failures across workloads at exactly the moment the old credential dies.
Related prompts
-
Automation Credential Scoping and Least-Privilege Prompt
Lock down the credentials automated workflows use — scoping each automation's identity to least privilege, eliminating shared god-tokens, designing short-lived/just-in-time credentials, and bounding what a compromised automation could do.
-
GitOps Sync-Wave Dependency Ordering Design Prompt
Design sync-wave and hook ordering for a GitOps deployment so resources with real dependencies (CRDs before CRs, databases before apps, config before consumers) apply in the right order — with health gates between waves, idempotent pre/post hooks, and safe rollback when a mid-wave resource never becomes healthy.
-
n8n Credential Vaulting and Secret Handling Design Prompt
Design how an n8n automation handles credentials and secrets — external vaulting, scoped access, redaction in logs and error output — so a workflow can't leak the keys it runs with.
-
Webhook-to-Action Event Automation Design Prompt
Design an event-driven automation that turns an inbound webhook into a safe, bounded action — covering authentication, idempotency, allow-listing of which events may trigger which actions, and a read-only default so a spoofed or replayed event can never cause harm.
More Automation prompts & error guides
Browse every Automation prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.