Blob Lifecycle Management Policies allow you to automate the transition of blob data to cooler storage tiers or expire data based on age and access patterns. This chapter covers the policy definition, rule structure, supported actions, conditions, and execution behavior. On the AZ-104 exam, this topic appears in about 5-8% of questions, often integrated with storage account configuration and cost optimization scenarios. Understanding lifecycle management is crucial for designing cost-effective storage solutions and is tested through scenario-based questions where you must select the correct policy rule to meet a given requirement.
Jump to a section
Imagine a library with millions of books. New books arrive daily and are placed on the 'New Arrivals' shelf. After 30 days, a librarian moves books that haven't been borrowed to the 'General Collection' shelves. After 365 days, books are moved to the 'Archives' basement. After 3 years, books that are never read are sent to the 'Recycling Center' (deleted). The librarian uses a rulebook: if a book is older than X days and hasn't been accessed in Y days, move it. This mirrors Azure Blob Lifecycle Management: you define rules based on age and last modification time. The librarian doesn't move books individually but processes them in batches nightly. Similarly, Azure runs lifecycle management policies once per day, checking all blobs against your rules. The key is that the librarian never moves a book that is currently checked out (leased blob). Also, the policy can't move books from a special 'Restricted' section (immutable storage). The librarian's actions are logged, so you can see what was moved or deleted. This analogy captures the mechanistic process: time-based triggers, bulk execution, exclusion conditions, and logging.
What Is Blob Lifecycle Management?
Blob Lifecycle Management is an Azure Storage feature that enables you to define rules to automatically move blobs to cooler storage tiers (Hot, Cool, Cold, Archive) or delete them based on age and last access time. It is a cost optimization tool that reduces storage costs by transitioning infrequently accessed data to cheaper tiers and removing stale data. The policy is defined as a JSON document and applied at the storage account level, affecting all blobs in the account unless scoped via filters.
How It Works Internally
Azure Storage runs the lifecycle management process once per day, typically between midnight and 6 AM UTC. It scans all blobs in the storage account and evaluates each blob against the defined rules. For each rule, it checks if the blob meets the filter conditions (prefix match, blob index match) and then checks the time-based conditions (age since creation, last modification, last access). If conditions are met, the specified action is queued. Actions are executed in the order defined in the policy. The process is asynchronous and may take up to 24 hours to complete after the policy is updated. There is no guarantee of exact execution time; the service aims to complete within 24 hours.
Key Components of a Lifecycle Management Policy
A policy is a JSON collection of rules. Each rule has:
- Name: A unique identifier within the policy.
- Type: Always "Lifecycle" for lifecycle management.
- Definition: Contains a filters object and an actions object.
- Filters: Specify which blobs the rule applies to. Options:
- blobTypes: Array of blob types, e.g., ["blockBlob"]. Only block blobs are supported. Append blobs and page blobs are not eligible.
- prefixMatch: Array of prefix strings to match blob names. E.g., ["logs/", "temp/"]. If not specified, rule applies to all blobs.
- blobIndexMatch: Array of key-value pairs for blob index tags. E.g., [{"name": "category", "op": "==", "value": "archive"}]. This allows fine-grained targeting.
- Actions: Define what happens when conditions are met. Actions can be base blob actions or snapshot actions. Base blob actions:
- tierToCool: Move to Cool tier. Condition: daysAfterModificationGreaterThan or daysAfterCreationGreaterThan or daysAfterLastAccessTimeGreaterThan.
- tierToCold: Move to Cold tier (preview, but exam relevant). Same condition types.
- tierToArchive: Move to Archive tier. Same condition types.
- delete: Delete the blob. Same condition types.
Snapshot actions:
- tierToCool, tierToCold, tierToArchive, delete – but conditions use daysAfterCreationGreaterThan (snapshots have creation time).
- Time Conditions:
- daysAfterModificationGreaterThan: Days since last write (PUT, PATCH, or metadata update). Read operations do not reset this.
- daysAfterCreationGreaterThan: Days since blob creation.
- daysAfterLastAccessTimeGreaterThan: Days since last read or write (requires enabling last access time tracking at storage account level).
- Note: You must specify at least one time condition. Multiple can be combined with AND logic (all must be true).
Default Values and Limits
Policy evaluation runs once per day.
Maximum number of rules per policy: 100.
Maximum number of prefixes per rule: 10.
Maximum number of blob index match conditions per rule: 10.
Storage account must have hierarchical namespace disabled for lifecycle management to work (Azure Data Lake Storage Gen2 not supported).
Blob versioning: Lifecycle management can manage previous versions if you specify version actions in the policy (similar to snapshot actions).
Immutable blobs (with legal hold or time-based retention) cannot be deleted or tiered by lifecycle management.
Blobs with an active lease (unbroken) are skipped.
Configuration and Verification
You can configure lifecycle management via Azure Portal, Azure CLI, PowerShell, or ARM templates.
Azure CLI example:
az storage account management-policy create \
--account-name mystorageaccount \
--resource-group myResourceGroup \
--policy @policy.jsonSample policy.json:
{
"rules": [
{
"name": "moveToCoolAfter30Days",
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": ["blockBlob"],
"prefixMatch": ["logs/"]
},
"actions": {
"baseBlob": {
"tierToCool": {
"daysAfterModificationGreaterThan": 30
}
}
}
}
},
{
"name": "deleteAfter365Days",
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": ["blockBlob"]
},
"actions": {
"baseBlob": {
"delete": {
"daysAfterModificationGreaterThan": 365
}
}
}
}
}
]
}Verification:
- Use az storage account management-policy show to view the current policy.
- Use az storage blob show to check a blob's access tier and last modification time.
- Monitor lifecycle management logs via Azure Monitor diagnostic settings (StorageRead, StorageWrite, StorageDelete categories).
Interaction with Related Technologies
Blob Versioning: If enabled, lifecycle management can target previous versions using version actions. Example:
"actions": {
"version": {
"delete": {
"daysAfterCreationGreaterThan": 90
}
}
}Blob Snapshots: Separate actions block for snapshots.
Last Access Time Tracking: Must be enabled per storage account via az storage account update --enable-last-access-time true. This adds a property lastAccessTime that is updated on read and write. Lifecycle management can use daysAfterLastAccessTimeGreaterThan.
Immutable Storage: Policies cannot delete or tier blobs with legal hold or time-based retention. The rule is skipped.
Soft Delete: If soft delete is enabled, lifecycle management can still delete blobs; they go to soft-deleted state. You can also use lifecycle management to delete soft-deleted blobs by targeting the softDeleted blob type? Actually, lifecycle management does not directly manage soft-deleted blobs. Soft-deleted blobs have their own retention policy. Lifecycle management only acts on active blobs.
Execution Order and Idempotency
Rules are evaluated in order, but actions are applied independently. If multiple rules match a blob, all applicable actions are attempted. However, if a blob is already in a cooler tier, a tier-to-cool action is ignored (no error). Similarly, if a blob is already deleted, delete action does nothing. The policy is idempotent.
Limitations and Exam Traps
Lifecycle management does not support append blobs or page blobs.
Does not work with Azure Data Lake Storage Gen2 (hierarchical namespace).
Does not work on blobs in the Archive tier if you attempt to tier to Cool/Cold (must rehydrate first).
Cannot move blobs from Archive to Cool directly; you must rehydrate to Hot first (via copy or tier change).
The daysAfterLastAccessTimeGreaterThan condition requires enabling last access time tracking, which incurs extra cost.
Policy changes take up to 24 hours to fully apply.
The exam often tests the difference between daysAfterModificationGreaterThan and daysAfterCreationGreaterThan. Modification is updated on writes; creation is fixed.
A common scenario: You need to delete blobs that haven't been modified in 90 days. Use daysAfterModificationGreaterThan. If you use daysAfterCreationGreaterThan, you might delete blobs that were recently modified but created long ago.
Summary of Supported Actions and Conditions
| Action | Condition Type | Supported Tiers | |--------|----------------|-----------------| | tierToCool | daysAfterModificationGreaterThan, daysAfterCreationGreaterThan, daysAfterLastAccessTimeGreaterThan | From Hot to Cool | | tierToCold | same | From Hot/Cool to Cold | | tierToArchive | same | From Hot/Cool/Cold to Archive | | delete | same | Deletes blob |
Note: Cold tier is in preview but exam may include it.
Enable Last Access Time Tracking
If you plan to use the `daysAfterLastAccessTimeGreaterThan` condition, you must enable last access time tracking on the storage account. This is done via Azure CLI: `az storage account update --name <account> --resource-group <rg> --enable-last-access-time true`. Once enabled, Azure Storage updates the `lastAccessTime` property on each blob whenever it is read or written. This tracking incurs additional cost (per million access operations) and adds a small latency to read operations. Without this, the condition cannot be used. The exam may test that this must be explicitly enabled.
Define the Policy JSON
Create a JSON file with one or more rules. Each rule must have a unique name, type 'Lifecycle', and a definition containing filters and actions. Filters specify which blobs to target using blobTypes (only blockBlob), prefixMatch (up to 10 prefixes), and blobIndexMatch (up to 10 tag conditions). Actions specify what to do: tierToCool, tierToCold, tierToArchive, or delete. Each action requires a time condition: daysAfterModificationGreaterThan, daysAfterCreationGreaterThan, or daysAfterLastAccessTimeGreaterThan. You can combine multiple time conditions, all must be met (AND logic).
Apply the Policy to Storage Account
Use Azure CLI, PowerShell, or Portal to assign the policy. For CLI: `az storage account management-policy create --account-name <account> --resource-group <rg> --policy @policy.json`. The policy is stored as a resource on the storage account. Once applied, Azure Storage begins evaluating blobs according to the rules. The evaluation runs daily, typically between midnight and 6 AM UTC. Changes to the policy may take up to 24 hours to take full effect.
Policy Evaluation and Execution
The lifecycle management service scans all block blobs in the storage account. For each blob, it checks if the blob matches any rule's filters (prefix, tags). If matched, it evaluates the time conditions. For example, if a rule specifies `daysAfterModificationGreaterThan: 30`, the service compares the current date with the blob's last modification time. If the difference exceeds 30 days, the action is queued. Actions are executed in the order they appear in the policy, but execution is asynchronous. Tier changes and deletions are performed in bulk.
Monitor and Verify Actions
After policy application, you can verify actions by checking blob properties. Use `az storage blob show` to see the access tier and last modification time. For deleted blobs, use soft delete recovery if enabled. Enable diagnostic logging on the storage account to capture lifecycle management events. Look for StorageDelete logs or tier change logs. The exam may ask how to confirm that a policy is working: check blob tier or use Azure Monitor alerts. Note that if a blob is leased or in immutable storage, it is skipped.
Enterprise Scenario 1: Log File Management
A SaaS company generates terabytes of application logs daily, stored in blob containers per service (e.g., logs/serviceA/2024/01/). Logs are frequently accessed for the first 30 days (for debugging), then rarely accessed after 90 days. Compliance requires logs to be retained for 1 year, after which they can be deleted. The lifecycle policy defines:
- Rule 1: Prefix logs/, tier to Cool after 30 days since modification.
- Rule 2: Prefix logs/, tier to Archive after 90 days.
- Rule 3: Prefix logs/, delete after 365 days.
This automates cost optimization without manual intervention. Common issue: if log generation stutters and a blob is not modified for 30 days but is still being written to (e.g., appends), the policy might move it prematurely. Solution: Use daysAfterLastAccessTimeGreaterThan if reads occur, or ensure log rotation creates new blobs frequently.
Enterprise Scenario 2: Media Content Archival
A media company stores video files in Hot tier for immediate streaming. After 6 months, videos are rarely watched but must be retained for 3 years for licensing. After 3 years, they can be deleted. The policy uses daysAfterCreationGreaterThan because videos are never modified after upload. Rule 1: tier to Cool after 180 days. Rule 2: tier to Archive after 365 days. Rule 3: delete after 1095 days. Performance consideration: Archive retrieval can take up to 15 hours, so policy must ensure no active need for rapid access. Misconfiguration example: using daysAfterModificationGreaterThan on immutable media files would never trigger since they are never modified, leading to higher costs.
Enterprise Scenario 3: Backup Retention
An enterprise uses Azure Backup for VM backups stored as blobs. Backups are created daily and retained for 7 days in Cool tier, then moved to Archive for 30 days, then deleted. The policy uses daysAfterCreationGreaterThan because each backup blob is created once. Rule 1: tier to Cool after 1 day (backups are initially Hot? Actually, Azure Backup may store directly in Cool; but assume Hot). Rule 2: tier to Archive after 7 days. Rule 3: delete after 37 days. Challenge: Backup blobs may have leases; lifecycle management skips leased blobs. Ensure backups are not leased or use a separate lifecycle policy for backup vaults? Actually, Azure Backup manages its own lifecycle; this scenario is for custom backup solutions. Misconfiguration: If you set delete too early, you lose backups. Always test with a small subset.
What AZ-104 Tests
AZ-104 objective: 'Configure blob lifecycle management' under 'Manage Azure storage' (2.1). Exam questions are scenario-based: given a cost optimization requirement, select the correct policy rule. You must know:
Supported blob types: only block blobs.
Conditions: daysAfterModificationGreaterThan vs daysAfterCreationGreaterThan vs daysAfterLastAccessTimeGreaterThan.
Actions: tierToCool, tierToCold, tierToArchive, delete.
Filters: prefixMatch, blobIndexMatch.
Execution frequency: once per day, up to 24-hour delay.
Limitations: no support for ADLS Gen2, append blobs, page blobs, immutable blobs, leased blobs.
Common Wrong Answers
Choosing `daysAfterCreationGreaterThan` when modification is relevant: Candidates think creation time is same as modification. Wrong. If blobs are updated frequently, creation-based policy may delete blobs prematurely or retain them too long. The exam uses phrases like 'last modified' to indicate modification condition.
Using `tierToCool` for blobs already in Cool or Archive: The policy ignores if already in a cooler tier, but candidates think it will move to Hot? No, tierToCool only moves from Hot to Cool. It does not move from Archive to Cool.
Applying policy to ADLS Gen2 account: The exam may state 'hierarchical namespace enabled' and ask if lifecycle management works. Answer: No, it is not supported.
Assuming immediate execution: Policy changes take up to 24 hours. Candidates might think it's instant.
Specific Numbers and Values
Maximum rules per policy: 100.
Maximum prefixes per rule: 10.
Maximum blob index match conditions: 10.
Time condition values: any integer number of days.
Last access time tracking must be enabled explicitly.
Cold tier is in preview, but exam may include it.
Edge Cases
Blob with active lease: skipped, not deleted or tiered.
Immutable blob: skipped.
Blob in Archive tier: cannot be tiered to Cool/Cold by lifecycle management; must rehydrate first.
Snapshot and version actions: separate from base blob actions.
Policy with multiple rules matching same blob: all applicable actions are attempted, but only first tier change may succeed if moving sequentially (e.g., tierToCool then tierToArchive on same blob: first moves to Cool, second moves to Archive; both can apply).
How to Eliminate Wrong Answers
Read the scenario carefully: Identify if blobs are modified after creation. If yes, use modification condition. If no, creation condition.
Check storage account type: If it's ADLS Gen2, eliminate lifecycle management.
Check blob type: If not block blob, eliminate.
Check if last access time is mentioned: If so, ensure tracking is enabled.
For cost optimization, prefer cooler tiers over deletion unless retention policy requires deletion.
Remember that policy execution is daily, not real-time.
Lifecycle management only supports block blobs; page and append blobs are not supported.
Policies are evaluated once per day; changes take up to 24 hours to apply.
Three time conditions: daysAfterModificationGreaterThan, daysAfterCreationGreaterThan, daysAfterLastAccessTimeGreaterThan.
Last access time tracking must be explicitly enabled on the storage account.
Actions: tierToCool, tierToCold (preview), tierToArchive, delete.
Cannot move blobs from Archive to warmer tiers via lifecycle management.
Blobs with active leases or immutable storage are skipped.
Maximum 100 rules per policy, 10 prefixes per rule, 10 blob index match conditions per rule.
Does not work with Azure Data Lake Storage Gen2 (hierarchical namespace).
Policy can manage snapshots and previous versions using separate action blocks.
These come up on the exam all the time. Here's how to tell them apart.
daysAfterModificationGreaterThan
Counts days since the blob's last write operation (PUT, PATCH, metadata update).
Read operations do not reset this timer.
Useful for blobs that are frequently updated, e.g., log files that are appended.
If a blob is never modified, this condition may never be met (if no modification).
Exam scenario: 'blobs that have not been modified in 90 days' → use this.
daysAfterCreationGreaterThan
Counts days since the blob was initially created.
Fixed value; does not change with updates.
Useful for blobs that are never modified after upload, e.g., media files or backups.
If a blob is modified, creation time is still the original upload date.
Exam scenario: 'blobs that are older than 90 days' → use this.
Mistake
Lifecycle management can move blobs from Archive to Cool or Hot automatically.
Correct
Lifecycle management can only move blobs to cooler tiers (Hot->Cool, Cool->Cold, Cool/Cold->Archive). It cannot move blobs from Archive to a warmer tier. To access data in Archive, you must manually rehydrate the blob by changing its tier to Hot or Cool, which may take up to 15 hours.
Mistake
Lifecycle management policies apply to all blob types including page blobs and append blobs.
Correct
Only block blobs are supported. Page blobs (used for VHDs) and append blobs (used for logging) are not eligible for lifecycle management. Any policy targeting these blob types will be ignored.
Mistake
The policy executes immediately after being applied.
Correct
Policy evaluation runs once per day, typically between midnight and 6 AM UTC. Changes to the policy can take up to 24 hours to take effect. It is not a real-time process.
Mistake
Using 'daysAfterCreationGreaterThan' is the same as 'daysAfterModificationGreaterThan' for blobs that are never modified.
Correct
For blobs that are never modified, both conditions yield the same result. However, if a blob is modified (e.g., updated metadata), the creation time remains fixed while modification time changes. The exam may test this distinction in scenarios where blobs are updated.
Mistake
Lifecycle management can delete blobs that are under legal hold or have active leases.
Correct
Blobs with a legal hold or time-based retention policy (immutable storage) cannot be deleted or tiered by lifecycle management. Similarly, blobs with an active lease (unbroken) are skipped. The policy will not apply to these blobs until the hold is removed or lease is broken.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. Lifecycle management can only move blobs to cooler tiers (Hot -> Cool -> Cold -> Archive). To move a blob from Archive to a warmer tier, you must manually rehydrate it by changing its tier using Azure CLI, PowerShell, or SDK. Rehydration can take up to 15 hours for standard priority.
Lifecycle management runs once per day, typically between midnight and 6 AM UTC. However, the exact time is not guaranteed. Policy changes may take up to 24 hours to take effect. It is not a real-time process.
No. Lifecycle management is not supported for Azure Data Lake Storage Gen2 accounts (hierarchical namespace enabled). You must use a general-purpose v2 storage account with flat namespace.
Blobs with an active lease (not broken) are skipped by lifecycle management. The policy will not delete or tier them. The blob is evaluated again in subsequent daily runs until the lease is broken.
No. The last access time property is not tracked by default. You must enable it on the storage account using Azure CLI or Portal. Enabling it incurs additional costs and may have a minor performance impact.
Yes. If blob versioning is enabled, you can define separate actions for previous versions using the 'version' block in the policy. The same time conditions apply, but they use daysAfterCreationGreaterThan for versions.
Cold tier is a new tier between Cool and Archive, introduced in preview. It offers lower storage cost than Cool but higher access cost and latency. On the exam, you may see both; Cold is currently in preview but may be tested.
You've just covered Blob Lifecycle Management Policies — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?