Troubleshooting Lab: Configure Storage Tiers
Diagnostic Scenarios
Scenario 1 — Root Cause
An operations team configured a lifecycle rule to automatically move blobs to the Archive tier after 90 days without modification. The storage account is of type StorageV2 with LRS redundancy, created six months ago. The rule was created three weeks ago and appears with Succeeded status in the Azure portal.
The team reports that blobs older than 90 days remain in the Hot tier and were not moved. The infrastructure team has already confirmed that there are no network or firewall blocks affecting the storage account. The subscription has no resource blocking policies applied.
Inspection of one of the affected blobs returns:
az storage blob show \
--account-name stgprodlogs \
--container-name auditlogs \
--name app-log-2025-10-01.gz \
--query "{tier:properties.blobTier, lastModified:properties.lastModified, accessTier:properties.accessTier}"
{
"tier": "Hot",
"lastModified": "2025-10-03T14:22:10+00:00",
"accessTier": "Hot"
}
The current date is March 26, 2026. The lifecycle rule is configured as follows:
{
"rules": [
{
"name": "archiveAfter90Days",
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": ["blockBlob"],
"prefixMatch": ["auditlogs/archive/"]
},
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 90
}
}
}
}
}
]
}
What is the root cause of the problem?
A) The storage account uses LRS redundancy, which doesn't support lifecycle rules with Archive tier
B) The prefixMatch filter requires blobs to be in the auditlogs/archive/ path, but the blobs are in the auditlogs container without this additional prefix
C) The rule was created only three weeks ago and the lifecycle mechanism hasn't processed the first complete 90-day cycle yet
D) The daysAfterModificationGreaterThan field considers the blob creation date, not the last modification date, and the blobs were modified recently
Scenario 2 — Action Decision
A company's financial reporting system accesses a set of blobs in Azure Blob Storage daily. This morning, the system began returning the following error for all blobs in the financial-reports container:
BlobAccessTierNotSupported: The operation is not supported for this access tier.
The team checks the tier of the affected blobs:
az storage blob list \
--account-name stgfinancial \
--container-name financial-reports \
--query "[].{name:name, tier:properties.accessTier}" \
--output table
Name Tier
-------------------------- -------
report-2026-01.xlsx Archive
report-2026-02.xlsx Archive
report-2026-03.xlsx Archive
report-2026-q1-summary.pdf Hot
The storage account is StorageV2. The team confirms that a lifecycle rule was accidentally activated last night, moving the blobs to Archive. The report-2026-q1-summary.pdf file wasn't affected because it was created today. The company doesn't have local copies of the files. The reporting system needs to be operational within 4 hours maximum.
What is the correct action to take at this moment?
A) Delete the blobs in Archive and reload the original files from backup, as rehydration may take more than 4 hours at Standard priority
B) Start blob rehydration with High priority, which for blobs of this type is usually completed in less than 1 hour, respecting the time constraint and absence of local copies
C) Use Copy Blob to copy the blobs directly from Archive to a new container in Hot tier, allowing immediate access without waiting for rehydration
D) Modify the lifecycle rule to exclude the financial-reports container and wait for the next processing cycle to automatically revert the tier
Scenario 3 — Root Cause
An administrator receives a complaint from the development team: an automation script that lists and reads blobs from a container is failing intermittently. About 30% of calls return data normally; the remaining 70% return the following error:
The blob is currently in the Archive tier and cannot be read directly.
Please rehydrate the blob before attempting to access its content.
The administrator inspects the storage account and confirms:
- Account type: StorageV2 General Purpose v2
- Replication: GRS
- All blobs in the container are over 180 days without modification
- The container has versioning enabled
- Immutability policy is disabled
- No lifecycle rules are currently configured on the account
The script uses the following access pattern:
blobs = container_client.list_blobs()
for blob in blobs:
data = container_client.download_blob(blob.name).readall()
What is the root cause of the intermittent errors?
A) GRS replication interferes with blob reading when the secondary endpoint is being synchronized, causing intermittent access failures
B) Versioning enabled on the container automatically generates versions in Archive tier after 180 days, and the script accesses old versions in Archive instead of the current version
C) Some blobs were moved to Archive manually at some previous point, and the script tries to read all listed blobs without checking the tier before access
D) The StorageV2 account type with GRS limits simultaneous read operations, causing intermittent errors when multiple blobs are accessed in sequence
Scenario 4 — Side Impact
An administrator identifies that a large number of blobs in a container were moved to the Cold tier by a lifecycle rule configured 45 days ago. After review, the team decides these blobs need to be deleted immediately to free up space and reduce costs.
The administrator executes the following command to delete all blobs from the container:
az storage blob delete-batch \
--account-name stgarchivedata \
--source cold-data \
--pattern "*"
The command executes successfully and all blobs are removed. Storage costs drop as expected.
What secondary consequence can this action cause?
A) Deleting blobs in Cold tier before completing the 90-day minimum retention generates a proportional charge for the remaining days of the minimum period, unexpectedly increasing the bill
B) Blobs deleted in Cold tier are automatically moved to Archive tier as a protection measure, remaining billable for another 180 days
C) The delete-batch operation on Cold blobs automatically disables the lifecycle rule associated with the container, requiring manual reconfiguration
D) Batch deletion of Cold blobs triggers a security alert in Microsoft Defender for Storage, blocking write operations on the account for 24 hours
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The rule's prefixMatch filter is configured as auditlogs/archive/. In Azure Blob Storage, prefixMatch matches the container name followed by the blob name prefix. This means the rule only applies to blobs whose name starts with archive/ within the auditlogs container. The affected blobs, like app-log-2025-10-01.gz, are in the container root without this prefix, so the rule never selects them.
The confirming clue is in the az storage blob show output: the blob was modified in October 2025, more than 90 days ago, but remains in Hot. If the issue were processing time or creation date, at least some blobs would have been moved already.
The irrelevant information in this scenario is the absence of network blocks and resource blocking policies. These factors have no relation to the lifecycle mechanism, which operates internally in the Azure Storage control plane.
The most dangerous distractor is C: believing the rule hasn't processed the complete cycle leads the administrator to wait indefinitely without investigating the actual configuration. Distractor D is a relevant technical misconception, as the daysAfterModificationGreaterThan field uses exactly the last modification date, but the data shows modification occurred over 170 days ago, eliminating this hypothesis.
Answer Key — Scenario 2
Answer: B
The critical constraint of the scenario is the 4-hour window without local copies available. This eliminates alternative A, which presupposes backup existence. Alternative C represents a common technical error: Copy Blob from a blob in Archive doesn't read the source blob content; the blob is still offline and the operation doesn't produce a functional copy with data. Alternative D is unfeasible because lifecycle doesn't operate in reverse; once in Archive, the blob only returns to an online tier through explicit rehydration.
Rehydration with High priority is the only action that simultaneously respects the absence of local copies and the available time window. For blobs of typical report size in XLSX and PDF format, rehydration with High priority usually completes in less than 1 hour.
The most dangerous distractor is C, as it seems technically elegant and fast, but fails silently: the copy will be created, the administrator will believe the problem is solved, and the reporting system will continue with errors when trying to read the copied files.
Answer Key — Scenario 3
Answer: C
The central point is the word "intermittent": 30% of accesses work and 70% fail. This rules out any cause that would affect all blobs equally. If it were a GRS replication problem or simultaneous read limitation, the behavior would be generalized or random without correlation to blob content.
The confirmation is in the combination of two facts: no lifecycle rule is currently active, but blobs over 180 days old are present. This indicates that a previous rule moved them to Archive before being removed or that they were moved manually. The script lists all blobs without filtering by tier and tries to read each one, resulting in success for blobs in Hot and failure for those in Archive.
The irrelevant information is the disabled immutability policy. Immutability affects deletion and modification, not reading, and has no relation to the described problem.
Distractor B is sophisticated and deserves attention: enabled versioning doesn't automatically move versions to Archive. This behavior would only occur if a lifecycle rule were explicitly configured for versions, which the statement confirms doesn't exist.
Answer Key — Scenario 4
Answer: A
The Cold tier applies a 90-day minimum retention. Blobs deleted before completing this period generate a proportional charge for the remaining days, as if they had remained stored until the end of the minimum period. Since the rule was configured 45 days ago and blobs were moved during this period, all have less than 90 days in Cold tier. Immediate deletion will generate charges for the remaining 45 days for each deleted blob, potentially resulting in a significantly higher bill than expected.
The other distractors describe behaviors that don't exist in the platform: deleted blobs aren't moved to Archive as protection, the delete-batch operation doesn't disable lifecycle rules, and Microsoft Defender for Storage doesn't block write operations as an automatic response to batch deletions of specific tiers.
The real consequence of ignoring this impact is financial and immediate: the team expecting to reduce costs will discover in the next bill that early deletion generated unexpected charges for the unfulfilled minimum retention period.
Troubleshooting Tree: Configure Storage Tiers
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 intermediate verification |
To use this tree when facing a real problem, start with the root node describing the observed symptom and answer each diagnostic question based on what you can directly verify in the storage account. Each branch eliminates hypotheses and narrows the path to the cause. When reaching a red node, you've identified the cause; when reaching a green node, you have the action to execute. If a path leads to an orange validation node, check the current state before advancing to the next decision.