The grain-silo storage account key appeared in a support ticket. How should the security engineer rotate keys with minimal downtime?
Select an answer to reveal the explanation.
Short Explanation
Two keys are like two spare dock keys on a ring. Swing apps to key2, cut key1, then swing back—don’t sink the whole silo account.
Full Explanation
When the grain-silo storage account key appeared in a support ticket, rotate with minimal downtime using the two-key pattern: move applications to key2, regenerate key1 (the exposed key), then optionally flip applications back and regenerate the other key as needed. Each storage account exposes two access keys specifically so operators can rotate without deleting the account or causing an immediate outage. For civic silo data, that preserves availability while invalidating the leaked credential.
Deleting the storage account and recreating it with a new name so both keys disappear fails by concept: recreation destroys data, endpoints, RBAC assignments, and downstream identity bindings far beyond key rotation. Regenerating key1 and key2 at the same moment while every app still references key1 fails because simultaneous regeneration of the in-use key causes widespread authentication failures. Disabling the storage firewall so leaked-key traffic is easier to spot, then leaving both keys unchanged, fails because network rules do not invalidate a leaked key and opening the firewall worsens exposure.
Exam caveat: always rotate using the unused peer key first; never regenerate both keys simultaneously while production still depends on one of them. Operational check: identify which key is in the ticket, switch apps and Key Vault secrets to the other key, regenerate the compromised key, verify silo workloads recover, hunt for remaining embeds of the old key in tickets and pipelines, and prefer Entra data-plane access going forward so standing keys are less critical.