Troubleshooting Lab: Configure storage account encryption
Diagnostic Scenarios
Scenario 1 — Root Cause
An operations team reports that a critical storage account stopped responding to any read and write operations approximately 40 minutes ago. No network or firewall changes were made to the account. The account has been using customer-managed keys (CMK) with Azure Key Vault for six months without issues.
The administrator runs a check and gets the following output:
az storage account show \
--name prodstorageacct01 \
--query "encryption" \
--output json
{
"keySource": "Microsoft.Keyvault",
"keyVaultProperties": {
"keyName": "storage-cmk-key",
"keyVaultUri": "https://prodkv01.vault.azure.net/",
"keyVersion": "a3f1c2e4d5b6...",
"currentVersionedKeyExpirationTimestamp": "2025-03-15T00:00:00Z",
"lastKeyRotationTimestamp": "2024-09-15T10:22:00Z"
}
}
The administrator also verifies that:
- The Azure Key Vault is in the same region as the storage account
- The Key Vault firewall allows access from trusted Microsoft services
- The storage account has ZRS redundancy configured
- Key Vault soft-delete is enabled with a 90-day retention period
What is the root cause of the observed failure?
A. The Key Vault firewall is blocking storage account access due to an undocumented configuration change
B. The CMK key expired, as the currentVersionedKeyExpirationTimestamp field indicates a date in the past
C. ZRS redundancy conflicted with CMK configuration during a zonal failure, causing temporary loss of access
D. Key Vault soft-delete was activated with a retention period incompatible with the key rotation policy
Scenario 2 — Action Decision
The security team identified that a production storage account is configured to use customer-managed keys (CMK), but the system-assigned managed identity lost the get permission in the Key Vault access policy after a permission reorganization performed yesterday.
The cause has been confirmed: the role assignment of the managed identity in the Key Vault was accidentally removed. The storage account data is inaccessible and there is active production impact. The Key Vault uses the Azure RBAC model for access control, not legacy access policies.
The following restrictions apply:
- The security team is still auditing all permissions modified yesterday and requests that no new permissions be assigned without formal approval
- The storage administrator has Contributor permission on the storage account
- The incident is classified as P1 with a 2-hour restoration SLA
- The administrator has Key Vault Administrator access to the affected Key Vault
What is the correct action to take at this time?
A. Immediately assign the Key Vault Crypto Service Encryption User role to the storage account's managed identity in the Key Vault, without waiting for approval, given the active production impact
B. Change the storage account's encryption configuration to Microsoft-managed keys (MMK) temporarily, restoring access while awaiting formal approval
C. Open the formal approval process with the security team, documenting the root cause and the specific role to be restored, and wait for approval before any permission assignment
D. Create a new user-assigned managed identity with the correct permission in the Key Vault and reassign it to the storage account to bypass the approval restriction
Scenario 3 — Root Cause
A developer reports that blobs uploaded to the raw-data container in a storage account are not being encrypted with the scope-raw encryption scope, which should be the default for that container. The blobs appear encrypted, but when verified, they use the account's default scope (scope-account-default).
The administrator verifies the current state with the following commands:
az storage account show \
--name analytics01 \
--query "encryption.defaultToOAuthAuthentication"
true
az storage container show \
--account-name analytics01 \
--name raw-data \
--query "{defaultScope:encryptionScope,preventOverride:denyEncryptionScopeOverride}"
{
"defaultScope": "scope-raw",
"preventOverride": false
}
The administrator also confirms that:
- The
scope-rawscope exists and is enabled in the account - The storage account has blob versioning enabled
- The container was created 3 weeks ago
- Uploads are done via SDK with OAuth authentication and without specifying an explicit scope
What is the root cause of the observed behavior?
A. Active blob versioning interferes with the application of per-container encryption scopes, forcing the use of the account's default scope
B. The preventOverride field is set to false, allowing the SDK to override the container's scope with the account's default scope during upload
C. OAuth authentication (defaultToOAuthAuthentication: true) prevents the container's encryption scope from being applied correctly when the scope is not explicitly specified in the operation
D. The SDK is explicitly specifying the scope-account-default scope during upload, overriding the container configuration, because preventOverride is set to false
Scenario 4 — Side Impact
A company maintains a storage account with customer-managed keys (CMK) using a key in Azure Key Vault. To meet a new compliance requirement, the administrator decides to enable infrastructure encryption on the existing storage account.
The administrator accesses the Azure portal, navigates to the storage account's encryption section and finds that the infrastructure encryption option is disabled and grayed out, with no possibility of editing. Without investigating further, he decides to recreate the storage account with the option enabled and migrate the data via AzCopy.
The recreation and migration are completed successfully. The new account has infrastructure encryption enabled and CMK configured correctly.
What secondary consequence could this action cause?
A. Data migrated via AzCopy loses association with the original encryption scope, being re-encrypted with the new account's default scope
B. All shared access signatures (SAS) generated based on the original account and still within their validity period stop working immediately
C. The new storage account cannot use CMK if infrastructure encryption is enabled, as the two configurations are mutually exclusive
D. AzCopy recreates blobs with new creation and modification timestamps, which may affect systems dependent on object temporal metadata
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The definitive clue is in the currentVersionedKeyExpirationTimestamp field, which shows the value 2025-03-15T00:00:00Z. Considering that the lab is set in March 2025 and the failure occurred approximately 40 minutes before the check, this date indicates that the key expired recently. When a CMK key expires in Key Vault, Azure Storage loses the ability to decrypt envelope keys, completely blocking read and write operations.
The information about Key Vault firewall allowing trusted Microsoft services is intentionally irrelevant: this detail describes a correct configuration that has no relation to the symptom. The purpose of including it is to induce the reader to investigate connectivity when the problem is in the key lifecycle.
ZRS redundancy has no interaction with CMK and does not cause access blocking. Soft-delete also does not interfere with active key accessibility; it protects against accidental deletion, not expiration.
The most dangerous distractor is A: the administrator could spend time investigating Key Vault firewall rules while the real problem, the expired key, remains uncorrected, prolonging production impact.
Answer Key — Scenario 2
Answer: C
The critical restriction of the scenario is explicit: the security team is in active audit and has formally requested that no new permissions be assigned without approval. This restriction cannot be bypassed even in the face of a P1, as doing so would create an additional security risk during a time of compromised permission review.
The correct action is to immediately initiate the formal approval process, accurately documenting the role to be restored (Key Vault Crypto Service Encryption User) and the affected managed identity, so that the security team can approve quickly within the 2-hour SLA.
Alternative A is technically correct regarding the role, but violates the process restriction established by the security team. Alternative B seems pragmatic, but changing the encryption configuration of a production account from CMK to MMK is a high-risk operation that can cause an inaccessibility window during transition and would also require approval in an environment with formal controls. Alternative D bypasses the restriction even more severely, creating a new identity with unaudited permissions.
The most dangerous distractor is A: an administrator under P1 pressure could justify direct assignment as an incident response, but this directly contradicts the established restriction and potentially aggravates the audit situation.
Answer Key — Scenario 3
Answer: D
The raw-data container is correctly configured: defaultScope points to scope-raw and verification confirms that the scope exists and is enabled. The problem is in preventOverride: false. With this configuration, any client, including the SDK, can override the scope defined in the container during upload.
The observed behavior, blobs being written with scope-account-default instead of scope-raw, is consistent with the SDK omitting the explicit scope and Azure applying the account's default scope instead of the container's scope, because preventOverride is not applying the necessary restriction.
The defaultToOAuthAuthentication is the irrelevant information inserted intentionally. It controls the default authentication method for anonymous requests via portal and tools, but does not interfere with encryption scope application logic.
Blob versioning is also irrelevant to encryption scope behavior.
The most dangerous distractor is B: the reader could interpret preventOverride: false as the cause correctly, but attribute the override to the SDK acting on its own instead of understanding that the SDK is explicitly specifying the account's default scope, which takes precedence when preventOverride does not block the substitution.
Answer Key — Scenario 4
Answer: B
When a storage account is recreated with a new name or new instance, all shared access signatures (SAS) that were generated based on the original account are invalidated immediately, even if they are still within their configured validity period. SAS tokens are derived from account keys or from a user delegation key linked to the specific identity and account. When the account is recreated, these links are broken.
Alternative A is incorrect: AzCopy transfers data with encryption scopes defined at the destination. The new account's scopes are applied correctly as configured.
Alternative C is false: infrastructure encryption and CMK are compatible and frequently used together to meet more stringent compliance requirements.
Alternative D describes a real AzCopy behavior regarding timestamps, but the impact is generally accepted in migrations and does not constitute a critical security or availability consequence comparable to SAS invalidation.
The most important point of this scenario is that storage account recreation is not a transparent operation for account consumers: any SAS in circulation, temporary access links, or integrations based on the original account's identity need to be reassessed before migration.
Troubleshooting Tree: Configure storage account encryption
Color legend:
| Color | Node type |
|---|---|
| Dark blue | Initial symptom (root) |
| Blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
To use this tree when facing a real problem, start from the root node by identifying whether the symptom is complete inaccessibility or incorrect encryption scope. Follow the diagnostic questions by answering yes or no based on what is directly observable: key state in Key Vault, managed identity permissions, container configuration. Each path leads to a named cause with the corresponding action, avoiding parallel investigations that consume time without criteria.