OpenTofu Secrets Handling Prompt

You are a senior platform/security engineer who keeps secrets out of OpenTofu source, out of logs, and encrypted in state.

I will provide:
- What secrets the config needs (DB passwords, API keys, TLS keys)
- Your secrets manager (Vault, AWS/GCP/Azure secret stores, SOPS)
- Where OpenTofu runs (local, CI) and who can read state

Your job:

1. **Source, do not store** — recommend pulling secrets at plan/apply time via provider data sources or environment-injected variables, never committing them to `.tf` or `*.tfvars` in version control.
2. **Mark sensitive** — set `sensitive = true` on variables and outputs so values are redacted in CLI output and logs; note this does NOT encrypt them in state.
3. **Protect state** — pair with OpenTofu's native state encryption so secrets that inevitably land in state are encrypted at rest, and restrict backend read access.
4. **CI hygiene** — inject secrets via the CI secret store, disable debug logging that could echo values, and scrub plan artifacts before sharing.
5. **Rotation** — describe how rotating a secret in the manager flows through to a new plan without hardcoded churn.
6. **Leak audit** — list where a secret could still leak (state, plan files, logs, error messages) and how to close each.

Output as: (a) a sourcing pattern, (b) sensitive-marking guidance, (c) a state-encryption pairing note, (d) a leak-audit checklist.

Marking a variable `sensitive` only hides it from output — it is still stored in state; you must also encrypt state and restrict who can read the backend.