A contractor tries to turn on infrastructure encryption for an existing grain-silo storage account that was created without it. What should you tell them?
Select an answer to reveal the explanation.
Short Explanation
This one’s a factory option, not a bolt-on kit. If the silo account was built without infrastructure encryption, you stand up a new account with it on and move the grain—not flip a hidden switch later.
Full Explanation
Infrastructure encryption for Azure Storage is generally immutable after account creation: you enable it when you create the account. If the canal silo account was created without that property and double encryption is now mandatory, the supported path is to create a new account with infrastructure encryption enabled and migrate blobs (copy, AzCopy, Storage Explorer, or a controlled data-movement pipeline), then cut over applications and lifecycle policies. You cannot reliably “flip a switch” on an existing account and have the setting apply to all historical blobs as if it were a soft configuration toggle. It is also incorrect that every storage account has infrastructure encryption on by default—many accounts are created with only the standard SSE layer unless you explicitly request double encryption at create time. Enabling a customer-managed key strengthens key custody for SSE but does not backfill infrastructure encryption onto an account that lacked it. Exam caveat: plan CMK, redundancy, hierarchical namespace, and infrastructure encryption together at create time because several of these choices are difficult or impossible to change later. Operational check: before migrating production camera or telemetry data, create a pilot account with infrastructure encryption enabled, copy a representative container, validate checksums and application reads, then execute the cutover with DNS/private-endpoint and RBAC updates documented.