A reviewer starts answering the grain-silo BYOK task by drafting Key Vault access-policy JSON, private-endpoint rules, and a rotation schedule. For Domain 3 storage encryption, what is the correct focus?
Select an answer to reveal the explanation.
Short Explanation
Domain 3 is the silo saying “use that key.” Domain 4 is running the Key Vault itself—networks, who can touch keys, rotation. Don’t rewrite the vault handbook when the ask is just pointing Storage at the CMK.
Full Explanation
When the task is to make a storage account use a customer-managed key, the Domain 3 action is on the storage encryption settings: select the Key Vault key URI (or encryption scope backed by that key) so Azure Storage uses that protector for SSE. Network lockdowns, RBAC, soft-delete, and rotation schedules are Key Vault administration (often Domain 4 style work) and may be required operationally, but they do not themselves point the storage account at the CMK. Replacing the storage CMK configuration with a full Key Vault network lockdown first confuses prerequisites with the actual encryption binding. Storing the storage account name as a Key Vault secret is ordinary secret storage; it is not Bring Your Own Key for SSE. An Azure Policy that only audits Key Vault soft-delete improves vault hygiene but never configures storage encryption. Exam caveat: the storage account identity still needs unwrap permission on the key, and encryption scopes can apply different keys per container or blob path—know whether the ask is account-level CMK or scope-level. Operational check: in the storage account encryption blade (or ARM/Bicep property), confirm the CMK URI or scope, test a write/read after the change, and separately verify vault firewall and RBAC only after the storage binding is correct so troubleshooting does not mix “key not selected” with “vault unreachable.”