Technical Lab: Configure soft delete for blobs and containers
Questions
Question 1 — Multiple Choice
An operations team enabled soft delete for blobs in a storage account with a retention period of 7 days. A developer executed the following command:
az storage blob delete \
--account-name mystorageacct \
--container-name dados \
--name relatorio.csv
Two days later, the developer realized they deleted the wrong file. Which statement correctly describes the blob's state and the necessary action to recover it?
A. The blob was permanently removed because the az storage blob delete command ignores the soft delete enabled on the account.
B. The blob is in a soft-deleted state and can be recovered with an undelete operation within the remaining retention period.
C. The blob is in a soft-deleted state, but can only be recovered through the Azure portal, not via CLI.
D. The blob is in a soft-deleted state and will be automatically recovered at the end of the 7-day retention period.
Question 2 — Technical Scenario
An administrator needs to ensure that when deleting an entire container, the blobs inside it are also protected against accidental deletion. He enables only soft delete for blobs with 14-day retention.
az storage blob service-properties delete-policy update \
--account-name mystorageacct \
--enable true \
--days-retained 14
During a test, he deletes the container via portal and verifies that he cannot recover it. What is the root cause of the problem?
A. The command was executed incorrectly; the --days-retained parameter should be --retention-days.
B. Soft delete for blobs does not protect containers; it's necessary to separately enable soft delete for containers.
C. Soft delete for blobs protects files individually, but the container is only protected if blob versioning is enabled.
D. Containers can only be protected with resource locks at the Azure Resource Manager level, not with soft delete.
Question 3 — True or False
When soft delete for containers is enabled and a container is deleted, the blobs that were inside it are automatically preserved and remain accessible via normal read operations during the retention period.
Question 4 — Multiple Choice
A storage account has the following active configurations:
| Resource | State | Retention |
|---|---|---|
| Soft delete for blobs | Enabled | 7 days |
| Soft delete for containers | Enabled | 30 days |
| Blob versioning | Disabled | N/A |
A user overwrites an existing blob by uploading a file with the same name. After 3 days, they realize the previous version was needed. What happens in this scenario?
A. Soft delete for blobs automatically preserves the previous content from the upload, allowing recovery via undelete.
B. Soft delete for containers protects the overwritten blob because it monitors changes at the container level.
C. The previous content is permanently lost because soft delete protects against deletion, not overwriting.
D. The overwritten blob can be recovered because soft delete captures all data mutations by default.
Question 5 — Technical Scenario
A company configured soft delete for blobs with 10-day retention. An analyst executes the following script to list all blobs in a container, but doesn't see recently deleted blobs:
az storage blob list \
--account-name mystorageacct \
--container-name arquivos \
--output table
The analyst needs to confirm if the blobs are still within the retention period. Which adjustment to the command solves the problem?
A. Add --include-deleted to the command to include blobs in soft-deleted state in the listing.
B. Use az storage blob restore with the blob name to verify if it still exists.
C. Query the storage account diagnostic logs, as soft-deleted blobs don't appear in listing commands.
D. Add the --show-deleted-blobs true parameter to the original command.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
When soft delete for blobs is enabled, any deletion operation, including those performed via CLI, portal, or SDK, does not remove the data immediately. The blob transitions to the soft-deleted state and remains recoverable for the configured retention period. The undelete operation can be performed via CLI with az storage blob undelete, via portal, or via SDK, without channel restrictions.
The main misconception represented by the distractors is assuming that CLI bypasses the soft delete policy (alternative A) or that recovery requires a specific interface (alternative C). Alternative D reverses the logic: the system doesn't automatically recover; recovery is always an explicit operator action.
Answer Key — Question 2
Answer: B
Soft delete for blobs and soft delete for containers are independent features in Azure Blob Storage. Enabling one does not imply enabling the other. When only soft delete for blobs is active, deleting a container results in the definitive removal of the container and all its content, regardless of the protection state of individual blobs.
Alternative C describes incorrect behavior: blob versioning is a separate feature and doesn't interfere with container protection via soft delete. Alternative D is wrong because resource locks operate at the Azure Resource Manager level and prevent deletion of the storage account resource as a whole, not individual containers within it.
Answer Key — Question 3
Answer: False
When a container is deleted with soft delete enabled, it transitions to the soft-deleted state along with all its content. The blobs inside the container are not accessible via normal read operations during the retention period. To access or recover the data, it's necessary to first restore the container with the undelete operation. Only after restoration do the container and its blobs return to the active and accessible state.
Confusing "preserved" with "accessible" is the central error here. The data is retained and protected, but remains inaccessible until restoration is explicitly executed.
Answer Key — Question 4
Answer: C
Soft delete for blobs protects against deletion operations, not overwriting. When a blob is replaced by uploading a file with the same name, the previous content is simply replaced and soft delete doesn't record or preserve the previous state. To protect content against overwriting, the correct feature is blob versioning, which was disabled in the scenario.
Alternatives A and D represent the most common misconception: assuming that soft delete has broader scope than it actually possesses. Alternative B attributes to container soft delete a mutation monitoring capability that doesn't exist in this feature.
Answer Key — Question 5
Answer: A
By default, the az storage blob list command doesn't display blobs in soft-deleted state. To include them in the listing, it's necessary to add the --include-deleted parameter. This allows viewing blobs with deleted status and verifying if they're still within the retention period through the expiration field returned.
Alternative D describes a non-existent parameter in Azure CLI, being a distractor based on intuitive but incorrect nomenclature. Alternative C is wrong because soft-deleted blobs are visible via CLI as long as the correct parameter is used; there's no need to resort to diagnostic logs for this purpose. Alternative B confuses listing with restoration, which are distinct operations.