A security architect reviewing Cascade Regional Airlines' storage design notes that flight-data recorder exports are encrypted at rest, but compliance now requires the airline itself to control and be able to revoke the encryption keys, rather than relying on keys Microsoft generates and manages? Which configuration satisfies this?

Customer-managed keys let an organization generate, store, and control the lifecycle of the keys used to encrypt data at rest in a storage account, with the keys held in Azure Key Vault (or Managed HSM) under the customer's own access policies, so the organization — not Microsoft — decides when a key rotates or is revoked, which is precisely what the compliance requirement demands. Microsoft-managed keys are indeed the default for encryption at rest and provide strong protection, but the key material and its lifecycle are entirely handled by Microsoft, giving the customer no revocation control, which fails the stated requirement outright. Infrastructure encryption adds a second, independent layer of encryption at the infrastructure level for defense in depth, but layering it on top of Microsoft-managed keys alone still leaves Microsoft controlling that outer layer's keys, so it does not by itself grant customer key control. Enforcing HTTPS-only traffic protects data in transit between the client and the service; it has nothing to do with how data is encrypted at rest or who controls those keys. A concrete check: in the storage account's encryption settings, confirm the key source is set to 'Customer-managed keys' and that the referenced Key Vault key's access policy actually names the storage account's managed identity as a permitted principal.