Azure Blob Storage is an object storage service that can store any form of unstructured data — images, videos, documents, log files, and more. For the AZ-204 exam, the key topics are SDK usage, distinguishing properties vs metadata, storage tiers, lifecycle policies, and immutability policies.
SDK: Three Client Classes
To understand the Blob Storage SDK, the most important thing is to distinguish the roles of three client classes. Think of an apartment complex as an example. It's like the relationship between the management office that manages the entire complex (BlobServiceClient), each building (BlobContainerClient), and each individual unit (BlobClient).
| Class | Role | Analogy | |-------|------|---------| | BlobServiceClient | Connects to the entire storage account | Apartment management office | | BlobContainerClient | Accesses a specific container (folder) | Managing a specific building | | BlobClient | Manipulates a specific blob file | A specific unit |
Each client can be obtained from its parent client or created directly with a URL.
Key Operation Patterns
Upload: blob_client.upload_blob(data, overwrite=True) Download: blob_client.download_blob().readall() Delete: blob_client.delete_blob() Create container: container_client.create_container() List blobs: container_client.list_blobs()
If you don't specify overwrite=True when uploading, an exception occurs when trying to upload to an existing blob.
Properties and Metadata: Storing Information About Files
Beyond the blob file itself, you can store information about the file in two ways. Think of a book as an example. The book's properties (thickness, page count, cover color — physical characteristics) are different in nature from the labels the library attaches (call number, shelf location, availability status).
System Properties
Properties automatically managed by Azure, directly tied to HTTP headers.
Content-Type: File format (e.g., image/jpeg, application/pdf) Content-Length: File size in bytes ETag: Version identifier (used for optimistic concurrency control) Last-Modified: Last modification time Content-Encoding, Content-Language, etc.
These properties can be retrieved via SDK or REST API, and some can be modified.
User-Defined Metadata
Key-value pairs that developers define arbitrarily. They are managed separately, not stored directly in the blob.
Format: key=value pairs (e.g., author=John, project=alpha, environment=production) Must follow HTTP header naming rules (letters, numbers, hyphens only) Retrieve: blob_client.get_blob_properties().metadata Set: blob_client.set_blob_metadata({"author": "John"})
Exam questions frequently test whether you can distinguish system properties from user-defined metadata.
Storage Tiers: Cost Optimization Based on Access Frequency
The appropriate storage tier depends on how often you need to access the data. Think of a refrigerator and storage room as an example. Food you eat frequently goes in the refrigerator (Hot), occasionally used items go in the storage room (Cool), rarely used items go in a deeper storage room (Cold), or long-term storage (Archive). Cosmos DB works the same way.
| Tier | Characteristics | Minimum Storage Duration | Access Cost | Storage Cost | |------|----------------|------------------------|-------------|--------------| | Hot | Frequently accessed data | None | Low | Highest | | Cool | Occasionally accessed data | 30 days | Medium | Medium | | Cold | Rarely accessed data | 90 days | High | Low | | Archive | Almost never accessed data | 180 days | Highest | Lowest |
You must remember the special characteristics of the Archive tier.
Offline state: Blobs in Archive cannot be read directly Rehydration: To read data, you must move it to Hot or Cool tier, which takes time Rehydration priority: Standard (several hours up to 15 hours), High (within 1 hour, extra cost)
If you change tiers or delete before the minimum storage duration, early deletion fees apply.
Lifecycle Management
You can set policies to automatically change a blob's tier or delete it over time. Like a company's document retention policy — rules like "files older than 3 months move to archive storage, files older than 1 year get destroyed" execute automatically.
Lifecycle policies are defined in JSON format.
Rule components: Filters (select target blobs) + Actions (what to do) Filter conditions: Blob name prefix, blob type, last modified date, etc. Supported actions: tierToCool, tierToCold, tierToArchive, delete Execution frequency: Runs once per day
For example, you can set a single policy: "blobs not modified for 30+ days move to Cool, 90+ days move to Archive, 365+ days get deleted."
Immutability Policy: Preventing Data Changes
A feature that protects blob data from being modified or deleted for regulatory requirements or legal obligations. Like storing a notarized contract in a safe. Even with permissions, it cannot be changed during the retention period.
Time-Based Retention Policy
Blobs cannot be modified or deleted for a specified period.
Retention period: 1 day to 146,000 days (400 years) Before locking: Policy can be modified or deleted After locking (Locked): Retention period cannot be shortened, policy cannot be deleted (only extension allowed) Use cases: Financial records, medical data, legal document retention
Legal Hold
Protects blobs indefinitely during legal disputes or investigations to preserve evidence.
Activated/deactivated via tags While Legal Hold is active, blobs cannot be modified or deleted Multiple tags can be applied simultaneously
| Policy Type | Duration | Lock | Use Case | |-------------|---------|------|---------| | Time-Based Retention | Specified period | Lockable | Compliance, legal retention | | Legal Hold | Indefinite | Released via tag | Legal disputes, investigations |
!Time-based retention versus Legal Hold
Exam Key Points
"Connect to entire storage account" -- BlobServiceClient
"Access specific container" -- BlobContainerClient
"Manipulate specific file (upload/download/delete)" -- BlobClient
"File information managed via HTTP headers" -- System properties (Content-Type, ETag, etc.)
"Key-value pairs defined by developers" -- User-defined metadata
"To read data from Archive" -- Rehydration required (move to Hot/Cool)
"Minimum storage: Hot=none, Cool=30 days, Cold=90 days, Archive=180 days"
"Automatic tier transitions/deletion via JSON policy" -- Lifecycle management
"Block modification/deletion for a specified period" -- Time-based retention policy
"Block modification/deletion indefinitely, released via tag" -- Legal Hold