Azure Storage Account Tiers and Lifecycle Policies: An Exam-Critical Walkthrough

Why are storage tiers so heavily tested on Azure exams?

Storage accounts are the most-deployed Azure resource and the foundation of nearly every workload. Both AZ-104 and AZ-204 test access tiers (Hot, Cool, Cold, Archive), redundancy options (LRS, ZRS, GRS, RA-GRS, GZRS), lifecycle management policies, and the cost trade-offs each implies. Exam scenarios use storage decisions as a proxy for understanding cost, durability, latency, and compliance simultaneously -- a single tier-and-redundancy choice answers four questions at once. Microsoft estimates storage decisions drive roughly fifteen percent of AZ-104 content.

---

Azure Storage is the workhorse of the Microsoft cloud. Every backup, every Data Lake, every static website, every container registry, and every diagnostic log eventually lands in a storage account. The choices around tier, redundancy, and lifecycle policies cascade into cost, latency, and compliance outcomes -- which is exactly why they appear so often on certification exams.

This walkthrough covers what AZ-104 and AZ-204 candidates need to know, how to read tier-selection scenarios, and the lifecycle policy patterns that turn into cost-optimization questions on every exam form.

---

The Four Access Tiers in 2026

Azure Blob Storage supports four access tiers. The 2026 refresh added the Cold tier between Cool and Archive.

Tier	Access Pattern	Min Retention	Storage Cost	Read Cost
Hot	Frequent access, low latency	None	Highest	Lowest
Cool	Infrequent, occasional access	30 days	Lower	Higher
Cold	Rare access, still online	90 days	Lower than Cool	Higher than Cool
Archive	Offline, retrieval in hours	180 days	Lowest	Rehydration cost + delay

The cost curve is intentional. Storage cost decreases as retention requirements increase; read cost increases. The exam tests scenarios where candidates must balance these trade-offs.

The Hot/Cool/Cold/Archive Decision Framework

Candidates should treat tier selection as a four-question filter.

1. How often is the data read? -- daily means Hot; monthly means Cool; quarterly means Cold; yearly or compliance-only means Archive.

2. What is the minimum retention? -- early deletion incurs an early-deletion fee. Pulling Cool data after 15 days costs as if it stayed 30.

3. What is the latency tolerance? -- Hot/Cool/Cold are millisecond-latency. Archive requires rehydration (1-15 hours) before it can be read.

4. What is the data size? -- the cost difference between tiers only matters at scale. A few gigabytes of logs do not justify lifecycle policy overhead.

The Heineken global IoT platform, in a publicly described Microsoft case study, stores brewery sensor telemetry in Hot for the first thirty days, transitions to Cool for the next eleven months, and Archive thereafter. AZ-104 lifecycle policy questions follow this pattern almost verbatim.

"Storage tiering is the cheapest cost optimization most customers never implement. The defaults are Hot forever, which is rarely what the workload actually needs." -- Anavi Nahar, Principal Program Manager at Microsoft Azure

---

Redundancy Options and the Geography Question

Azure Storage redundancy is a separate decision from tier. Both exams test the matrix.

• LRS (Locally Redundant Storage) -- three copies in a single data center. Lowest cost, no DR.

• ZRS (Zone-Redundant Storage) -- three copies across availability zones in a single region. Survives a data center failure.

• GRS (Geo-Redundant Storage) -- LRS in primary plus async replica in a paired secondary region. Survives regional failure.

• RA-GRS -- GRS with read-only access to the secondary endpoint.

• GZRS -- ZRS in primary plus async replica in secondary region. The most resilient and most expensive option.

• RA-GZRS -- GZRS with read access to the secondary endpoint.

The exam scenario tests which option meets specific RPO, RTO, and cost requirements. A scenario requiring "data must survive regional failure with read access during DR drills" answers RA-GRS or RA-GZRS. A scenario with "lowest cost, single region acceptable" answers LRS.

