A teammate committed a production database password as an ordinary value in `Pulumi.prod.yaml` rather than with `--secret`. What do you do, and what does `pulumi stack change-secrets-provider` actually re-encrypt?

## First: the value is burnt A plaintext credential in a committed file has been distributed to everyone who cloned the repository, every CI cache, and every fork or mirror. Encryption applied afterwards protects the *next* value, not this one. So the first action is at the source system: rotate the database password. Nothing in the tool changes that ordering, and an interviewer asking this question is largely checking that you say it before you say anything about Pulumi. ## Second: put the replacement in correctly ```bash pulumi config set --secret dbPassword "$NEW_PASSWORD" --stack prod pulumi up --stack prod ``` Now `Pulumi.prod.yaml` holds: ```yaml config: myapp:dbPassword: secure: v1:...:ciphertext... ``` and the value is encrypted both there and, once it flows into the resource, in the stack's checkpoint. Confirm with `pulumi config get dbPassword --stack prod`, which prints `[secret]` unless you add `--show-secrets`. ## Third: contain the exposure - **Git history.** The old commit still contains the plaintext. Rewriting history is possible but disruptive and never complete once the repository has been cloned; do it if policy requires, and treat rotation as the real remedy. - **CI logs.** A non-secret config value shows up in preview output and diffs. Check whether the pipeline printed it, and whether those logs are retained and readable by a wider group than the repository. - **Anywhere the value was copied.** A password set in the clear tends to have been pasted elsewhere too. ## What `change-secrets-provider` is for ```bash pulumi stack change-secrets-provider "awskms://alias/pulumi-prod?region=eu-west-1" --stack prod ``` This re-encrypts the stack's secrets under a new provider: the secret config values in `Pulumi.<stack>.yaml` and the secret properties recorded in the stack's state. The stack file's key material is rewritten accordingly — the `encryptionsalt` of a passphrase provider gives way to the new provider's settings. The legitimate uses are: - Migrating from a shared `passphrase` to a cloud KMS key so decryption becomes an auditable, revocable IAM grant. - Rotating after someone with the passphrase leaves, since a shared string cannot be revoked from one person. - Moving a stack to a different backend or account where the old key is not reachable. The limits are the point of the question. It re-encrypts what is already *marked* secret; a value stored as ordinary config stays ordinary. And it operates on the current stack state and config — it does not reach into git history, CI logs, or the copy in someone's shell history. ## Fourth: stop it recurring The durable fixes are cheap: - **Review stack-config diffs.** Any new key in `Pulumi.<stack>.yaml` whose value is not under `secure:` and whose name looks credential-shaped should stop a pull request. - **Secret scanning in pre-commit and CI.** The same scanner you run over source code should cover stack config files. - **Prefer never having the value at all.** Where the platform supports it, generate the credential in the program or read it from a secret store at deploy time, so no human ever types it into config and no plaintext version exists to commit. - **Watch `--show-secrets` in pipelines.** It is the other common way a properly stored secret ends up in a log. ## The summary an interviewer wants Rotate first because the tool cannot un-leak a value; re-set it with `--secret` so the file carries ciphertext; use `change-secrets-provider` for key hygiene — moving off a shared passphrase or rotating after a departure — and be clear that it re-encrypts existing secrets rather than reclassifying values that were never secret.