Lab: Blob recovery, versions, and lifecycle rules

Outcome

Configure a private container, versioning, blob and container soft delete, then recover an overwritten and deleted object. Define a lifecycle rule and explain why a new blob cannot prove a time-based rule immediately.

Before you begin

Use a disposable general-purpose v2 account without hierarchical namespace. Blob versioning is unavailable when hierarchical namespace is enabled. Use a seven-day training retention period only if it fits your organization’s recovery policy; retention has cost and recovery consequences.

Do: protect a container and blob

1. In Data protection, enable blob versioning, blob soft delete, and container soft delete. Record each retention period. In Containers, create recovery-training with private access.
2. Upload plan.txt containing version one. Download it to prove the current version. Overwrite it with version two, then list versions and download the earlier version. Make the earlier version current again using the portal’s version action or an equivalent supported command.
3. Delete plan.txt. List versions or deleted items, restore/undelete the intended version, and verify its contents. Delete recovery-training, restore the deleted container before its retention expires, and verify its blob list.

Do: define, inspect, and reason about lifecycle

1. Create a lifecycle-management rule that applies only to the lifecycle-training/ prefix. Use a JSON policy rule with blobTypes: ["blockBlob"]; choose an age threshold appropriate for the account policy. If you include deletion of current blobs, include a separate action for previous versions or snapshots where those prevent current-version deletion.
2. Upload lifecycle-training/keep.txt and outside-rule.txt. In the portal, inspect the saved policy, enabled state, prefix filter, actions, and the blobs that match or do not match.
3. Do not claim a newly uploaded blob has proved an age rule. Lifecycle conditions are time-based and processing is asynchronous. Record the calculated eligibility date and use policy inspection plus matching metadata as the immediate evidence. Observe a completed transition only in a long-lived, noncritical training account with an approved short threshold.

Verify

Capture the private access level, three data-protection settings, version list, restored contents, deleted-container restoration, lifecycle JSON/rule view, prefix match, and eligibility calculation. You should now understand: versioning preserves prior object states; soft delete gives a retention window for deletion recovery; lifecycle policies control later tiering or deletion and are not an instant command.

Break and fix

1. Try to recover a blob after deleting it with protection disabled in a separate empty test account. Stop before using valuable data; explain why that deletion is permanent and enable the required protections before storing training data.
2. Make recovery-training public by mistake, verify the access-level warning/state, return it to private, and retest anonymous access.
3. Set a lifecycle prefix that does not match lifecycle-training/keep.txt. Diagnose the mismatch from the saved JSON and blob name, correct the prefix, and re-inspect the match.

Scenario practice

1. Configure: An application overwrites daily reports and needs 30 days of rollback. Select versioning, soft delete, lifecycle treatment of old versions, and container access level.
2. Diagnose: A lifecycle deletion rule has not moved a blob uploaded today. Which age field, prefix/tag filter, eligibility time, and asynchronous processing facts do you check?
3. Distinguish: Contrast a prior version, a soft-deleted blob, a soft-deleted container, and a backup against account deletion or ransomware.

Clean up

Delete the lifecycle policy, then permanently remove only the disposable container/account after confirming no retained data is needed. Delete the resource group if it contains no shared training resources.

Sources and re-audit

• Soft delete for blobs, checked 2026-08-22.
• Lifecycle management overview, checked 2026-08-22.
• Lifecycle policy structure, checked 2026-08-22.

Re-audit when versioning support, data-protection behavior, lifecycle actions, or retention controls change.

Related

blob-storage · blob-versioning · access-tier · storage-account · All labs