AZ-305 Design data storage solutions Practice Question
A company stores log data in Azure Blob Storage. The logs are accessed frequently for the first 30 days, then only occasionally for up to 1 year, and after that must be retained for 7 years for compliance purposes. The company wants to minimize storage costs by automatically moving data to cheaper tiers. Which Azure Blob Storage lifecycle management policy should they implement?
⚠ Common exam trap
Many candidates choose Option B thinking '7 years' is acceptable in the policy, but Azure requires the 'delete after' action to be specified in days (2555), not years, and they may overlook the early deletion penalty of the Archive tier when moving data too soon.
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
✓
Move to Cool tier after 30 days, move to Archive tier after 365 days, delete after 2555 days
It aligns with the access patterns: move to Cool tier after 30 days (frequent access period), move to Archive tier after 365 days (occasional access period ends), and delete after 2555 days (7 years retention). This minimizes costs by transitioning data to progressively cheaper storage tiers and automatically deleting it when compliance retention expires.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Move to Cool tier after 30 days, move to Archive tier after 365 days, delete after 2555 days
Why this is correct
This policy correctly matches the log usage lifecycle: for the first 30 days data remains Hot for frequent queries; from day 30 to day 365 it is moved to Cool because access becomes occasional but still needed; after 365 days it is moved to Archive for long-term compliance while deletion occurs after 2555 days (exactly 7 years). That transition sequence minimizes cost: Hot for active use, Cool for sporadic retrieval with no rehydration fee, and Archive for rarely accessed records, with deletion eliminating any further storage charges. The rule uses numeric day values as Azure requires.
- ✗
Move to Cool tier after 30 days, move to Archive tier after 365 days, delete after 7 years
Why it's wrong here
The flaw is not the tier transitions but the deletion expression: '7 years' is not a valid Azure lifecycle numeric value. Azure lifecycle management rules only accept integers for 'days after creation' or 'days after last modification', so the policy would be rejected at validation time. Using '2555 days' is the correct equivalent for 7 years and removes ambiguity around leap-year intervals; therefore this option fails because the rule cannot be executed as written.
- ✗
Move to Cool tier after 30 days, move to Archive tier after 30 days, delete after 2555 days
Why it's wrong here
Moving to Archive after only 30 days violates the intended access pattern: for the first year logs are accessed occasionally, and Cool tier is designed for that exactly—it offers lower storage cost than Hot while still allowing near-real-time reads. Archive, by contrast, requires rehydration and can add minutes to hours of latency before access. If you transition to Archive at day 30, you'll incur unnecessary retrieval and rehydration costs for every one of the occasional accesses during the remaining 335 days, which is more expensive than leaving the data in Cool.
- ✗
Move to Archive tier after 30 days, keep in Archive until deletion after 2555 days
Why it's wrong here
Skipping Cool and placing logs into Archive at day 30 means the most frequently used period (the first 30 days) remains Hot, but from day 31 through day 365, when logs are still occasionally queried, you're hit with Archive's rehydration latency and per-GB retrieval charges. Also, once a blob is in Archive it cannot be read directly; you must 'rehydrate' it, adding operational complexity and cost for each access. The correct sequence is Hot→Cool→Archive, so this option misplaces the first-year data and penalizes normal operational workflows.
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
This AZ-305 question is part of Courseiva's 212-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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-305 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-305 exam.