AzureAZ-104

Azure Blob Storage Explained for AZ-104

Blob storage is where Azure stores unstructured data at scale: images, videos, backups, log files, application binaries, and anything else that does not fit neatly into a database table. The name blob stands for Binary Large Object, which is a deliberately broad term covering any file format. Within blob storage, Azure offers three distinct blob types optimized for different write patterns, and a tiering system that lets you balance access performance against storage cost. The AZ-104 exam tests blob types, access tiers, lifecycle management, data protection features like soft delete and versioning, and immutable storage for compliance.

7 min
3 sections · 8 exam key points

Blob types and access tiers

Block blobs are the most common blob type and the one you use for almost everything: images, videos, documents, backups, and application data. Block blobs are built from blocks of data uploaded independently and committed together. The maximum size is approximately 190 TB. Append blobs are optimized for append-only operations: each write adds data to the end of the blob without modifying existing content. They are purpose-built for logging, where new log entries are appended continuously. Page blobs are optimized for random read/write access and are used internally by Azure as the storage for virtual machine disks (VHDs). If you are using managed disks, Azure handles page blobs transparently.

Access tiers determine the cost tradeoff between storage price and retrieval cost. Hot tier is for data that is accessed frequently: low retrieval cost, higher per-GB storage price. Cool tier is for data accessed infrequently but that needs to remain available quickly: lower storage price, slightly higher retrieval cost, and a minimum storage duration of 30 days (delete before 30 days and you pay a penalty). Cold tier (a newer addition) sits between Cool and Archive: lower storage cost than Cool, higher retrieval cost, minimum 90-day duration. Archive tier is for data that is rarely or never accessed: the lowest possible storage cost, but the blob must be rehydrated before reading, which takes hours. Archive is the right choice for long-term backups and regulatory retention.

Rehydration moves a blob from Archive back to Hot or Cool so it can be read. Standard priority rehydration takes up to 15 hours. High priority rehydration completes within one hour for blobs under 10 GB and is more expensive. You cannot read an archived blob directly: it must be fully rehydrated first.

Data protection: versioning, soft delete, and immutability

Blob versioning automatically saves a copy of a blob every time it is modified or deleted. Each version has its own version ID. If a user accidentally overwrites or deletes a blob, you restore the previous version without relying on a separate backup process. Versioning adds storage cost for retained versions, so lifecycle policies should include rules to expire old versions.

Soft delete protects against accidental deletions by retaining deleted blobs for a configurable retention period (1 to 365 days). During the retention period, the blob appears deleted in normal operations but can be restored from the portal, CLI, or API. Soft delete and versioning are independent features that complement each other: soft delete catches deletions, versioning catches overwrites.

Immutable blob storage implements WORM (Write Once Read Many) compliance. Time-based retention policies lock blobs for a specified duration: no one can delete or overwrite them during the retention period. Legal hold tags can also be applied to blobs to prevent deletion regardless of any configured retention period, typically used during active litigation. Immutable storage meets regulatory requirements from financial, healthcare, and legal industries that mandate unalterable record retention.

How to choose the correct answer

Block blob: general purpose, images, videos, backups. The default choice for most use cases.

Append blob: log files, audit data, any workload where data is only added, never modified.

Page blob: VM disk storage (VHD). Typically managed transparently by Azure managed disks.

Hot tier: frequently accessed data, lowest retrieval latency, higher storage cost.

Cool tier: infrequent access, 30-day minimum, lower storage cost. Slight retrieval penalty.

Archive tier: rarely accessed, rehydration required (hours), lowest storage cost.

Soft delete: recovers accidentally deleted blobs within retention period. Enable on all production containers.

Immutable storage (time-based retention): compliance WORM. Cannot be disabled before expiry, even by account owner.

Key exam facts — AZ-104

  • Block blobs: most common, up to ~190 TB, used for images, videos, backups, documents.
  • Append blobs: append-only writes, optimized for logging scenarios.
  • Page blobs: random I/O, used as backing storage for Azure managed VM disks.
  • Hot: frequent access. Cool: 30-day minimum, infrequent. Cold: 90-day minimum. Archive: rehydrate to read.
  • Archive rehydration: Standard up to 15 hours, High Priority under 1 hour (premium cost).
  • Soft delete: catches accidental deletions, configurable 1-365 day retention period.
  • Blob versioning: each modification creates a new version, previous versions restorable.
  • Immutable storage: time-based retention or legal hold, WORM compliance for regulated industries.

Common exam traps

You can read archived blobs immediately after setting the access tier to Archive.

Archive tier blobs must be rehydrated (moved back to Hot or Cool) before they can be read. Rehydration takes up to 15 hours for standard priority or under 1 hour for high priority. During rehydration, the blob cannot be read. Plan retention and retrieval workflows around this delay.

Soft delete and blob versioning provide the same protection.

Soft delete protects against deletion: if a blob is deleted, it can be recovered within the retention period. Blob versioning protects against overwrites: each modification creates a new version, preserving previous content. Together they cover both scenarios. Versioning alone does not help if the entire blob is deleted without versioning showing a previous version.

Append blobs can be used instead of block blobs for any workload.

Append blobs only support append operations. You cannot modify or overwrite existing data in an append blob. This makes them unsuitable for most application storage patterns where files need to be updated. Use append blobs specifically for log aggregation and audit trails where data is always added at the end.

Practice this topic

Test yourself on Azure Blob Storage

JT Exams routes you to questions in your exact weak areas — automatically, after every session.

No credit card · Cancel anytime

Related certification topics