6.4 Unstructured Data Protection & Durability Design

Why Protection and Durability Design Matters on AZ-305

Redundancy (Section 6.3) protects against hardware and datacenter failure — it does nothing to protect against a user or attacker deleting or encrypting your data on purpose. The "Recommend a data solution for protection and durability" objective tests a different, narrower layer of defense: soft delete, versioning, and immutable (WORM) storage — each aimed at a specific failure mode, and frequently combined in ransomware-resilience and regulatory-compliance scenarios.

Blob Soft Delete: Undo for Accidental Deletes and Overwrites

Soft delete keeps a deleted or overwritten blob, snapshot, or version recoverable for a configurable retention period of 1 to 365 days. During that window, the Undelete Blob operation restores it; after the window expires, it is permanently gone.

What soft delete protects against: an application bug or a person accidentally deleting or overwriting a blob. What it does not protect against: deletion of the container itself (enable container soft delete separately) or deletion of the storage account (only a resource lock on the account prevents that).

Blob Versioning: An Automatic History, Not Just an Undo Button

Blob versioning, when enabled, automatically creates a new immutable previous version every time a blob is overwritten — with no application code changes required. Combined with soft delete, deleting the "current" version simply promotes the most recent previous version to current, rather than losing the data outright.

Versioning is also the prerequisite for point-in-time restore for block blobs, which lets an administrator roll an entire container (or a prefix within it) back to its exact state at any point within the retention window — the strongest answer to "recover from a ransomware attack that corrupted thousands of blobs at once."

Immutable Storage: WORM for Regulatory Compliance

Immutable storage (Write Once, Read Many — WORM) is the strongest protection tier: while an immutability policy is active, data cannot be modified or deleted by anyone, including the storage account owner. There are two policy types:

Both can be scoped at container level (one policy applies to the whole container, and is supported on ADLS Gen2/hierarchical-namespace accounts) or version level (per-account, per-container, or per-blob-version granularity — requires versioning, and is not yet supported on hierarchical-namespace/ADLS Gen2 accounts).

A time-based retention policy starts unlocked (for testing only) and must be locked to be compliant with regulations such as SEC Rule 17a-4(f), FINRA Rule 4511, and CFTC Rule 1.31(d) — all commonly named in financial-services AZ-305 scenarios. Once locked, the retention period can only be extended, never shortened, and a locked container can only be deleted once it is empty.

Trap: immutability policies are incompatible with point-in-time restore. You cannot combine "roll back to any moment" recovery with "nobody can ever modify this data" compliance on the same data, because point-in-time restore is itself a form of modification.

Tracking Immutability at Scale

For accounts with many containers and blobs, Azure Storage blob inventory generates a daily report listing every blob, snapshot, and version along with whether it currently has an immutability policy applied. This is the standard answer whenever a scenario asks how to prove, for audit purposes, which objects are actually protected — manually enumerating containers does not scale, and the inventory report is purpose-built for that governance need. A related nuance: version-level immutability policies specifically are not compatible with blob inventory on the same account, so an architect choosing version-level WORM for granular per-blob retention needs a different auditing approach, typically the policy's own audit log (which records up to seven time-based retention commands per container, including user ID, command type, and timestamps).

Building a Layered Protection Strategy

A defense-in-depth answer for "protect blob data end-to-end" typically stacks:

1. Soft delete + container soft delete — undo accidental application-level mistakes.
2. Versioning — automatic history and the basis for point-in-time restore.
3. Immutable storage (locked time-based retention) — regulatory-grade tamper protection for records that must never change.
4. Resource lock on the storage account — the only control that stops the account itself from being deleted.
5. Azure Backup for blobs (operational or vaulted) — an additional layer outside the storage account itself, useful when the requirement extends to protecting against the loss of the account or subscription, not just individual objects.

Scenario Walkthrough

A broker-dealer must retain trade confirmation records for 7 years in a state that satisfies SEC 17a-4(f), while also protecting the storage account from accidental deletion by an over-privileged administrator.

Design: enable blob soft delete for day-to-day protection, then apply a container-level, locked, time-based retention policy set to a 7-year (2,555-day) retention interval for the compliance requirement, and add a resource lock (CanNotDelete) on the storage account so the account itself cannot be removed regardless of a user's RBAC permissions.

Key Takeaways Recap

Soft delete undoes mistakes, versioning gives you an automatic rollback history, and immutable storage is the only layer that survives a malicious or over-privileged administrator. Pick the layer — or combination of layers — that matches the actual threat named in the scenario, not just "more protection is always better."