Secret rotation is easier when you know every place the credential is used. A podcast API key may serve a web backend, a scheduled worker, a test job, and a support script. Updating one environment variable does not prove that all callers changed.
Begin with an inventory of callers and owners. Record secret names and deployment locations, not the secret values themselves.
Prepare the replacement path
Use the provider's documented key-management flow and confirm whether more than one active key is allowed. Do not assume a safe overlap exists. If the provider supports it, introduce the replacement before retiring the older key.
Deploy the new secret through your normal release process. Run a small authorized request from each environment that should use it. Check both a permitted operation and an operation the key should not be allowed to perform.
Watch authentication failures and request volume after the change. A quiet background worker may not run until hours later, so its schedule belongs in the handover plan.
When the replacement has been verified, revoke the old key using the documented mechanism. Removing it from a configuration file alone does not stop another copy from working.
Prepare for exposure separately
Routine rotation can use a planned overlap. A known exposed credential may require faster revocation and a different tradeoff. Keep that response procedure ready before you need it.
After the change, search logs and build artifacts for accidental copies. Update local developer instructions and remove obsolete secret references from deployment configuration.
A rotation record should say which credential identity changed, when it was retired, and what was checked. It should never contain the plaintext key that the team is trying to protect.