Configure Storage Access, Private Connectivity, and Data Protection for AZ-104
Understand SAS, keys, storage firewalls, Azure Files access, blob lifecycle settings, versioning, and soft-delete behavior for AZ-104.
This objective area is where AZ-104 turns storage into a real operations problem. The question is not only whether data exists. It is whether the right clients can reach it, whether access can be limited safely, and whether accidental deletion or age-based sprawl is already under control.
What you need to recognize fast
Microsoft expects you to configure storage firewalls and virtual networks, create and use SAS tokens, configure stored access policies, manage access keys, and configure identity-based access for Azure Files. It also expects you to work with blob containers, file shares, storage tiers, versioning, lifecycle rules, and soft-delete features for both blobs and Azure Files.
The admin judgment behind those tasks
Use the narrowest access mechanism that still fits the client. A SAS is often safer than exposing account keys broadly. Private endpoints provide the strongest private-access model for many PaaS scenarios, but they usually require private DNS work. Service endpoints are lighter but keep the service on a public endpoint. Soft delete, snapshots, versioning, and lifecycle rules all protect data in different ways, so choose the feature that matches the failure mode you care about.
Blob storage versus Azure Files
AZ-104 often groups these services together under storage administration, but the access patterns are not interchangeable.
| Service | Administrative focus | Common exam distinction |
|---|---|---|
| Blob Storage | Containers, object access, tiers, lifecycle, versioning, immutability, SAS | Usually tests data-plane controls and retention behavior |
| Azure Files | File shares, SMB or NFS access, identity-based access, backup and snapshots | Often tests share access models and file-service administration rather than object access |
If the question sounds like application object storage, think blob first. If it sounds like a file share replacement or shared file path, think Azure Files first.
Common traps
The classic misses are overusing account keys, forgetting that private endpoints require name resolution to line up, and assuming lifecycle management or versioning behaves like a full backup strategy. Another trap is treating Azure Files and Blob Storage as interchangeable when their access and admin models differ.
Lab moves worth practicing
- create a SAS and compare it with key-based access
- restrict storage access by network and verify the resulting path
- enable versioning, soft delete, and a lifecycle rule, then observe how each feature behaves
Access and protection chooser
| Need | Strongest first choice | Why |
|---|---|---|
| Delegate narrow temporary access to storage data | SAS | Limits scope and duration better than sharing account keys |
| Allow trusted VNet-based access while keeping the service on its public endpoint | Service endpoint | Lightweight network restriction pattern |
| Put the service behind a private IP in your VNet | Private endpoint | Stronger private-access model for many PaaS data paths |
| Recover from accidental deletion or overwrite in blob workflows | Versioning and soft delete | Protects common operator mistakes |
| Age data down automatically | Lifecycle rules | Moves or deletes data by policy rather than manual cleanup |
Private-access troubleshooting order
When a storage workload stops working after you tighten network access, check these in order:
- Confirm whether the design uses a service endpoint or a private endpoint. Those imply different data paths.
- Check name resolution. Private endpoints often fail because the client still resolves the public name and not the
privatelinkpath. - Only then move on to firewall rules, NSGs, route behavior, or client credentials.
Quiz
Continue into Compute once storage access patterns feel natural.