The Failover Behavior Trap

Customer-initiated failover is supported on GRS, GZRS, and RA-GRS/RA-GZRS. The exam tests one specific gotcha: after failover, the secondary becomes primary, and the redundancy temporarily drops to LRS until the customer manually configures geo-replication again. Candidates who assume redundancy auto-restores miss the question.

---

Lifecycle Management Policies

Lifecycle management is the feature that automates tier transitions and deletions based on rules. It runs once per day and acts on blobs that match defined conditions.

A lifecycle policy is JSON. It contains rules. Each rule has filters (which blobs it applies to) and actions (what happens to them).

The actions tested on AZ-104 and AZ-204:

1. tierToCool -- transition to Cool tier

2. tierToCold -- transition to Cold tier (added 2024)

3. tierToArchive -- transition to Archive tier

4. enableAutoTierToHotFromCool -- restore to Hot on read

5. delete -- permanent deletion

6. daysAfterLastAccessTimeGreaterThan -- access-based trigger requiring LastAccessTimeTracking enabled

7. daysAfterModificationGreaterThan -- modification-time-based trigger

8. daysAfterCreationGreaterThan -- creation-time-based trigger (for snapshot and version actions)

The exam scenario typically describes a regulatory retention requirement -- "logs must be retained for seven years but accessed rarely after the first month" -- and asks for the lifecycle policy. The correct answer transitions to Cool at 30 days, to Cold at 90, to Archive at 180, and deletes at 2555 days (seven years).

The Last-Access-Time Tracking Detail

Last-access-time tracking is not enabled by default. Without it, lifecycle rules using daysAfterLastAccessTimeGreaterThan evaluate to never. Enabling tracking adds a small per-operation cost. The exam tests this trade-off directly -- candidates must know that access-based policies require explicit opt-in.

---

Storage Account Types

The exam expects candidates to choose the right account kind.

Kind	Use Case	Notes
StorageV2	Default for new accounts	Supports all tiers and features
BlockBlobStorage	High-throughput Premium block blobs	SSD-backed, no Cool/Archive
FileStorage	Premium file shares	SSD-backed
StorageV1	Legacy general-purpose	Avoid for new deployments

StorageV2 is the answer in nearly every greenfield scenario. The exam reserves BlockBlobStorage and FileStorage for explicit performance scenarios.

Premium Versus Standard Performance

Standard uses HDDs with a higher latency floor. Premium uses SSDs with single-digit-millisecond latency. Premium is required for BlockBlobStorage and FileStorage accounts. The exam tests this requirement directly -- a scenario requiring sub-10ms latency on file shares answers Premium FileStorage.

---

Securing Storage Accounts

Storage security is its own subdomain. Both exams test:

• Shared Key authentication -- account keys, the default and least secure option

• SAS tokens -- time-limited, scope-limited delegation

• Microsoft Entra ID authentication -- modern, RBAC-based, the recommended path

• Network restrictions -- firewall rules, service endpoints, private endpoints

• Customer-managed keys -- bring-your-own-key encryption via Key Vault

The most-tested security pattern: disable Shared Key authentication, require Entra ID for data-plane access, and use private endpoints for network-level isolation. ASOS, the UK retailer, publicly described disabling Shared Key on all production storage accounts as part of its 2023 zero-trust hardening project.

The allowBlobPublicAccess Property

Storage accounts created before 2022 default to allowing public blob access. Accounts created after default to deny. The exam tests scenarios where a security audit requires disabling public access tenant-wide -- the answer is Azure Policy that denies storage accounts with allowBlobPublicAccess: true. This pattern aligns with the Microsoft Cloud Security Benchmark.

---

Real-World Patterns

Heineken IoT brewery: telemetry into Hot, transitioned to Cool at 30 days, Archive at one year. Compliance retention seven years. This is the textbook lifecycle pattern AZ-104 borrows.

