Configure Storage Access, SAS, and Private Connectivity for AZ-104
Understand SAS, stored access policies, keys, storage firewalls, Azure Files identity-based access, and private connectivity for AZ-104.
This objective area is where AZ-104 turns storage into a real access-control and network-path problem. The question is not just whether data exists. It is whether the right clients can reach it, whether delegated access is scoped safely, and whether the network path matches the security requirement.
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.
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.
Blob storage versus Azure Files access
AZ-104 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, firewalls, SAS, private endpoints | Usually tests delegated object access and network restriction behavior |
| Azure Files | File shares, SMB or NFS access, identity-based access, private connectivity | 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 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 a private endpoint and verify the resulting DNS behavior
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 |
| Let file-share access follow identity rather than shared keys | Azure Files identity-based access | Better fit when file access must align to user or group identity |
Access delegation tools you should not mix up
| Tool | Best use | Common mistake |
|---|---|---|
| Account key | Full account-level access when key-based auth is explicitly required | Treating it as the default for routine delegated access |
| SAS token | Narrow, time-bound delegated access to storage data | Forgetting that a loose SAS can still be too broad |
| Stored access policy | Central control over SAS constraints on supported storage objects | Assuming it is the same thing as the SAS token itself |
| Azure Files identity-based access | File-share access tied to identity instead of shared keys only | Treating Azure Files authorization exactly like blob SAS authorization |
Identity-based access for Azure Files deserves its own mental slot
Blob access questions often revolve around SAS and data-plane tokens. Azure Files can also bring identity-based access into the story, especially when the workload behaves more like a traditional file share than an object store.
If the prompt sounds like:
- shared folders
- SMB access
- user or group access management
- file-share permissions instead of object URLs
then Azure Files identity-based access may be the real answer layer, not just a generic storage firewall.
Azure CLI and AzCopy example
This example covers three objective areas at once: container creation, key awareness, and data movement tooling.
1# Create a blob container by using Microsoft Entra authentication
2az storage container create \
3 --account-name stgexamdemo01 \
4 --name appdata \
5 --auth-mode login
6
7# Review account keys only when the scenario explicitly depends on key-based access or rotation
8az storage account keys list \
9 --resource-group app-rg \
10 --account-name stgexamdemo01
11
12# Move data by using AzCopy and a scoped SAS
13azcopy copy ./seed-data "https://stgexamdemo01.blob.core.windows.net/appdata?<sas-token>" --recursive=true
What to notice:
- container creation is a management step, not the same thing as granting delegated access
- account keys are powerful and should not be your default sharing model
- AzCopy is specifically in scope for the study guide because administrators often need a fast operational data-movement tool
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.
That order also helps with Azure Files. If the share is expected to resolve and travel privately but the name still points to the public path, the storage problem usually starts in DNS rather than in share configuration.
Quiz
Next, move to 2.3 Azure Files, Blob Lifecycle & Recovery to separate network-access decisions from the blob and file-share data-protection features Microsoft also tests.