Troubleshooting Lab: Configure blob versioning
Diagnostic Scenarios
Scenario 1 — Root Cause
An operations team maintains a StorageV2 storage account in the East US region. Blob versioning is listed as enabled in the Azure portal. The account has a container called documentos with private access, and blobs are written by an application via .NET SDK.
After an incorrect update to a critical file called relatorio-mensal.xlsx, the team tries to list previous versions of the blob to recover the original content. The following command is executed:
az storage blob list \
--account-name storageops01 \
--container-name documentos \
--include v \
--output table
The output returns only the current version of the blob, with no previous versions listed. The team confirms that the file was overwritten about 20 minutes ago. The storage account uses the Hot access tier and has lifecycle management configured with the following active rule:
{
"rules": [
{
"name": "move-to-cool",
"enabled": true,
"definition": {
"filters": { "blobTypes": ["blockBlob"] },
"actions": {
"baseBlob": {
"tierToCool": { "daysAfterModificationGreaterThan": 30 }
}
}
}
}
]
}
What is the root cause of the absence of previous versions in the listing?
A) The lifecycle management rule deleted the previous version when moving the blob to the Cool tier right after the overwrite.
B) Versioning was enabled after the overwrite had occurred, therefore no previous version was recorded for that event.
C) The --include v parameter is not sufficient to list versions; it's also necessary to specify --prefix with the exact blob name.
D) The write operation via .NET SDK used a call that doesn't trigger the versioning mechanism, such as Put Block without Put Block List.
Scenario 2 — Action Decision
The cause of the problem was identified: blob versioning was disabled at the time the file was overwritten. An administrator has just successfully enabled versioning. The documentos container stores approximately 4,000 active blobs, all in production and continuously accessed by a critical application. No maintenance window is available for the next 8 hours.
The administrator needs to ensure that existing blobs will have versions recorded from now on, without interrupting application access and without unnecessarily duplicating data.
What is the correct action to take at this moment?
A) Copy all blobs from the documentos container to a new container with the same name in another storage account that already had versioning enabled before, and redirect the application to the new account.
B) No additional action is necessary: with versioning now enabled, any future write operation on existing blobs will automatically create the first previous version from that point forward.
C) Execute a script that performs a copy operation of each blob onto itself (Copy Blob with identical source and destination) to force immediate registration of a baseline version for all 4,000 blobs.
D) Disable and re-enable versioning twice in succession to force the service to reindex existing blobs and create initial versions for each one.
Scenario 3 — Root Cause
A data engineer reports that they can list versions of a specific blob called pipeline-config.json, but when trying to download a previous version for validation, they receive the following error:
BlobAccessTierNotSupported: The operation is not supported for this version of the blob.
The environment has the following characteristics:
- StorageV2 account with hierarchical namespace disabled
- Versioning enabled 45 days ago
- The version the engineer is trying to access was created 38 days ago
- The account has integration with Microsoft Entra ID for authentication via RBAC, and the engineer has the Storage Blob Data Reader role at the account scope
- A lifecycle management rule moved previous versions older than 30 days to the Archive tier
What is the root cause of the error received?
A) The Storage Blob Data Reader role doesn't have permission to access blob versions, only the base blob.
B) The version was moved to the Archive tier by the lifecycle management rule, and blobs in this tier cannot be read directly without prior rehydration.
C) The disabled hierarchical namespace prevents access to individual blob versions in StorageV2 accounts.
D) Versioning enabled 45 days ago is still in propagation period for blobs created before enablement, and versions older than 30 days are not yet available.
Scenario 4 — Diagnostic Sequence
An operator receives a ticket reporting that old blob versions in a container are accumulating and generating unexpected costs, even with a lifecycle management policy configured to delete previous versions older than 60 days. They need to investigate why versions aren't being deleted as expected.
The available investigation steps are:
- Verify if the rule's
enabledproperty is set totrue - Confirm that the configured action type is
version.deleteand notbaseBlob.delete - List the affected blob's versions and check the creation date of each version
- Verify if versioning is actually enabled on the storage account
- Check the lifecycle policy execution log in Azure Monitor to identify if the rule was evaluated and if there were errors
Which sequence represents the most efficient diagnostic reasoning?
A) 4 → 1 → 2 → 3 → 5
B) 3 → 5 → 4 → 2 → 1
C) 1 → 4 → 2 → 5 → 3
D) 5 → 3 → 1 → 4 → 2
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The decisive clue is in the statement: versioning is listed as enabled in the portal, but no previous version exists for a blob that was overwritten 20 minutes ago. Versioning is prospective by definition: it only starts recording versions from the moment it's enabled. If the blob existed before enablement and was never modified after it, there's no previous version recorded.
The information about the lifecycle management rule (distractor A) is purposely irrelevant: the rule moves blobs to Cool after 30 days, and the event occurred only 20 minutes ago. This rule couldn't have deleted any version in this interval.
Distractor C represents a syntax error that doesn't exist: --include v is the correct parameter to include versions in the listing. Distractor D describes a plausible technical scenario, but Put Block without Put Block List leaves the blob in an uncommitted block state, and the scenario doesn't indicate any anomaly in the write process.
The most dangerous diagnostic error would be distractor A: acting on the lifecycle rule by modifying it wouldn't solve the problem, and the team would waste time investigating an incorrect cause while the recovery window (if there was backup) closes.
Answer Key — Scenario 2
Answer: B
With versioning enabled, the default service behavior ensures that any future write operation on an existing blob will automatically create a previous version with the current content before modification. No additional action is necessary for existing blobs to start having their history tracked from that point forward.
Distractor C (copying each blob onto itself) is technically a valid strategy to create an immediate version baseline, but the statement presents a critical constraint: 4,000 blobs in production with continuous access and no maintenance window. Executing 4,000 copy operations on active blobs introduces risk of concurrency conflicts, additional latency, and unnecessary transaction costs. The operational constraint makes this action incorrect in this specific context.
Distractor A proposes a complete account migration, which directly violates the service continuity constraint. Distractor D describes behavior that doesn't exist: disabling and re-enabling versioning doesn't force any type of reindexing.
Answer Key — Scenario 3
Answer: B
The root cause lies in the combination of two objective facts provided in the statement: the version in question was created 38 days ago, and there's a lifecycle management rule that moves previous versions older than 30 days to the Archive tier. Blobs in the Archive tier are offline and cannot be read directly. Any access attempt returns an error until the blob is rehydrated to Hot or Cool, which can take hours.
The information about authentication via Microsoft Entra ID and the Storage Blob Data Reader role is purposely irrelevant: this role has read permission on blob versions, and the engineer can even list versions without error, which proves that authentication and authorization work correctly.
Distractor A is the most dangerous: it would direct the administrator to review RBAC permissions and open access tickets, while the real problem is storage tier-related and can be solved by initiating a rehydration operation immediately.
Answer Key — Scenario 4
Answer: A
The correct sequence is 4 → 1 → 2 → 3 → 5, which represents a progression from simplest to most specific:
First confirm that versioning is enabled (step 4), because without it no versions exist to be managed by the policy. Next, verify if the rule is active (step 1), since a rule with enabled: false is completely ignored. Then, confirm that the configured action is version.delete and not an action on the base blob (step 2), as this is the most common configuration mistake. With configuration validated, check the actual data from listed versions (step 3) to confirm if dates exceed the rule's threshold. Finally, consult Azure Monitor (step 5) to verify if the rule was evaluated and if there were execution errors, which is the most time-costly step and should only be done when previous ones don't reveal the cause.
Sequence B (distractor) starts with observable data before validating configuration, which can lead to incorrect conclusions. Sequence C reverses logic by checking configuration before confirming the prerequisite (versioning enabled). Sequence D starts with the most advanced diagnostic resource without first validating simpler prerequisites.
Troubleshooting Tree: Configure blob versioning
Color legend:
| Color | Node type |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Validation or confirmed correct state |
To use this tree when facing a real problem, start with the root node describing the general symptom. Answer each diagnostic question based on what you can directly verify in the environment, following the path corresponding to your answer. Each branch progressively eliminates hypotheses until you reach a red node that names the root cause, followed by a green node with the precise corrective action. Never skip questions: the order of branches reflects real dependencies between service prerequisites.