Troubleshooting Lab: Configure blob lifecycle management
Diagnostic Scenarios
Scenario 1 — Root Cause
An operations team reports that blobs in the storage account prodlogs001 are not being moved to the Cool tier as expected. The account was created two years ago and is of type General Purpose v2. Blob versioning is disabled. The configured replication is LRS.
The administrator checks the active policy and finds the following:
{
"rules": [
{
"name": "moverParaCool",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": ["blockBlob"],
"prefixMatch": ["logs/"]
},
"actions": {
"baseBlob": {
"tierToCool": {
"daysAfterLastAccessTimeGreaterThan": 30
}
}
}
}
}
]
}
The administrator confirms that blobs in logs/ have more than 30 days without access. The account has 4 TB of data and a total of 12 lifecycle rules configured. The monthly cost increased 18% last month.
What is the root cause of the observed problem?
A) The account has 12 lifecycle rules, exceeding the maximum allowed limit of 10 rules per account, which causes the most recent rules to be ignored.
B) Last access tracking is not enabled on the storage account, therefore the daysAfterLastAccessTimeGreaterThan condition is never satisfied.
C) The Cool tier is not a valid destination for blockBlob type blobs in GPv2 accounts with LRS replication.
D) The prefix logs/ is incorrect; lifecycle policies require the prefix to include the full container name in the format container/prefix.
Scenario 2 — Action Decision
The infrastructure team identified that the lifecycle policy for the archivestore02 account is correctly configured and enabled. The root cause has already been determined: the account is of type General Purpose v1 (GPv1) and tier movement actions are not executed on this account type.
The account is in production, processes approximately 500 write operations per hour and is used by three critical applications that cannot have service interruption. The team has a scheduled maintenance window 48 hours from now. The development team confirmed that the applications are compatible with GPv2 accounts.
What is the correct action to take at this moment?
A) Recreate the account as GPv2, update connection strings in the three applications and reactivate the lifecycle policy, performing everything immediately to avoid accumulating more cost.
B) Wait for the maintenance window and perform the account upgrade from GPv1 to GPv2 through the Azure portal, without needing to recreate the account or migrate data.
C) Create a new GPv2 account in parallel, configure the lifecycle policy, migrate data using AzCopy and redirect applications during the maintenance window.
D) Enable Archive access tier directly on the GPv1 account via Azure CLI, which allows the lifecycle policy to execute without needing migration.
Scenario 3 — Root Cause
An administrator configures a lifecycle policy to automatically delete blobs after 180 days. After 200 days, when auditing the account, they find blobs that should have been deleted still present. The account is GPv2, the blob type is blockBlob and the rule is enabled.
When investigating, they collect the following information:
Container name: backup-diario
Blob type: blockBlob
Current tier: Archive
Last modification date: 210 days ago
Configured policy:
- delete: daysAfterModificationGreaterThan: 180
- tierToArchive: daysAfterModificationGreaterThan: 90
Replication: GRS
Region: Brazil South
Storage cost: within expected for Archive
The administrator notices that the blobs are in the Archive tier and suspects that GRS replication is interfering with policy execution. Microsoft support confirms there are no incidents in the Brazil South region.
What is the root cause of the blobs not being deleted?
A) GRS replication prevents automatic blob deletion, as the lifecycle policy waits for secondary replica confirmation before executing the action.
B) Blobs in the Archive tier need to be rehydrated to Hot or Cool before a lifecycle policy can execute the deletion action.
C) The tierToArchive rule and the delete rule are configured for the same blob, and when there are conflicting actions in the same policy, only the lower cost action is executed.
D) Blobs in the Archive tier with more than 180 days have their modification clock reset at the moment of tier transition, postponing the deletion criteria.
Scenario 4 — Collateral Impact
An administrator notices that accumulated snapshot blobs are generating high cost. To solve the problem, they add the following action to the existing lifecycle policy of the account:
"snapshot": {
"delete": {
"daysAfterCreationGreaterThan": 7
}
}
The policy is saved and begins executing in the next cycle. The cost problem is resolved. Two days later, the disaster recovery team reports they cannot restore a critical file corrupted 5 days ago from a previous snapshot.
What secondary consequence did this action cause?
A) The snapshot deletion policy automatically disabled the soft delete functionality for snapshots, preventing recovery even within the configured retention period.
B) Snapshots less than 7 days old that existed before policy activation were retroactively deleted in the first execution cycle, eliminating the snapshot created 5 days ago before it completed 7 days.
C) The snapshot deletion rule removed all snapshots older than 7 days, and since the file was corrupted 5 days ago, the only useful snapshot would be one created less than 7 days ago, which should still exist, but was deleted by a conflicting baseBlob rule.
D) By adding the snapshot.delete action, the policy silently replaced the account's soft delete configuration, reducing the soft delete retention period from 14 days to 7 days.
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
Last access tracking is a feature that needs to be explicitly enabled on the storage account before being used as criteria in lifecycle policies. When this tracking is not active, Azure does not record the last access timestamp on blobs, and the daysAfterLastAccessTimeGreaterThan condition is never evaluated as true, since the field remains null or outdated.
The clue in the scenario is the absence of any mention that access tracking is enabled, combined with the choice of access-based condition.
The irrelevant information in this scenario is the 4 TB volume and 18% cost increase: these data contextualize the urgency of the problem, but have no relation to the cause of policy failure.
The distractors represent common diagnostic errors: alternative A confuses number of rules with a non-existent limit (the real limit is 100 rules per policy, not 10); alternative C invents a restriction that doesn't exist between blockBlob and Cool tier in GPv2 with LRS; alternative D confuses the prefix format, which may or may not include the container name depending on scope, but logs/ is valid if blobs are in a container called logs.
The most dangerous distractor is D: an administrator could waste time changing prefixes without solving the real problem.
Answer Key — Scenario 2
Answer: B
Upgrading an account from GPv1 to GPv2 is an operation directly supported by Azure and is irreversible, but not destructive: data remains intact, connection strings don't change, and service is not interrupted. Performing this upgrade during the maintenance window is the correct action because it respects all scenario constraints: no service interruption, no need for data migration, and aligned with the available timeframe.
Alternative A ignores the critical constraint of not interrupting service and unnecessarily rushes an operation that can be done in a controlled manner. Alternative C is technically valid in scenarios where upgrade is not possible, but introduces unnecessary complexity and migration risk when direct upgrade solves the problem. Alternative D describes an operation that doesn't exist: there's no way to enable tier movement in GPv1 via CLI; the account type is the architectural limiter.
Answer Key — Scenario 3
Answer: B
Blobs in the Archive tier are in an offline state. For any operation to be executed on them, including deletion by lifecycle policy, the blob must first be rehydrated to an online tier (Hot or Cool). Lifecycle policy does not execute deletion action on blobs in Archive directly.
The decisive clue in the scenario is that blobs are in the Archive tier and that cost is within expected for Archive: this confirms that tier transition occurred normally, but subsequent deletion was not executed.
The irrelevant information is the administrator's suspicion about GRS replication and confirmation of no incidents in the region: these elements were inserted to divert diagnosis to infrastructure causes when the problem is expected Archive tier behavior.
The most dangerous distractor is A: the idea that GRS replication interferes with policies is intuitively plausible, but incorrect. Acting on this hypothesis would lead the administrator to change account replication without solving the real problem.
Answer Key — Scenario 4
Answer: B
Lifecycle policies are evaluated based on the current state of objects at the time of cycle execution. When a snapshot deletion rule with daysAfterCreationGreaterThan: 7 is activated, the first execution cycle evaluates all existing snapshots based on this criteria. A snapshot created 5 days before rule activation existed for 5 days at activation time, but this doesn't protect it: in the first policy execution after activation, if this snapshot still has less than 7 days, it will be preserved. The real problem is that the rule was applied and the snapshot created 5 days ago was deleted because at the time the cycle executed, it already had more than 7 days (5 days before activation plus 2 days after, totaling 7 days or more).
Alternative A describes behavior that doesn't exist: lifecycle policies don't interact with soft delete configuration. Alternative C introduces a rule conflict that wasn't configured in the scenario. Alternative D describes a silent replacement that also doesn't occur: soft delete and lifecycle management are independent configurations.
The central learning from this scenario is that when activating a deletion policy, all existing objects become immediately eligible based on time criteria, not just those created after rule activation.
Troubleshooting Tree: Configure blob lifecycle management
Color Legend:
- Dark blue: initial symptom, investigation entry point
- Medium blue: diagnostic question, decision point
- Red: identified cause
- Green: recommended action or resolution
- Orange: intermediate validation or verification
To use this tree when facing a real problem, start with the root node describing the observed symptom and answer each decision question based on what you can directly verify in the storage account or policy configuration. Follow the path corresponding to each answer until you reach an identified cause or recommended action node. Don't skip levels: each question filters a hypothesis and reduces the space of possible causes before you act.