AZ-204 Develop for Azure storage Practice Question
Which THREE of the following are true about Azure Blob Storage lifecycle management?
⚠ Common exam trap
It's easy for candidates to think lifecycle policies can be applied at the container level (Option A) because they often use container-scoped filters, but the policy definition itself is always at the storage account level.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
It can automatically move blobs to the Cool tier after a specified number of days.
Option B is correct because lifecycle management policies support tiering rules that transition blobs from Hot to Cool (or Cool to Archive) based on a daysAfterModificationGreaterThan or daysAfterCreationGreaterThan condition. Option C is correct because lifecycle management is supported on general-purpose v2 and Blob Storage accounts (and premium block blob accounts), but not on general-purpose v1 or classic accounts. Option D is correct because lifecycle rules include a delete action that can remove blob snapshots (and versions) after a specified number of days, using baseBlob, snapshot, and version rule filters. Option A is not correct because lifecycle management policies are defined at the storage account level (scoped via rule filters such as prefix or blob index tags), not at the container level. Option E is not correct because replication type (LRS, ZRS, GRS, RA-GRS) is a storage account redundancy setting changed via account configuration, not an action available in lifecycle management policies.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
It can be defined at the container level.
Why it's wrong here
Azure Blob Storage lifecycle management policies are configured at the storage account level, not granularly per container. This design ensures consistent application of rules across all blobs within the account, simplifying administration for large-scale data management. While rules can specify blob prefixes to target specific subsets of data, the policy itself is a storage account resource and applies its rules across the entire account's blob containers.
- ✓
It can automatically move blobs to the Cool tier after a specified number of days.
Why this is correct
Azure Blob Storage lifecycle management policies are specifically designed to automate the movement of blobs between different access tiers. A common rule dictates that blobs can be automatically transitioned from the Hot tier to the Cool tier after a user-defined number of days since their last modification or creation. This capability is crucial for optimizing storage costs by moving less frequently accessed data to more economical tiers.
- ✓
It can be applied to general-purpose v2 and Blob Storage accounts.
Why this is correct
Azure Blob Storage lifecycle management is a feature exclusively supported on General-purpose v2 (GPv2) and Blob Storage accounts. These account types offer the necessary flexibility and tiering capabilities required for effective lifecycle management, unlike older General-purpose v1 accounts or premium storage accounts. This ensures that users can leverage advanced cost optimization features for their most common and cost-sensitive blob storage workloads.
- ✓
It can delete blob snapshots after a specified number of days.
Why this is correct
Lifecycle management policies provide granular control over the retention and deletion of various blob components, including snapshots. It can be configured to automatically delete blob snapshots after a specified number of days from their creation, ensuring that stale or unnecessary recovery points are removed. This automation helps manage storage consumption and compliance requirements by preventing indefinite retention of historical data.
- ✗
It can change the replication type of the storage account.
Why it's wrong here
Azure Blob Storage lifecycle management policies are focused on managing the lifecycle of blob data itself, including tiering, archiving, and deletion. However, they do not possess the functionality to alter fundamental storage account properties such as the replication type (e.g., LRS, GRS, RA-GRS). Changing the replication strategy is a separate, account-level operation that impacts data durability and availability, distinct from data lifecycle management.
Quick reference
Azure Blob Storage Tier Comparison
| Tier | Storage Cost | Retrieval Cost | Latency | Use Case |
|---|---|---|---|---|
| Hot | Highest | Lowest | Immediate | Active data, frequent reads |
| Cool | Lower | Higher | Immediate | Data accessed < once / month |
| Cold | Lower still | Higher | Immediate | Data accessed < once / quarter |
| Archive | Lowest | Highest + rehydration delay | Hours | Long-term compliance retention |
Go deeper
Related to this question
About these practice questions
Courseiva writes every AZ-204 question from scratch — 883 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-204 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-204 exam.