ASOS analytics: data lake on StorageV2 with hierarchical namespace enabled, Cold tier for historical event data older than 90 days, lifecycle policies driven by container prefix. AZ-204 candidates see this pattern in scenarios involving Data Lake Storage Gen2.

---

What Each Exam Asks

Topic	AZ-104 Depth	AZ-204 Depth
Access tiers	Selection by scenario	Selection plus programmatic transitions
Redundancy	Match RPO/RTO to option	Same plus client SDK behavior on failover
Lifecycle policies	Read JSON, write basic rule	Read JSON, write complex multi-action rule
SAS tokens	Recognize types	Generate via SDK, choose stored access policy
Networking restrictions	Firewall, endpoint setup	Private endpoint plus DNS configuration
Encryption	Default vs CMK trade-offs	CMK key rotation, customer-provided keys

AZ-104 candidates need familiarity; AZ-204 candidates need code-level fluency. The Microsoft AZ-204 Exam Ref by Santiago Fernandez Munoz is the most cited reference for the developer-side details.

---

A Hands-On Practice Sequence

Each step takes under thirty minutes on the Azure free tier.

1. Create a StorageV2 account with LRS redundancy

2. Upload a blob and observe Hot as the default tier

3. Manually transition the blob to Cool, Cold, and Archive; observe rehydration on Archive read

4. Enable last-access-time tracking and create a lifecycle policy that transitions blobs to Cool after 14 days

5. Switch redundancy to GRS and observe replica creation in the paired region

6. Disable Shared Key authentication and confirm that az storage blob list requires Entra ID authentication

7. Add a private endpoint and a custom DNS configuration; verify that public endpoint access is rejected

Each step maps to one or more exam objectives.

---

Common Mistakes That Lose Points

• Confusing redundancy with backup: GRS replicates corruption to the secondary. It is not a backup. AZ-104 tests this by asking how to recover from accidental deletion -- the answer is soft delete and point-in-time restore, not GRS.

• Forgetting early-deletion fees: Cool, Cold, and Archive tiers all charge as if the blob stayed for the minimum retention period. The exam scenario describes a workload that re-uploads quickly and asks why Cool is more expensive than Hot in this case.

• Mismatched container security: a private container with a SAS token still works, but a private container without authentication returns 404 to public requests. The exam tests this distinction.

• Hierarchical namespace lock-in: Data Lake Storage Gen2 is a StorageV2 account with hierarchical namespace enabled. The flag cannot be turned off after creation. Candidates who guess "disable hierarchical namespace" lose the question.

The Microsoft Press AZ-104 Exam Ref by Harshul Patel and the Microsoft Learn "Manage Azure Storage" path together cover every gotcha tested by the 2026 exam.

---

See also: /certifications/azure/az-104-azure-administrator-domains-with-highest-question-density, /certifications/azure/az-204-azure-developer-associate-what-the-exam-actually-tests, /certifications/cybersecurity/data-protection-cloud-storage-fundamentals.

---

SAS Tokens in Detail

Shared Access Signatures generate time-limited, scope-limited tokens for delegated storage access. Three types exist.

1. User delegation SAS -- signed with an Entra ID credential, the recommended modern option

2. Service SAS -- signed with the account key, scoped to a single service (Blob, Queue, Table, File)

3. Account SAS -- signed with the account key, scoped to multiple services on the account

Each SAS includes a start time, expiry, allowed operations, and an optional IP range. The exam scenario tests SAS selection by security posture -- user delegation SAS is the correct answer when the customer wants to avoid issuing account keys to applications. Service SAS combined with a stored access policy is the correct answer when the customer needs to revoke access without rotating keys.

Stored access policies are a server-side resource that a Service SAS references. Revoking a stored access policy invalidates every SAS that referenced it. This pattern is heavily tested on AZ-204 in scenarios involving partner data exchange.

---

Storage Performance Targets

Both exams test performance limits because they drive sizing decisions. AZ-204 tests them at code-level depth.

