The grain-silo storage account still uses Microsoft-managed keys, and auditors want the canal authority to hold the encryption key. How do you configure Bring Your Own Key for Storage encryption?

Customer-managed keys (CMK) for Azure Storage mean the account encrypts data with a key you control in Azure Key Vault or Azure Key Vault Managed HSM. You create or import the key, then grant the storage account’s system- or user-assigned managed identity permission to wrap and unwrap that key so Storage can use it for server-side encryption without embedding raw key material in the account. That is the supported bring-your-own-key path auditors expect when the canal authority wants custody of key lifecycle separate from Microsoft-managed SSE. Pasting a customer passphrase into the access-key blade does not replace Microsoft-managed encryption with CMK; access keys are account credentials, not the SSE key hierarchy. Disabling encryption at rest is not a valid control plane for “managing keys outside Azure”—Azure Storage encrypts at rest by default, and turning protection off is not the CMK design. Classic storage models and on-premises-only HSM appliances are not the modern CMK configuration for a general-purpose Azure Storage account in this exam domain. Exam caveat: CMK still uses Azure’s encryption stack; you control the key material and rotation, not a completely separate on-disk cipher that bypasses Storage. Operational check: after assigning the CMK, verify the account encryption shows customer-managed, confirm the managed identity has get/wrap/unwrap on the key, rotate or disable the key in a non-production account to validate failure modes, and ensure purge protection and soft-delete on the vault protect the key the storage account depends on.