Browse Microsoft Certification Guides

Azure AZ-204 Blob Storage Guide

Study Azure AZ-204 Blob Storage: key concepts, common traps, and exam decision cues.

This lesson covers the Blob Storage implementation path AZ-204 expects developers to know: setting and reading metadata, using the right SDK operations, and understanding when lifecycle management belongs in policy rather than in app code.

Metadata: User-defined descriptive key-value data stored with a blob object.

Lifecycle policy: Rule-driven storage management that moves or deletes data automatically based on age or state.

What Microsoft is really testing here

AZ-204 is checking whether you can separate:

  • blob data from descriptive blob attributes
  • per-request SDK actions from long-term rule-driven storage behavior
  • application logic from storage-governance policy
  • blob object management from unrelated messaging or app-hosting features

Fast Blob Storage chooser

Need Strongest first lane Why it fits
Read or write blobs from code Blob Storage SDK Core blob data path
Attach descriptive values to a blob Metadata or blob properties Per-blob descriptive state
Transition or delete blobs automatically over time Lifecycle management policy Rule-driven storage behavior
Find or act on blobs using account-wide long-term rules Lifecycle policy or related storage-governance feature This is policy, not per-request application code

SDK operations versus metadata versus lifecycle management

If the question says Think first about
upload, download, read, write, list, or update blob content Blob Storage SDK
descriptive values attached to a blob metadata or blob properties
tiering or deletion after age-based rules lifecycle management policy
repeating storage-retention logic across many blobs policy instead of app code

According to the current Azure Blob lifecycle management docs, lifecycle management uses rule-based policies to transition or delete blobs automatically based on time, access, or object state.

Common traps

Trap Better reading
“If code can do it, lifecycle policy is unnecessary.” AZ-204 often rewards the policy-based storage answer when the requirement is long-term automatic management.
“Metadata is the same thing as the blob body.” Metadata describes the blob; it is not the blob content itself.
“Lifecycle management is mainly a per-request SDK feature.” It is an account-level rule-driven policy concept.
“Blob metadata is the answer whenever classification is mentioned.” Some classification or retention needs point to policies, tags, or broader storage-management features instead.

Harder scenario question

A team stores large files in Blob Storage. The application should attach descriptive values to each blob when it is uploaded, but long-term cost optimization and deletion must happen automatically without app code running cleanup jobs.

The strongest reading is:

  1. use Blob Storage SDK operations plus metadata for the upload path, and use lifecycle management policy for long-term transition or deletion
  2. use lifecycle policy for uploads because policy is always better than code
  3. use Queue Storage because automatic deletion sounds like messaging
  4. use App Service deployment slots because the data should be staged

Correct answer: 1. Metadata belongs in the upload/data path, while long-term retention and tiering belong in policy.

Decision order that usually wins

  1. Separate blob CRUD, descriptive object state, and long-term storage governance.
  2. If the question is about upload, download, list, or delete behavior in code, stay in the Blob SDK lane.
  3. If the question is about attaching descriptive values to a blob, think metadata and properties.
  4. If the question is about automated movement or deletion over time, think lifecycle management policy.
  5. Keep per-blob descriptive state separate from rule-based retention behavior.

Quiz

Loading quiz…
Revised on Sunday, May 10, 2026