This chapter covers Immutable Blob Storage in Azure, specifically the two protection modes: Legal Hold and Time-Based Retention. These features are critical for compliance scenarios such as SEC Rule 17a-4, FINRA regulations, and other legal hold requirements. On the AZ-104 exam, questions on immutable storage appear in approximately 5-10% of storage-related questions, often testing your ability to differentiate between the two modes, their configuration, and their behavior. Mastering this topic ensures you can design compliant storage solutions and avoid common exam traps.
Jump to a section
Imagine a bank's secure document storage room. The room has two types of protection: a 'legal hold' and a 'time-based retention' system. The legal hold works like a court order: if a judge issues a hold on a specific safe deposit box, the bank manager cannot remove or tamper with that box's contents, even if the customer requests it. The hold remains until the judge explicitly lifts it. There is no expiration date; it lasts indefinitely until the legal matter is resolved. The time-based retention, on the other hand, is like a time-lock safe. When a document is placed inside, a timer starts. The safe door will not open until the timer counts down to zero. Once the timer expires, the document can be removed. However, if a legal hold is also placed on that document, the timer pauses—the safe remains locked even after the timer would have expired. The bank cannot override either mechanism; they are immutable protections. The bank's policy ensures that once a document is protected by either method, no one—not even the bank president—can delete or modify it. This mirrors Azure's Immutable Blob Storage: Legal Hold is indefinite and manually lifted, while Time-Based Retention is a fixed period that can be extended but not shortened, and the two can coexist, with legal hold overriding the retention period.
What is Immutable Blob Storage?
Immutable Blob Storage is a feature of Azure Blob Storage that allows you to store data in a write-once, read-many (WORM) state. Once a blob is written, it cannot be modified or deleted for a user-specified retention interval or until a legal hold is explicitly removed. This is essential for meeting regulatory compliance requirements such as SEC Rule 17a-4, which mandates that financial records be stored in a non-erasable, non-rewritable format. Immutability is configured at the container level and applies to all blobs within that container.
How It Works Internally
Immutable Blob Storage uses two distinct policies: Time-Based Retention and Legal Hold. These policies are enforced at the storage service level, not at the client or application level. When a container has an immutability policy, Azure Blob Storage tracks each blob's state and blocks any write or delete operations that would violate the policy.
Time-Based Retention: You set a retention period (in days) on a container. Each blob inherits this period. The retention interval starts when the blob is created. During this period, blobs cannot be overwritten or deleted. After the retention period expires, the blob's immutability state becomes 'expired' and it can be deleted (provided no legal hold exists). The retention period can be extended but never shortened.
Legal Hold: You add one or more legal hold tags to a container. These tags are arbitrary strings (e.g., 'Case-123'). When a container has an active legal hold, all blobs in that container are protected from deletion or modification. Legal holds have no expiration; they remain until explicitly cleared by removing all tags. Legal holds override time-based retention—even if a blob's retention period has expired, it cannot be deleted if a legal hold is active.
Key Components and Defaults
Immutability Policy State: Can be 'Unlocked' or 'Locked'. An unlocked policy can be modified (retention period can be changed, legal holds added/removed). A locked policy is permanent—the retention period cannot be shortened, and the policy cannot be deleted. Locking is irreversible. For compliance with regulations like SEC 17a-4, the policy must be locked.
Retention Period: Measured in days, minimum 1 day, maximum 146,000 days (400 years). Default is not set; you must specify.
Legal Hold Tags: Up to 10 tags per container. Each tag is a string up to 64 characters. Tags are case-sensitive.
Versioning: Immutable blobs can be versioned. When a blob is overwritten (if allowed by policy), a new version is created. However, with immutability, overwrites are blocked unless the policy allows appending (append blobs).
Configuration and Verification
You can configure immutability via Azure Portal, PowerShell, Azure CLI, or REST API.
Azure CLI Example:
# Create a container with a time-based retention policy (unlocked)
az storage container immutability-policy create \
--account-name mystorageaccount \
--container-name mycontainer \
--period 365 \
--allow-protected-append-writes true
# Lock the policy (irreversible)
az storage container immutability-policy lock \
--account-name mystorageaccount \
--container-name mycontainer \
--if-match <etag>
# Add a legal hold
az storage container legal-hold set \
--account-name mystorageaccount \
--container-name mycontainer \
--tags "Case-123" "Case-456"
# View immutability policy
az storage container immutability-policy show \
--account-name mystorageaccount \
--container-name mycontainer
# View legal hold status
az storage container legal-hold show \
--account-name mystorageaccount \
--container-name mycontainerPowerShell Example:
# Set immutability policy
Set-AzStorageContainerImmutabilityPolicy `
-ResourceGroupName myrg `
-StorageAccountName mystorageaccount `
-ContainerName mycontainer `
-ImmutabilityPeriod 365
# Lock policy
Lock-AzStorageContainerImmutabilityPolicy `
-ResourceGroupName myrg `
-StorageAccountName mystorageaccount `
-ContainerName mycontainer `
-IfMatch <etag>
# Add legal hold
Add-AzStorageContainerLegalHold `
-ResourceGroupName myrg `
-StorageAccountName mystorageaccount `
-ContainerName mycontainer `
-Tag "Case-123"Interaction with Related Technologies
Soft Delete: Immutability takes precedence over soft delete. If a blob is protected by immutability, it cannot be soft-deleted. However, if the blob is not protected, soft delete can be used.
Versioning: When versioning is enabled, overwriting a blob creates a new version. But with immutability, overwrites are blocked unless the blob is an append blob and 'allowProtectedAppendWrites' is enabled. This setting allows new blocks to be appended but prevents modification of existing blocks.
Snapshots: Snapshots are point-in-time read-only copies. Immutability does not prevent creating a snapshot, but the snapshot inherits the immutability of the base blob.
Blob Inventory: Immutable blobs are included in inventory reports.
Lifecycle Management: Lifecycle policies cannot delete or tier blobs that are under immutability protection. The policy will skip those blobs.
Common Exam Scenarios
The AZ-104 exam tests your understanding of when to use each mode and the implications of locking. A typical question might present a compliance requirement (e.g., 'Data must be retained for 7 years and cannot be altered by anyone, including the storage administrator') and ask which configuration is required. The answer would be: Locked time-based retention policy with a period of 2557 days (7 years). Another question might ask about legal hold behavior: 'A company needs to preserve data for an ongoing lawsuit. The retention period has expired. What happens?' Answer: The data is still protected if a legal hold is active.
Technical Nuances
The immutability policy is applied at the container level, not the storage account level. You can have multiple containers with different policies.
The 'allowProtectedAppendWrites' flag is specific to append blobs. It allows writing new blocks to an append blob while the immutability policy is in effect. This is useful for logging scenarios.
When a time-based retention policy is locked, the retention period can only be increased, never decreased. After locking, the policy cannot be removed.
Legal hold tags can be added or removed at any time, even if the time-based policy is locked. However, removing all tags clears the legal hold.
The retention period is based on the blob's creation time, not the policy creation time. If you change the retention period on an unlocked policy, it applies to new blobs and existing blobs (the new period is used for remaining duration). For locked policies, changes only affect new blobs.
Performance and Scale Considerations
Immutable Blob Storage has no performance overhead for read operations. Write operations are slightly affected because the service must check policy compliance. The feature is available in all Azure regions and supports all storage tiers (Hot, Cool, Archive). However, blobs in the Archive tier must be rehydrated before they can be read or deleted, even if the immutability policy has expired.
Troubleshooting
Common errors: - 'This operation is not permitted because the blob is immutable' – occurs when trying to delete or overwrite a protected blob. - 'The immutability policy is locked and cannot be modified' – occurs when trying to reduce retention or delete policy. - 'Legal hold is active on the container' – occurs when trying to delete a container with active legal holds.
Create a Storage Account
First, you need a general-purpose v2 storage account (standard or premium). Immutable Blob Storage is supported in GPv2 and BlobStorage accounts. Enable hierarchical namespace (Azure Data Lake Storage Gen2) if needed, but immutability works with both flat and hierarchical namespaces. Ensure the account is in the same region as your compliance requirements. For exam purposes, remember that immutable storage is not available for Azure Files or Table storage.
Create a Container
Create a container within the storage account. This container will hold the blobs that need immutability protection. You can create multiple containers with different policies. For example, one container for financial records with a 7-year retention, another for legal hold documents. The container name must be lowercase and between 3-63 characters. Public access level can be set to private (recommended for compliance).
Configure Immutability Policy
On the container, navigate to 'Immutability policy' and enable it. Choose either 'Time-based retention' or 'Legal hold'. For time-based, specify the retention period in days (e.g., 2557 for 7 years). For legal hold, add one or more tags (e.g., 'Case-2024-001'). You can combine both. The policy starts as 'Unlocked' by default. To meet strict compliance, you must lock the policy. Locking is irreversible and prevents any reduction in retention period or deletion of the policy.
Upload Blobs
Upload blobs to the container. Once uploaded, the immutability policy applies immediately. For time-based retention, the clock starts at upload time. For legal hold, the hold applies from the moment the tag is added. Blobs can be block blobs, append blobs, or page blobs. Append blobs have special handling: you can enable 'Allow protected append writes' to permit appending new blocks while immutability is in effect. This is useful for logging data that must be append-only.
Verify and Monitor
Use Azure Portal, CLI, or PowerShell to verify the immutability state. In the portal, the container's 'Immutability policy' blade shows the state (Locked/Unlocked), retention period, and legal hold tags. You can also use Azure Monitor to audit changes to immutability policies. For example, the 'StorageBlobLogs' can show attempts to delete protected blobs. Regularly review legal hold tags to ensure they are still relevant. Removing all tags clears the legal hold and may expose data to deletion if the time-based retention has expired.
Enterprise Scenario 1: Financial Compliance (SEC Rule 17a-4)
A large investment bank must retain all electronic communications and trade records for 7 years in a non-erasable, non-rewritable format. They use Azure Blob Storage with a locked time-based retention policy of 2557 days (7 years) on a container named 'sec-records'. The policy is locked to satisfy the 'no deletion' requirement. Additionally, they enable 'Allow protected append writes' on append blobs to log real-time trade data. They also set up legal hold tags for any ongoing SEC investigations. The bank monitors the retention expiry using Azure Monitor alerts. A common mistake is forgetting to lock the policy, which would allow an administrator to shorten the retention period, violating compliance. In production, they also enable soft delete as a backup, though immutability takes precedence. Performance is not an issue as read operations are unaffected; write operations experience a slight latency due to policy checks.
Enterprise Scenario 2: Healthcare Records Retention
A hospital network must retain patient records for 10 years per HIPAA regulations. They use a locked time-based retention policy of 3650 days. However, they also need to preserve records for active malpractice lawsuits. They add legal hold tags for each case (e.g., 'Malpractice-2023-001'). The legal hold ensures that even after 10 years, the records are not deleted until the lawsuit is resolved. They use Azure Policy to enforce that all storage accounts have immutability enabled for containers holding health data. A challenge is managing legal hold tags at scale; they use automation scripts to add/remove tags based on case status. Misconfiguration occurs when an administrator removes a legal hold tag prematurely, leading to data deletion after retention expires. They mitigate this by requiring multi-factor authorization for legal hold changes.
Enterprise Scenario 3: Media and Entertainment
A media company stores raw footage and final cuts for client projects. They use time-based retention for 1 year (contractual obligation) but also need to protect assets during disputes. They set up legal hold tags for disputed projects. A unique requirement is that editors need to append metadata to existing video files (append blobs). They enable 'Allow protected append writes' to allow appending but prevent overwriting. They also use lifecycle management to tier older blobs to Cool storage after 30 days, but immutability prevents tiering if retention is active. They learned to configure lifecycle policies to skip blobs under immutability. A common error is attempting to delete a container with an active legal hold, which fails with an error. They use PowerShell scripts to check for legal holds before deletion.
What AZ-104 Tests
This topic falls under Objective 2.1: 'Configure storage accounts' and Objective 2.2: 'Configure blob storage'. The exam expects you to:
Differentiate between time-based retention and legal hold.
Understand the locking mechanism and its irreversibility.
Know the minimum and maximum retention periods (1 day to 146,000 days).
Recognize that legal hold tags are arbitrary strings and up to 10 per container.
Understand that immutability is configured at the container level.
Know that 'Allow protected append writes' is for append blobs only.
Be aware that soft delete and lifecycle management are overridden by immutability.
Common Wrong Answers and Traps
'You can shorten the retention period after locking.' – This is false. Locking makes the retention period permanent; you can only extend it.
'Legal hold has a default duration of 90 days.' – No, legal hold has no expiration; it lasts until tags are removed.
'Immutability is set at the storage account level.' – False, it's per container.
'You can delete a container with an active legal hold.' – False, you must remove all legal hold tags first.
'Time-based retention starts when the policy is created.' – No, it starts per blob at upload time.
Specific Numbers and Terms
Retention period: 1 to 146,000 days.
Legal hold tags: up to 10, each up to 64 characters.
Policy states: Unlocked (modifiable) vs Locked (permanent).
SEC 17a-4 requires locked policy.
'AllowProtectedAppendWrites' is a boolean flag.
Edge Cases
If you have both a time-based retention and a legal hold, the blob is protected until the later of the two. If legal hold is removed before retention expires, the blob remains protected until retention expires. If retention expires but legal hold remains, the blob is still protected.
Append blobs: With 'AllowProtectedAppendWrites' enabled, you can append but not overwrite. If you try to overwrite a block, it fails.
Deleting a container: You must first remove the immutability policy (if unlocked) or ensure no blobs exist. If locked, you cannot delete the policy, so you must delete all blobs first (only after retention expires and no legal hold).
How to Eliminate Wrong Answers
If a question mentions 'regulatory requirement for non-erasable storage', look for 'locked' policy.
If a question says 'indefinite hold', it's legal hold.
If a question says 'retain for X years', it's time-based retention.
If a question asks about modifying retention, consider whether the policy is locked or unlocked.
If a question mentions 'append blobs', think of 'AllowProtectedAppendWrites'.
Immutable Blob Storage provides WORM (Write Once, Read Many) protection for compliance.
Time-based retention: fixed period from blob creation; locked policy is irreversible.
Legal hold: indefinite hold via tags; no expiration.
Both can coexist; legal hold takes precedence.
Configured at container level, not storage account level.
Retention period range: 1 to 146,000 days.
Legal hold tags: up to 10, each up to 64 characters.
AllowProtectedAppendWrites enables appending to append blobs.
Soft delete and lifecycle management are overridden by immutability.
Locked policy is required for SEC 17a-4 compliance.
These come up on the exam all the time. Here's how to tell them apart.
Time-Based Retention
Has a fixed duration (1 to 146,000 days).
Retention starts per blob at creation time.
Can be locked to make it permanent.
Once locked, retention period can only be extended.
Blobs become deletable after retention expires (if no legal hold).
Legal Hold
Has no expiration; lasts until tags are removed.
Applies immediately when tags are added.
Cannot be locked; tags can be added/removed anytime.
Tags are arbitrary strings (up to 10 per container).
Overrides time-based retention; prevents deletion even after expiry.
Mistake
Immutable Blob Storage prevents all write operations, including appending.
Correct
Append blobs can still be appended if the 'Allow protected append writes' setting is enabled. This allows adding new blocks but prevents modifying or deleting existing blocks.
Mistake
You can delete a blob immediately after its time-based retention period expires.
Correct
If a legal hold is active on the container, the blob remains protected even after retention expires. You must clear all legal hold tags first.
Mistake
The retention period starts when you create the immutability policy.
Correct
The retention period starts per blob at the time of its creation (upload). Changing the policy's retention period affects only the remaining duration for existing blobs (if unlocked) or only new blobs (if locked).
Mistake
You can have multiple immutability policies on the same container.
Correct
A container can have at most one immutability policy, which can include both a time-based retention period and legal hold tags simultaneously.
Mistake
Legal hold tags are automatically removed when the retention period expires.
Correct
Legal hold tags persist until manually removed. They are independent of time-based retention and have no expiration.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An unlocked policy can be modified: you can change the retention period (increase or decrease) or delete the policy. A locked policy is permanent: you cannot shorten the retention period or delete the policy. Locking is irreversible. For compliance with regulations like SEC Rule 17a-4, the policy must be locked.
You can delete a container only if the immutability policy is unlocked and you first delete the policy, or if the policy is locked but all blobs have been deleted (after their retention periods have expired and no legal hold is active). If legal hold tags exist, you must remove them first.
Append blobs are designed for append-only operations. With immutability, you can enable the 'Allow protected append writes' setting, which permits new blocks to be appended to the blob while the immutability policy is in effect. However, existing blocks cannot be modified or deleted. This is useful for logging scenarios.
The operation fails with an error message stating that the blob is immutable. The blob cannot be overwritten or deleted until the immutability policy no longer applies (retention expired and no legal hold).
Lifecycle management policies can be defined, but they will skip blobs that are under immutability protection. For example, a rule to delete blobs after 30 days will not delete a blob that is within its retention period or under legal hold.
Yes, you can have up to 10 legal hold tags per container. Each tag is a string of up to 64 characters and is case-sensitive.
You can use the Azure Portal (under 'Immutability policy' in the container blade), Azure CLI (`az storage container immutability-policy show`), or PowerShell (`Get-AzStorageContainerImmutabilityPolicy`). The output shows the state (Locked/Unlocked), retention period, and legal hold tags.
You've just covered Immutable Blob Storage: Legal Hold and Time-Based Retention — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?