This chapter covers Blob Versioning and Soft Delete, two critical data protection features in Azure Blob Storage. These features are essential for safeguarding against accidental deletion, overwrite, and corruption of blob data. On the AZ-104 exam, questions on data protection for Azure Storage, including versioning and soft delete, typically account for 10-15% of the Storage domain questions. You must understand how to enable, configure, and interact with these features, including retention periods, cost implications, and integration with other Azure services.
Jump to a section
Imagine a library where patrons can borrow books and return them. Without any protection, if a patron accidentally spills coffee on a book and returns it, the library loses the original content. Now, the library implements two features: a 'soft delete' bin and a 'versioning' shelf. Soft delete: When a patron returns a damaged book, instead of discarding it, the librarian places it in a special bin that is not visible to other patrons but can be recovered by library staff within a 30-day window. After 30 days, the bin is emptied permanently. Versioning: Each time a patron checks out a book, the librarian makes a photocopy of the current state and stores it on a separate shelf. If the patron returns a damaged book, the librarian can restore the last good copy. The photocopies are kept indefinitely unless the librarian sets a retention policy to delete old copies after a certain number of days. Together, these features protect against accidental deletion and corruption. In Azure Blob Storage, soft delete preserves deleted blobs for a configurable retention period (default 7 days), and versioning automatically saves a snapshot of a blob each time it is modified or deleted. The combination allows recovery from both accidental overwrites and deletions.
What Are Blob Versioning and Soft Delete?
Blob Versioning and Soft Delete are complementary features that protect blob data in Azure Storage accounts. Both are disabled by default and must be explicitly enabled at the storage account level.
Blob Versioning automatically creates a new version of a blob every time it is modified or deleted. Each version is a complete, immutable copy of the blob at that point in time. When versioning is enabled, every write operation (PutBlob, PutBlockList, SetBlobProperties, etc.) creates a new version. Deleting a blob does not remove the data; instead, it creates a delete marker version, which is a special version with a timestamp but no data. You can restore a previous version by promoting it to the current version.
Soft Delete (also known as blob soft delete) protects blobs from accidental deletion. When enabled, deleted blobs are not permanently removed; they are transitioned to a soft-deleted state. Soft-deleted blobs are invisible to normal read/list operations but can be recovered within a configurable retention period (1 to 365 days). After the retention period expires, the blob is permanently deleted. Soft delete can be applied to blobs, blob snapshots, and blob versions.
How They Work Internally
When both features are enabled, the interaction is nuanced. Consider a blob with versioning enabled. If a user deletes the blob, Azure creates a delete marker version. The underlying data (previous versions) remains intact. If soft delete is also enabled, the delete marker itself can be soft-deleted when it is deleted (e.g., by a lifecycle management policy or manual deletion). This creates a soft-deleted delete marker, which is recoverable during the soft delete retention period.
When you restore a blob, you typically promote a non-current version to become the current version. If the blob was deleted (has a delete marker as current version), you can delete the delete marker to restore the last non-current version as current. Alternatively, you can copy a specific version to the current version.
Key Components, Values, Defaults, and Timers
Soft Delete Retention Period: Configurable from 1 to 365 days. Default is 7 days. This applies to all soft-deleted blobs, including delete markers and versions.
Versioning: Once enabled, cannot be disabled for the storage account. You can suspend versioning, but re-enabling it later is allowed. Deleting a storage account requires versioning to be disabled first.
Cost: Each version is billed as a separate blob at the same rate as the base blob. Soft-deleted blobs are billed until permanently deleted. Enabling versioning can significantly increase storage costs if blobs are frequently updated.
Lifecycle Management: Can be used to automatically delete old versions or soft-deleted blobs after a specified number of days. This helps manage costs.
Configuration and Verification Commands
To enable soft delete using Azure CLI:
az storage blob service-properties update --account-name <storage-account> --enable-delete-retention true --delete-retention-days 7To enable versioning using Azure CLI (requires storage account version 2019-07-07 or later):
az storage account blob-service-properties update --account-name <storage-account> --enable-versioning trueTo list blob versions:
az storage blob list --account-name <storage-account> --container-name <container> --include vTo list soft-deleted blobs:
az storage blob list --account-name <storage-account> --container-name <container> --include dTo restore a soft-deleted blob:
az storage blob undelete --account-name <storage-account> --container-name <container> --name <blob-name>To promote a specific version as current:
az storage blob copy start --account-name <storage-account> --destination-container <container> --destination-blob <blob-name> --source-uri <version-uri>Interaction with Related Technologies
Azure Backup: Can be used for long-term retention of blobs, complementing versioning and soft delete.
Azure Files: Soft delete is also available for Azure file shares (file share soft delete), but versioning is not.
Storage Account Types: Versioning is available for general-purpose v2 (GPv2) and BlobStorage accounts. It is not supported for general-purpose v1 (GPv1) or premium block blob accounts.
Point-in-Time Restore: For block blobs, Azure offers point-in-time restore, which can restore a container to a previous state. This feature requires versioning to be enabled.
Exam-Relevant Details
The default soft delete retention period is 7 days. Exam questions may ask you to configure a different period.
Versioning is irreversible once enabled; you can only suspend it.
Soft delete can be disabled, but existing soft-deleted blobs are retained until their retention period expires.
When both features are enabled, soft delete protects delete markers and versions from premature deletion.
Lifecycle management rules can target versions and soft-deleted blobs with the $web container if static website hosting is enabled.
Cross-account scenarios: Versioning and soft delete operate within a single storage account. They do not replicate across accounts unless you use object replication.
Enable Soft Delete on Storage Account
Navigate to the Azure portal, select your storage account, go to 'Data protection' under 'Blob service'. Enable 'Soft delete for blobs' and set the retention period (1-365 days). Click Save. Alternatively, use the Azure CLI command `az storage blob service-properties update --enable-delete-retention true --delete-retention-days 7`. This enables soft delete for all blobs in the account. At the packet level, the Azure Storage service updates its metadata to flag future deletions as soft deletes. There is no immediate effect on existing blobs.
Enable Blob Versioning on Storage Account
In the Azure portal, under 'Data protection', toggle 'Blob versioning' to Enabled. Click Save. Using CLI: `az storage account blob-service-properties update --enable-versioning true`. Once enabled, the next write to any blob will create a version. The version ID is a GUID timestamp. Existing blobs will not have a version until they are modified. Versioning cannot be disabled; it can only be suspended. Suspension stops creating new versions but retains existing ones.
Upload and Modify a Blob to Create Versions
Upload a blob (e.g., file.txt) to a container. This creates the current version with version ID '2024-01-01T00:00:00.0000000Z'. Modify the blob by uploading a new version or using `PutBlob`. A new version is created with a new timestamp. The previous version becomes non-current. You can list all versions with `--include v`. Each version is an independent blob object with its own ETag and MD5 hash.
Delete a Blob to Create a Delete Marker
Delete the blob using `az storage blob delete` or via portal. Since versioning is enabled, this does not delete data; it creates a delete marker version. The delete marker has a version ID and no content. The current version becomes the delete marker. The previous versions remain intact. If soft delete is also enabled, the delete marker itself can be soft-deleted if you delete it again (e.g., via lifecycle policy).
Restore a Blob from a Previous Version
To restore, you need to promote a non-current version to current. You can do this by copying the version to the blob name. Using CLI: `az storage blob copy start --source-uri <version-uri> --destination-container <container> --destination-blob <blob-name>`. This creates a new current version with the data from the source version. Alternatively, you can delete the delete marker (if present) to make the last non-current version current. Use `az storage blob undelete` for soft-deleted blobs.
Scenario 1: Accidental Deletion of Critical Business Documents
A financial services company stores loan application PDFs in Azure Blob Storage. An administrator accidentally deletes a container containing hundreds of applications. Without any protection, data is gone. With soft delete enabled (retention period set to 30 days), the deleted blobs are recoverable. The administrator uses az storage blob undelete to restore the entire container. However, if versioning is also enabled, the restore is even more granular; they can restore specific versions if some documents were overwritten. Cost consideration: During the 30-day retention, soft-deleted blobs incur storage charges. The company must budget for this, especially if they have large datasets. Misconfiguration: Setting the retention period too short (e.g., 1 day) may not give enough time to detect and recover from deletion.
Scenario 2: Protecting Against Ransomware with Versioning
A healthcare organization stores patient records in Azure Blob Storage. They enable versioning to protect against ransomware that encrypts files and overwrites them. When a ransomware attack occurs, the attacker modifies blobs, creating new versions. The organization can restore the previous unencrypted versions by promoting them. However, the attacker may also delete blobs, creating delete markers. With versioning, the data is not lost; they can delete the delete markers. To prevent the attacker from deleting versions, the organization uses Azure RBAC to restrict write/delete permissions to only authorized users. Performance consideration: Each version consumes storage, so frequent updates can lead to high costs. They implement lifecycle management to delete versions older than 90 days. This scenario is common in exam questions about ransomware protection.
Scenario 3: Compliance and Data Retention
A government agency must retain records for a minimum of 7 years. They use Azure Blob Storage with versioning and soft delete. They set soft delete retention to 365 days (maximum) to allow recovery within a year. For longer retention, they use Azure Backup to take snapshots and store them in a separate vault. They also implement lifecycle management to automatically delete versions older than 7 years. Common pitfall: They initially forgot to enable versioning on the storage account, so overwritten blobs were lost. After enabling, they had to restore from backups. They learned that versioning must be enabled before data is modified to capture versions. Exam tip: The maximum soft delete retention is 365 days; anything beyond requires backup or archive.
What AZ-104 Tests on This Topic
AZ-104 objective 'Configure blob storage' includes sub-objectives on data protection: enabling soft delete, configuring retention periods, enabling versioning, and restoring blobs. Specific codes: 'Manage Azure Blob Storage lifecycle' and 'Implement data protection for Azure Storage'. Questions often present scenarios where you must choose the correct combination of features to protect against accidental deletion, overwrite, or ransomware.
Common Wrong Answers and Why Candidates Choose Them
Enabling versioning to protect against deletion: Candidates think versioning alone prevents deletion. Actually, versioning creates a delete marker; the data is still present but the blob appears deleted. To fully protect against deletion, you need soft delete to allow recovery of the delete marker itself. Versioning protects against overwrite, not deletion.
Setting soft delete retention to 0 days: The minimum is 1 day; setting 0 disables soft delete. Candidates may think 0 means 'no retention' but it actually means disabled.
Assuming versioning can be disabled: Once enabled, versioning cannot be disabled; it can only be suspended. Candidates often think it's reversible.
Confusing soft delete with snapshots: Snapshots are manual and require explicit creation; soft delete is automatic. Candidates may choose snapshots for automatic protection.
Specific Numbers and Terms on the Exam
Default soft delete retention: 7 days.
Maximum retention: 365 days.
Versioning cannot be disabled, only suspended.
Soft delete can be enabled/disabled at any time.
Both features are at the storage account level.
Versioning requires storage account version 2019-07-07 or later.
Edge Cases and Exceptions
Premium block blob accounts: Versioning is not supported. Soft delete is supported.
Hierarchical namespace (Azure Data Lake Storage Gen2): Versioning is not supported. Soft delete is supported for blobs (not directories).
Static website hosting: Versioning and soft delete work with the $web container. Lifecycle policies can target $web.
Immutable storage: Versioning can be used with immutable storage, but immutability policies take precedence. If a blob is protected by a legal hold or time-based retention, it cannot be deleted or overwritten, but versioning still creates new versions if the policy allows modifications.
How to Eliminate Wrong Answers Using Underlying Mechanism
When a question asks how to recover from accidental deletion, look for keywords: 'overwrite' suggests versioning; 'delete' suggests soft delete. If both are needed, the answer is to enable both. If the question mentions 'point-in-time restore', that requires versioning. For ransomware, versioning is key. For accidental deletion by a user, soft delete is sufficient. Always check the retention period: if they need 400 days, soft delete alone won't work; combine with backup or archive.
Default soft delete retention is 7 days; maximum is 365 days.
Versioning cannot be disabled; only suspended.
Soft delete and versioning can be used together for comprehensive protection.
Versioning is not supported on premium block blob or ADLS Gen2 accounts.
Lifecycle management can automatically delete old versions or soft-deleted blobs to manage costs.
To restore a blob after deletion with versioning, delete the delete marker or copy a previous version.
Point-in-time restore requires versioning to be enabled.
Soft-deleted blobs are billed at the same rate as active blobs.
These come up on the exam all the time. Here's how to tell them apart.
Blob Versioning
Automatically creates a new version on each write/delete.
Protects against overwrite (accidental modification).
Creates delete markers on deletion (data remains).
Cannot be disabled; only suspended.
Each version incurs storage costs.
Soft Delete
Preserves deleted blobs in a soft-deleted state.
Protects against accidental deletion.
Requires a retention period (1-365 days).
Can be enabled/disabled at any time.
Soft-deleted blobs incur storage costs until permanently deleted.
Mistake
Blob versioning protects against accidental deletion.
Correct
Versioning protects against overwrite by preserving previous versions. When a blob is deleted with versioning enabled, a delete marker is created, but the data is still present. However, the delete marker itself can be deleted, making the blob unrecoverable without soft delete. To fully protect against deletion, you need soft delete, which allows recovery of delete markers and soft-deleted blobs.
Mistake
Soft delete retention period can be set to 0 to disable it.
Correct
The minimum retention period is 1 day. Setting it to 0 disables soft delete entirely. To disable soft delete, you must set `--enable-delete-retention false`. The retention period value of 0 is not valid.
Mistake
Once versioning is enabled, it can be disabled at any time.
Correct
Versioning cannot be disabled after enabling. You can only suspend it, which stops creating new versions but retains existing ones. To fully disable, you would need to delete the storage account (which requires suspending versioning first) or migrate data to a new account without versioning.
Mistake
Soft delete and versioning are mutually exclusive.
Correct
They are complementary and can be enabled together. When both are enabled, soft delete protects delete markers and versions from premature deletion, while versioning captures historical states. This combination provides the strongest protection.
Mistake
Versioning is supported for all storage account types.
Correct
Versioning is supported only for general-purpose v2 (GPv2) and BlobStorage accounts. It is not supported for general-purpose v1 (GPv1), premium block blob accounts, or accounts with hierarchical namespace (Azure Data Lake Storage Gen2).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
You can enable blob versioning in the Azure portal under your storage account's 'Data protection' settings, or using Azure CLI: `az storage account blob-service-properties update --account-name <storage-account> --enable-versioning true`. It can only be enabled at the storage account level. Once enabled, it applies to all containers and blobs. Remember, versioning cannot be disabled; you can only suspend it.
No. Versioning only captures changes after it is enabled. If a blob was deleted before versioning was enabled, it is permanently deleted unless soft delete was enabled at the time of deletion. To recover such blobs, you would need a backup or point-in-time restore (if available). This is why it's important to enable data protection features proactively.
A blob version is automatically created by Azure when versioning is enabled. It is immutable and has a unique version ID. A snapshot is manually created and can be deleted independently. Versioning provides automatic protection, while snapshots require manual effort. Both incur storage costs. On the exam, versioning is the automatic option; snapshots are manual.
To restore a blob to a previous version, you can either copy the previous version over the current version using `az storage blob copy start` with the version URI, or delete the current version (if it's a delete marker) to make the previous version current. The CLI command `az storage blob undelete` only works for soft-deleted blobs, not for promoting versions.
No. Soft delete only protects against deletion. If a blob is overwritten, the old data is lost unless versioning is enabled. Soft delete does not create a copy of the overwritten data. To protect against overwrites, you need versioning or manual snapshots.
No. Soft delete retention is configured at the storage account level and applies to all blobs in all containers within that account. You cannot have different retention periods per container. If you need different periods, you must use separate storage accounts.
When you disable soft delete, existing soft-deleted blobs remain in the soft-deleted state until their retention period expires. They are not immediately deleted. However, any new deletions after disabling soft delete are permanent. You can still recover existing soft-deleted blobs until their retention expires.
You've just covered Blob Versioning and Soft Delete — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?