Describe core data concepts →mediumMultiple ChoiceObjective-mapped

DP-900 Describe core data concepts Practice Question

Exhibit

{
  "name": "sales",
  "location": "eastus",
  "properties": {
    "isVersioningEnabled": true,
    "publicNetworkAccess": "Enabled",
    "storageAccount": "/subscriptions/.../storageAccounts/salesdatalake",
    "containerSoftDeleteDurationInDays": 7
  },
  "resourceType": "Microsoft.Storage/storageAccounts/blobServices/containers"
}

Refer to the exhibit. You are reviewing an Azure Resource Manager template for a Blob Storage container named 'sales'. The container has versioning enabled. A developer accidentally overwrites a blob. What is the simplest way to recover the previous version?

⚠ Common exam trap

Candidates often confuse versioning with soft delete, assuming soft delete can recover overwrites, but soft delete only protects against deletions, not modifications.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Access the previous version through the version list and restore it

Azure Blob Storage versioning automatically maintains a history of blob versions. When a blob is overwritten, the previous version is preserved and can be accessed via the version list. The simplest recovery method is to promote the previous version to the current version, which restores the blob to its prior state without needing additional services or configurations.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Access the previous version through the version list and restore it
Why this is correct
Azure Blob Storage versioning automatically creates a new version each time a blob is written, overwritten, or deleted. To recover the overwritten blob, open the container, select the blob, go to its Version list, locate the previous version you want, and promote it by copying it over the current version or by using the "Restore version" action. This self-service, metadata-driven operation requires no external backup product and preserves all other versions, including the current one, for auditability.
✗
Use blob soft delete to recover the blob
Why it's wrong here
Blob soft delete is designed to protect against accidental deletion, not overwrite operations. When a blob is overwritten in place, the blob still exists in the container—it has not been deleted—so it never enters the soft-deleted state and soft delete retains nothing to restore. Recovering an overwritten blob requires blob versioning (or a point-in-time restore), whereas soft delete alone can only bring back blobs that were actually deleted within the retention period.
✗
Restore from a backup using Azure Backup
Why it's wrong here
Azure Backup is not the correct recovery mechanism in this scenario. The VM backup and Azure Files backup offerings protect entire virtual machines or file shares, not individual blobs inside a storage container, so they have no visibility into a single overwritten blob. Even the operational backup for Azure Blobs is built on top of versioning and point-in-time restore, meaning you would still need versioning already enabled and would be restoring a broader scope than necessary. Directly promoting the previous blob version from the Version list is faster, requires no backup vault, and affects only the single blob that was overwritten.
✗
Perform a point-in-time restore of the container
Why it's wrong here
Point-in-time restore operates at the storage account level to revert all blobs in a container to a prior state from a defined backup window, but the scenario requires recovering only a single overwritten blob in a container that already has versioning enabled. The correct mechanism is to promote the previous blob version directly, which avoids restoring the entire container. This option is tempting because point-in-time restore is the standard recovery method for accidental bulk deletion or corruption across a container, where versioning alone would be insufficient.

Quick reference

Azure Blob Storage Tier Comparison

Tier	Storage Cost	Retrieval Cost	Latency	Use Case
Hot	Highest	Lowest	Immediate	Active data, frequent reads
Cool	Lower	Higher	Immediate	Data accessed < once / month
Cold	Lower still	Higher	Immediate	Data accessed < once / quarter
Archive	Lowest	Highest + rehydration delay	Hours	Long-term compliance retention

Go deeper

DP-900 Describe core data concepts Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Azure Blob Storage Tier Comparison

Related to this question