Canal-app password rotation will land a new value in Key Vault. How should the security engineer stage the change?
Select an answer to reveal the explanation.
Short Explanation
Rotate by adding a new version, not by torching the only copy. Leave the old version around until every canal-app instance has moved to the current one.
Full Explanation
Key Vault secrets and keys are versioned. Staging canal-app password rotation correctly means creating a new secret (or key) version, pointing callers at the current version as they recycle, and retaining the previous version until every instance has moved. That dual-version window prevents a hard cut where half the fleet still expects the old material while the only version was already destroyed.
Overwriting the only secret version in place and deleting all prior versions before any application recycles fails by concept: it creates an immediate dependency on synchronized restarts and removes rollback. Emailing the plaintext password to operators and skipping Key Vault versioning fails confidentiality and auditability. Disabling versioning and storing each rotation under a randomly renamed secret every week fails operationally—applications must constantly retarget names, and Key Vault already versions objects without renames.
Exam caveat: “current” versus explicit version identifiers matter for clients—know whether the app pins a version GUID or always reads latest. Operational check: create a new secret version with the rotated password, update or recycle apps to the new current version, confirm old version still retrieves during overlap, then disable or remove the old version only after fleet health checks pass.