Configure Storage Access, Private Connectivity, and Data Protection 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.

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

Access delegation tools you should not mix up

Blob and file-share tasks that map directly to the objective list

• create a blob container when the scenario is about object storage layout, lifecycle, versioning, or tiering
• create an Azure Files share when the scenario is about SMB or NFS access, shared file paths, or identity-based file access
• use storage tiers for cost and access-frequency decisions, not as a backup substitute
• use blob soft delete, versioning, and lifecycle management for object-data protection and retention behavior
• use Azure Files snapshots and soft delete when the recovery requirement is tied to file-share workflows

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:

1. Confirm whether the design uses a service endpoint or a private endpoint. Those imply different data paths.
2. Check name resolution. Private endpoints often fail because the client still resolves the public name and not the privatelink path.
3. 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

Continue into Compute once storage access patterns feel natural.