Skip to main content

Technical Lab: Configure storage account encryption

Questions​

Question 1 — Multiple Choice​

A security team requires that all encryption keys used in Azure storage accounts be manually rotated by the organization, without any dependency on Microsoft-managed keys. Which configuration meets this requirement?

A. Enable infrastructure encryption with Microsoft-managed keys (MMK)

B. Use customer-managed keys (CMK) stored in Azure Key Vault with manual rotation configured

C. Enable blob versioning combined with Microsoft-managed keys

D. Configure immutability policies on the storage account with encryption scope

Question 2 — Technical Scenario​

An administrator created an encryption scope on a storage account with the following configuration:

az storage account encryption-scope create \
  --account-name mystorageaccount \
  --name myencryptionscope \
  --key-source Microsoft.Storage

Subsequently, the security team requests that this scope start using a key stored in Azure Key Vault. The administrator executes a second command to update the scope with --key-source Microsoft.KeyVault and the key URI.

After the update, what happens to existing blobs that were encrypted with the previous scope?

A. The blobs need to be manually re-encrypted, as the key source change is not retroactive

B. The blobs are automatically re-encrypted in the background with the new Key Vault key

C. The blobs remain accessible and are re-encrypted transparently only on the next read operation

D. Azure blocks the scope update while there are blobs associated with it

Question 3 — True or False​

When infrastructure encryption is enabled on an Azure storage account, data is encrypted twice at rest: once at the service layer and a second time at the infrastructure layer, using independent algorithms and keys.

  • True
  • False

Question 4 — Multiple Choice​

A company uses customer-managed keys (CMK) with Azure Key Vault to encrypt a storage account. The Key Vault administrator, without notifying the storage team, temporarily disables the key in the vault.

What is the immediate behavior of the storage account after the key is disabled?

A. The storage account automatically reverts to Microsoft-managed keys until the key is re-enabled

B. Read operations continue working, but write operations are blocked

C. The storage account becomes inaccessible for both read and write until the key is restored

D. Azure automatically generates a new key version in the Key Vault to maintain availability

Question 5 — Technical Scenario​

A developer reports that when uploading blobs to a specific container, the files are not being encrypted with the default encryption scope configured on the storage account. He uses the following command:

az storage blob upload \
  --account-name mystorageaccount \
  --container-name mycontainer \
  --name myfile.txt \
  --file ./myfile.txt

The default encryption scope was defined on the account, but the container has no scope configuration. What is the most likely cause of the reported behavior?

A. The az storage blob upload command ignores encryption scopes by default and always uses Microsoft-managed keys

B. The account's default encryption scope only applies to blobs uploaded via the Azure portal, not via CLI

C. The container did not inherit the account's default scope because the --default-encryption-scope configuration was not applied to the container at the time of its creation or update

D. The account's default encryption scope is applied only to new containers created after its definition, and blobs in existing containers require the scope to be explicitly specified during upload

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

Customer-managed keys (CMK) stored in Azure Key Vault are the correct mechanism when the organization needs full control over the key lifecycle, including manual rotation. The administrator defines when and how the key is rotated, without dependency on Microsoft.

Alternative A describes exactly the opposite of the requirement: MMK are managed by Microsoft. Alternative C combines blob versioning with MMK, which doesn't solve the key control requirement. Alternative D confuses immutability with encryption, which are distinct controls with different purposes.

The central misconception of the distractors is associating "more security" with more features, when the requirement is specifically about key ownership.

Answer Key — Question 2​

Answer: B

When an encryption scope is updated to use a new key source or new key, Azure automatically re-encrypts all data associated with that scope in the background. The process is transparent and requires no manual intervention nor causes unavailability.

Alternative A represents a common misconception: assuming that encryption in Azure works like on-premises systems where key changes require manual reprocessing. Alternative C is plausible but incorrect: re-encryption doesn't occur only on read, it's proactive. Alternative D contradicts Azure's actual behavior, which allows scope updates even with existing blobs.

Understanding that re-encryption is automatic and asynchronous is essential for planning CMK migrations without operational impact.

Answer Key — Question 3​

Answer: True

Infrastructure encryption adds a second layer of encryption at rest, operating below the service layer. The two layers use AES-256, but with independent keys: the service layer uses keys configured by the administrator (Microsoft-managed or customer-managed), while the infrastructure layer uses Microsoft-managed keys at the platform level.

This configuration is enabled at storage account creation time and cannot be activated on existing accounts. The main risk of marking as false is confusing double encryption with redundancy without value, when in practice it meets compliance requirements that demand encryption at multiple independent layers.

Answer Key — Question 4​

Answer: C

When the CMK key in Key Vault is disabled or deleted, Azure Storage loses access to the cryptographic material needed to decrypt the envelope keys that protect the data. The result is complete blocking: neither read nor write operations work until the key is restored and accessible again.

Alternative A represents desirable but non-existent behavior: Azure doesn't automatically fall back to MMK, as this would violate the key sovereignty model that CMK aims to guarantee. Alternative B is a misconception that underestimates the impact: reads also depend on the key. Alternative D describes behavior that never occurs, as Azure never generates keys in the customer's vault without explicit authorization.

This scenario reinforces the need for Key Vault access policies with proper monitoring and alerts when CMK is in use.

Answer Key — Question 5​

Answer: C

The default encryption scope defined on the storage account is not automatically propagated to existing containers. For a container to use a default scope, it must be explicitly configured with --default-encryption-scope during creation or through a subsequent update with az storage container set. Without this configuration on the container, blobs uploaded without specifying a scope in the upload operation use the account's default behavior, which may differ from the expected scope.

Alternative A is false: CLI respects encryption scopes normally. Alternative B is false: there's no behavioral distinction between portal and CLI for scopes. Alternative D is plausible but incorrect: the account's default scope applies to containers without their own configuration, except when the container has its own scope configuration defined, which is not the case described.

The most common error here is assuming that account configurations automatically propagate to all child resources, when in practice containers have independent encryption scope configuration.