A standard general-purpose v2 storage account targets up to 20,000 transactions per second and 50 Gbps egress in the primary region. Premium accounts deliver single-digit-millisecond latency with higher transaction ceilings but more expensive per-gigabyte costs. The Microsoft Azure Storage scalability and performance targets documentation page lists the exact numbers and is fair game on both exams.

The exam scenario for performance: a workload exceeds the ingress or transaction limit, manifesting as 503 ServerBusy responses. The candidate must select the correct mitigation -- partition prefix design for blob storage, multiple storage accounts with sharding, or a switch to Premium block blobs. Candidates who default to "increase the SKU" without knowing standard vs Premium distinctions miss the question.

Throttling Patterns Tested on AZ-204

AZ-204 tests retry strategies for throttled storage requests. The Azure SDKs ship with default exponential-backoff retry policies that handle most 503 responses transparently. The exam expects candidates to recognize that custom workloads bypassing the SDK must implement equivalent backoff. Jeffrey Snover, the inventor of PowerShell and a Microsoft Technical Fellow, has written that "the most expensive bug in cloud applications is the one that retries instantly without backoff" -- AZ-204 reflects this directly with a question on the impact of tight-loop retry against a throttled storage account.

---

Encryption and Compliance Detail

Storage encryption-at-rest is on by default and cannot be disabled. The exam tests the key-management option, not whether encryption is enabled.

Microsoft-managed keys (MMK) -- the default. Keys rotate automatically, customer has no key access.

Customer-managed keys (CMK) -- keys live in Azure Key Vault or Managed HSM. The customer controls rotation and revocation. Required for many regulatory frameworks.

Customer-provided keys (CPK) -- keys passed in the request header per operation. Used by data residency and per-blob compliance scenarios.

The exam scenario for CMK typically involves a regulatory mandate -- HIPAA, PCI-DSS, or financial-services frameworks -- where the customer must demonstrate exclusive key control. The correct answer is CMK with Key Vault, automatic key rotation, and an Entra ID managed identity for the storage account to access the vault. CPK appears in scenarios involving extreme data sovereignty requirements.

Mark Russinovich, Chief Technology Officer at Microsoft Azure, has written publicly that CMK adoption is now the default recommendation for any regulated workload, with CPK reserved for scenarios where the customer cannot delegate any key visibility. The exam reflects this guidance.

"Encryption is on. The question on every audit and every certification exam is who holds the key, who can rotate it, and who can revoke it." -- Yuri Diogenes, Principal PM Manager at Microsoft Security

Immutable Storage and Legal Hold

Immutable storage provides write-once-read-many semantics. Two policy types exist.

1. Time-based retention -- blobs cannot be modified or deleted for a specified retention period

2. Legal hold -- blobs cannot be modified or deleted until a named legal hold tag is removed

The exam tests scenarios involving SEC Rule 17a-4(f), FINRA, CFTC, and HIPAA retention. Each requires immutable storage with appropriate retention. Candidates should know that an immutability policy can be locked, after which it cannot be shortened -- this is the property that satisfies most regulators.

---

References

1. Microsoft Learn. "Hot, cool, cold, and archive access tiers for blob data." Microsoft Corporation, 2025.
2. Microsoft Docs. "Azure Storage redundancy." Microsoft Corporation, 2025.
3. Microsoft Docs. "Configure a lifecycle management policy." Microsoft Corporation, 2025.
4. Patel, Harshul. Exam Ref AZ-104 Microsoft Azure Administrator. Microsoft Press, 2024.
5. Microsoft Docs. "Authorize access to blobs using Microsoft Entra ID." Microsoft Corporation, 2025.
6. Microsoft Cloud Security Benchmark. "Storage account security baseline." Microsoft Corporation, 2025.
7. Munoz, Santiago Fernandez. Exam Ref AZ-204 Developing Solutions for Microsoft Azure. Microsoft Press, 2024.