Configure Azure Files, Blob Lifecycle, and Recovery Features for AZ-104
Understand containers, file shares, tiers, lifecycle rules, versioning, soft delete, and snapshots for AZ-104 storage administration.
This part of AZ-104 is where storage becomes a retention and recovery problem instead of only an access problem. Microsoft expects you to know how blob containers and Azure file shares behave over time, what features protect against deletion or overwrite, and which setting changes cost or recovery posture without changing the storage account itself.
What Microsoft is explicitly testing
The current study guide groups these tasks under Configure Azure Files and Azure Blob Storage. That includes:
- creating and configuring an Azure Files share
- creating and configuring a blob container
- configuring storage tiers
- configuring soft delete for blobs and containers
- configuring snapshots and soft delete for Azure Files
- configuring blob lifecycle management
- configuring blob versioning
The right mental split
Do not treat every storage feature as “backup.”
| Feature | What it helps with | What it does not replace |
|---|---|---|
| Blob versioning | Recovering earlier blob versions after overwrite or deletion | A full backup or DR design |
| Blob soft delete | Recovering deleted blobs or containers for a retention window | Cross-region resilience |
| Lifecycle management | Cost control and retention automation | Recovery by itself |
| Azure Files snapshots | Point-in-time file-share recovery | Storage-account redundancy |
| Azure Files soft delete | Recovering a deleted file share | A broad business continuity plan |
AZ-104 often rewards the candidate who notices the exact failure mode. Accidental overwrite, accidental deletion, retention control, and disaster recovery are related, but they are not the same admin decision.
Blob Storage versus Azure Files administration
| If the scenario is really about… | Think first about… |
|---|---|
| object data, containers, versioning, lifecycle, immutability, hot/cool/archive movement | Blob Storage |
| shared file paths, SMB or NFS access, file-share recovery, snapshots | Azure Files |
That distinction matters because Microsoft tests blob features and Azure Files features in the same domain, but the operational controls are different.
Blob lifecycle and protection chooser
| Need | Strongest first fit | Why |
|---|---|---|
| Protect against accidental overwrite of blob data | Blob versioning | Keeps prior object versions available |
| Recover deleted blobs or containers within a retention window | Blob soft delete | Directly addresses deletion mistakes |
| Move aging object data to cheaper tiers automatically | Lifecycle management | Time-based policy is stronger than manual cleanup |
| Create a file-share recovery point | Azure Files snapshot | File-share-specific recovery control |
| Recover a deleted file share | Azure Files soft delete | Targets share-level accidental deletion |
Cost and retention decisions appear here too
This section is not purely about recovery. It is also where AZ-104 tests whether you can connect access frequency to cost controls.
| Pattern | Strongest first fit | Why |
|---|---|---|
| Data stays active and latency-sensitive | Hot tier | Best fit for active object access |
| Data is still needed but accessed less often | Cool tier | Lower storage cost with access trade-offs |
| Data is rarely accessed and retention matters more than speed | Archive tier, when the scenario fits | Lowest-cost long-term object retention path |
If the prompt sounds like “old logs,” “rarely accessed files,” or “retention window,” lifecycle management plus the right tier is often the core answer.
Azure CLI example: lifecycle, versioning, and soft delete
This example shows the kind of storage-protection posture AZ-104 expects you to interpret quickly.
1az storage account blob-service-properties update \
2 --account-name stgexamdemo01 \
3 --resource-group app-rg \
4 --enable-versioning true \
5 --enable-delete-retention true \
6 --delete-retention-days 14 \
7 --enable-container-delete-retention true \
8 --container-delete-retention-days 14
What to notice:
- versioning and soft delete solve related but different object-recovery problems
- container delete retention is separate from blob delete retention
- these are blob-service settings, not a substitute for broader backup or regional recovery design
Azure Files admin habits worth practicing
- create one file share and inspect the share-level settings rather than only the storage account
- compare file-share recovery thinking with blob recovery thinking
- know when a question is asking for file-share snapshots instead of blob versioning
Common traps
- calling versioning or soft delete “backup” without checking the actual recovery requirement
- choosing lifecycle rules when the real need is restore capability
- forgetting that blob and Azure Files recovery tools are not identical
- choosing a colder tier without checking whether retrieval expectations still fit
Quiz
Continue into Compute once the storage account, access, and data-protection layers feel distinct instead of blended together.