Troubleshooting Lab: Configure soft delete for blobs and containers
Diagnostic Scenarios
Scenario 1 — Root Cause
A data team reported that a critical blob was accidentally deleted by an automated script in the early morning. The administrator confirms that soft delete for blobs is enabled on the storage account with 15 days retention. The storage account also has blob versioning enabled and uses the Cool access tier.
The administrator runs the following command to try to recover the file:
az storage blob undelete \
--account-name prodstorageacct \
--container-name datasets \
--name pipeline-output.parquet
The output returns without error, but when listing the container's blobs, the file doesn't appear:
az storage blob list \
--account-name prodstorageacct \
--container-name datasets \
--output table
Name Blob Type Blob Tier Length Content Type
---------------------- ----------- ----------- -------- ------------
archive-2024.parquet BlockBlob Cool 4823901 application/octet-stream
The administrator checks in the Azure portal and confirms that soft delete for blobs is active. The account's lifecycle management policy has no configured rules for the datasets container.
What is the root cause of the file's absence after the undelete operation?
A. The undelete command was successful, but the blob is in the Cool tier and requires rehydration before appearing in the listing.
B. The file was deleted longer ago than the configured retention period, so it no longer exists in the soft-deleted state.
C. The az storage blob list command doesn't display restored blobs by default; the --include-deleted parameter is required.
D. Blob versioning is interfering with the undelete operation, requiring the restoration to be done by specific version.
Scenario 2 — Action Decision
The cause of the problem has been identified: soft delete for containers was not enabled on a production storage account. A container called relatorios-fiscais was accidentally deleted by a team member with Contributor access. The storage account has soft delete for blobs enabled with 30 days retention, but the container and all its content cannot be recovered.
The administrator needs to act. The following restrictions apply:
- The storage account is in production and other active containers depend on it
- There is a backup of the container in a secondary storage account with data from 48 hours ago
- The compliance team requires the recovery to use the most recent available data
- The administrator has Owner access on the subscription
What is the correct action to take at this moment?
A. Delete and recreate the entire storage account from a Resource Manager snapshot to ensure restoration integrity.
B. Immediately enable soft delete for containers on the current storage account and wait for Azure to automatically recover the container.
C. Restore the backup content from the secondary storage account to a new container in the production storage account and then enable soft delete for containers to prevent recurrence.
D. Apply a CanNotDelete resource lock on the storage account and open a support ticket for Microsoft to restore the deleted container.
Scenario 3 — Root Cause
An administrator receives the following alert in the Azure portal: a container called logs-app was deleted. They verify that soft delete for containers is enabled with 7 days retention and try to recover the container via portal. The container appears in the deleted containers listing, but when clicking "Undelete", the operation fails with the following message:
ContainerAlreadyExists: The specified container already exists.
The administrator checks the current state of the storage account and finds the following:
az storage container list \
--account-name appstorageacct \
--output table
Name Lease Status Public Access
------------ -------------- -------------
logs-app unlocked None
backups unlocked None
configs unlocked None
The storage account was migrated to the Brazil South region 3 weeks ago. Soft delete for blobs is disabled on this account.
What is the root cause of the container undelete operation failure?
A. The region migration caused inconsistency in soft delete metadata, corrupting the deleted container record.
B. Soft delete for blobs needs to be enabled for container undelete operations to work correctly.
C. A container with the same name already exists in the storage account in active state, preventing restoration of the soft-deleted container.
D. The 7-day retention period is insufficient for the Brazil South region; the minimum required is 14 days for undelete operations.
Scenario 4 — Diagnostic Sequence
An administrator is notified that blobs in a storage account are disappearing without any team member having performed manual deletions. Soft delete for blobs is enabled with 10 days retention. The blobs don't appear even in the listing with --include-deleted.
The following investigation steps are available, but out of order:
- Check if there is a lifecycle management policy configured on the storage account with delete rules
- Check Azure Monitor diagnostic logs to identify which identity executed the deletion operation
- Confirm that soft delete for blobs is enabled and what is the current retention period via portal or CLI
- Check if the disappeared blobs still exist with
az storage blob list --include-deleted - Review RBAC permissions assigned to service principals and managed identities with access to the storage account
What is the correct investigation sequence?
A. 3 → 4 → 2 → 1 → 5
B. 4 → 3 → 1 → 2 → 5
C. 3 → 4 → 1 → 2 → 5
D. 1 → 3 → 4 → 5 → 2
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The undelete operation returned without error, which means Azure processed the command, but found no soft-deleted blob with that name to restore. When there is no recoverable object, the command doesn't fail with an exception; it simply has no effect. This indicates that the file was deleted more than 15 days ago, exceeding the retention period, and was permanently removed before the team noticed the problem.
The central clue in the statement is the absence of any error in the undelete operation combined with the absence of the file. If the object existed in the soft-deleted state, it would appear after undelete.
The information about the Cool tier and blob versioning are irrelevant details for this diagnosis. The access tier doesn't affect blob visibility in the listing. Versioning doesn't interfere with the undelete operation of non-versioned blobs.
Alternative C represents the most dangerous reasoning error: the --include-deleted parameter is used to list blobs still in the soft-deleted state, not to list already restored blobs. Acting based on this hypothesis would lead the administrator to continue searching for an object that simply no longer exists.
Answer Key — Scenario 2
Answer: C
Given that the container was permanently lost and the most recent available data is in the 48-hour-old backup, the only action that meets all restrictions is to restore from the backup to a new container in the production account and then fix the configuration gap by enabling soft delete for containers.
Alternative B represents the most common misconception in this type of scenario: enabling soft delete after deletion has no retroactive effect. Azure doesn't recover data deleted before the policy was enabled. This is the most dangerous consequence of choosing this alternative, as the administrator would lose time waiting for a recovery that will never occur.
Alternative A is technically destructive and unnecessary: recreating the entire storage account would impact all other active containers that depend on it. Alternative D is unfeasible because Microsoft doesn't offer data recovery service for deleted data without prior protection; resource locks prevent future deletions, they don't restore already lost data.
Answer Key — Scenario 3
Answer: C
The ContainerAlreadyExists error message is straightforward: Azure is trying to restore a container named logs-app, but an active container with that name already exists in the same storage account. The container listing explicitly confirms this. Soft delete cannot create a container with a duplicate name over an existing active container.
The information about the migration to the Brazil South region 3 weeks ago is an irrelevant detail purposely inserted to divert reasoning. Region migrations don't cause inconsistencies in soft delete metadata.
Alternative B represents a classic conceptual error: soft delete for blobs and soft delete for containers are independent functionalities. The absence of one doesn't block the operation of the other. Alternative D is a distractor based on fictional regional restrictions that don't exist on the Azure platform.
The correct step after identifying the cause is to rename or delete the conflicting active container before executing the undelete operation, or accept that the active container has already been manually recreated and it's not necessary to restore the soft-deleted one.
Answer Key — Scenario 4
Answer: C
The correct sequence is 3 → 4 → 1 → 2 → 5.
The correct diagnostic reasoning starts by validating assumptions before investigating external causes. Step 3 confirms if soft delete is actually active and with the expected retention period, eliminating the possibility of misconfiguration. Step 4 checks if the blobs exist in the soft-deleted state or were permanently removed, which defines the next path. Step 1 is next because the absence of blobs even in the listing with --include-deleted strongly suggests that something is deleting and expiring them before the retention window, which points to lifecycle management. Step 2 uses diagnostic logs to identify the identity responsible for the deletions. Step 5 closes the cycle by reviewing permissions of identities that could be executing automated deletions.
Alternative A inverts steps 3 and 4, starting by confirming configuration before observing the object state, which is less efficient since the blob state already provides immediate diagnostic information. Alternative D starts with lifecycle management without first confirming configuration assumptions, skipping the initial validation that can reveal the cause more quickly.
Troubleshooting Tree: Configure soft delete for blobs and containers
Legend:
| Color | Node Type |
|---|---|
| Dark blue | Initial symptom or entry point |
| Medium blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Validation or intermediate verification |
To use this tree when facing a real problem, start with the root node that describes the observed symptom and answer each diagnostic question based on what you can directly verify in the environment. Follow the path that corresponds to the actual observed state, without skipping steps. Red nodes indicate that the cause has been isolated; green nodes indicate there's a concrete action to execute. If you reach an orange node, perform the indicated verification before continuing. The goal is to reach a cause or resolution node by the shortest valid path, discarding hypotheses at each branch based on observable evidence.