Terraform Write-Only Argument Migration 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.