Terraform Write-Only Argument Migration Prompt
Migrate existing secret arguments that linger in state (passwords, tokens) to write-only arguments and their `_wo_version` triggers, so sensitive values stop being persisted in the state file.
- Target user
- Engineers hardening Terraform configs that store secrets in state
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a Terraform expert who knows that ordinary resource arguments — even `sensitive` ones — get written into the state file in plaintext, and that the modern fix is *write-only* arguments (the `_wo` variants, e.g. `password_wo`) paired with a `_wo_version` field that controls when the value is re-sent. You're helping retrofit this onto a config that currently stores secrets in state. I will provide: - The resources and arguments that currently hold secrets in state ([SECRET_ARGUMENTS]) - The provider and resource versions (write-only support is provider- and version-specific) - Where the secret value comes from (an ephemeral resource, a Vault/SM data source, a variable) Your job: 1. **Confirm support** — verify the specific provider/resource/version actually exposes a write-only variant for each argument ([SECRET_ARGUMENTS]). If it doesn't, say so plainly and recommend the next-best mitigation rather than inventing an argument that doesn't exist. 2. **Source the value ephemerally** — write-only arguments must be fed from values that aren't themselves persisted; show wiring from an `ephemeral` resource or a secrets-manager data source, never from a plain variable that lands in state. 3. **Author the migration** — replace `password = ...` with `password_wo = ...` plus `password_wo_version = N`, and explain that bumping `_wo_version` is the *only* way to force the value to be re-sent (since Terraform can't diff a value it doesn't store). Show how to set the initial version. 4. **Clean the old value out of state** — describe the steps so the previously-persisted plaintext secret is no longer in state after migration, and note that historical state versions/backups may still contain it (rotate the secret). 5. **Plan and verify** — the plan should show the write-only argument with no plaintext value, and a subsequent `terraform state show` should reveal no secret. Confirm idempotency: re-running without bumping `_wo_version` should be a no-op. Output as: (a) the support confirmation per argument, (b) the ephemeral/data-source wiring, (c) the rewritten resource with `_wo`/`_wo_version`, (d) the state-cleanup and secret-rotation steps, (e) the verification that state no longer holds the plaintext. Treat the existing state as compromised: review the plan, and rotate any secret that was previously stored in plaintext rather than assuming the migration alone is sufficient.
Why this prompt works
Most teams discover the state-secrets problem too late: they marked an argument sensitive and assumed that protected it, not realizing sensitive only redacts CLI output while the value still sits in the state file in plaintext. Write-only arguments are the real fix, but retrofitting them onto an existing, already-leaking config is a different job from greenfield adoption. The prompt is built around that retrofit, and it opens by forcing a support check — because write-only variants exist only for specific resources at specific provider versions, and the worst failure mode is an AI confidently hallucinating a password_wo that the provider never shipped.
The mechanics it encodes are the two things people get wrong. First, write-only values cannot come from ordinary variables (those land in state too); they have to be sourced from an ephemeral resource or a secrets-manager data source, so the prompt makes that wiring explicit. Second, because Terraform stores nothing to diff against, the _wo_version integer is the only lever that forces the value to be re-sent — the prompt makes the model explain this so engineers understand why a plain rotation looks like a no-op until they bump the version.
Crucially, the prompt refuses to let the migration end at “we stopped persisting it.” A secret that was ever in state — including in remote-state version history and backups — must be treated as compromised and rotated. That insistence is what turns a feel-good config edit into an actual security remediation, and the verification step (a state show that reveals no secret, plus confirmed idempotency) keeps the whole thing in AI-drafts-human-verifies territory rather than blind trust.