Microsoft AZ-104 Azure Administrator Deep Dive: Azure storage — From Fundamentals to Exam Scenarios

 

Azure storage questions become much easier when you separate four decisions that are often mixed together: how data is authorized, how the request reaches the service, how the data is protected against failure or deletion, and how the data should behave over time. Account keys, shared access signatures, identity-based access, storage firewalls, private endpoints, redundancy, soft delete, versioning, lifecycle management, and storage tiers all belong to that broader model, but they solve different problems.

The current AZ-104 storage domain accounts for 15–20 percent of the April 17, 2026 skills outline. Microsoft specifically expects candidates to configure storage access, use SAS tokens and stored access policies, manage keys, configure identity-based access for Azure Files, choose redundancy, understand object replication and encryption, work with Storage Explorer and AzCopy, and manage Azure Files and Blob Storage features such as tiers, soft delete, snapshots, lifecycle rules, and versioning.

The practical skill is to reason from the requirement instead of from the feature name. “Give a vendor upload access for two hours” is an authorization problem. “Keep the service off the public network path” is a connectivity problem. “Recover a blob after accidental overwrite” is a data-protection problem. “Move old objects to a lower-cost tier” is a lifecycle problem. The storage security practice and storage resilience practice are useful only after those distinctions are understood.

Build storage decisions in the right order

A storage scenario becomes easier if you process it in a fixed sequence.

1. Identify the data service. Is the requirement about object data in Blob Storage, file semantics in Azure Files, or the storage account as the administrative boundary?
2. Choose the authorization model. Does the caller need identity-based access, a constrained SAS, or a broad account credential? What is the narrowest acceptable permission and duration?
3. Define the network path. Is public network access acceptable? Should selected VNets reach the public service endpoint, or does the workload require a private IP through Private Link?
4. Choose the durability and recovery features. Is the concern hardware failure, zone failure, regional failure, accidental deletion, overwrite, or point-in-time recovery?
5. Define lifecycle behavior. Should objects change tier, expire, retain prior versions, or be protected by soft delete?
6. Validate with the right tool. Storage Explorer, AzCopy, the Azure portal, logs, and application tests answer different operational questions.

This sequence prevents a common mistake: changing authorization when the request cannot reach the service, or changing networking when the real failure is a missing data-plane role. It also keeps redundancy separate from backup-like recovery features. Replication improves resilience against infrastructure failures; soft delete and versioning address different data-loss scenarios.

Authorization: management plane versus data plane

Start with the storage account as the administrative boundary

A storage account is the foundation for several Azure storage services and settings. It has properties related to redundancy, security, networking, encryption, and service behavior. Before studying individual blob or file features, make sure you can reason about what belongs at the account level and what belongs at the service, container, share, or object level.

Create a storage account in a lab and inspect its properties before changing anything. Identify the account type, performance choices, redundancy setting, network access configuration, encryption options, and the services available. Then ask what would happen if a requirement changed. If a workload needs private network access, where do you configure that? If the organization changes its redundancy requirement, which setting is relevant? If a user needs temporary object access, should you share an account key?

This habit prevents a common exam problem: selecting an answer that affects the right service but at the wrong control point.

Separate management access from data access

One of the most important storage concepts is the distinction between managing the Azure resource and accessing the data stored inside it. A principal may be allowed to modify a storage account’s Azure settings without automatically having permission to read blob contents. Conversely, a principal may receive data access without broad management rights.

When a scenario says, “The user can see the storage account but cannot read the blobs,” do not assume the user needs Contributor at a broader scope. Determine whether the missing permission is a data-plane authorization issue. When a scenario says, “The user can read data but cannot change the storage firewall,” the missing permission is likely in the management plane.

This is where the identity concepts from the Entra governance become directly relevant. Azure storage is not a separate universe; its access model depends on identity, role scope, and service-specific authorization choices.

Understand account keys as broad credentials

Storage account access keys are powerful credentials. They can authorize broad access to an account and therefore require careful protection and rotation. In exam scenarios, account keys are often a deliberately broad option compared with more constrained authorization methods.

If an application or administrator receives an account key, ask whether that level of access is actually necessary. Could Microsoft Entra-based authorization provide identity-specific access? Could a shared access signature provide temporary, limited permissions? The principle of least privilege applies to credentials as well as RBAC roles.

Practice rotating keys in a lab and think about the operational consequence. Applications that depend on the old key may fail unless the rotation process is coordinated. A strong administrator treats key rotation as an application-dependency problem, not just a button click.

Use shared access signatures as constrained delegated access

A shared access signature, or SAS, can grant limited access to storage resources without handing out the account key. The important scenario dimensions are resource scope, allowed permissions, start and expiry time, and other restrictions relevant to the SAS type.

Suppose an external process must upload files to one container for two hours. A broadly shared account key would exceed the requirement. A carefully scoped SAS can be a better fit because access can be restricted by time and permission. If the process only needs to write, the token should not automatically grant unrelated delete or account-management capabilities.

When studying SAS, avoid memorizing token fields without context. Build scenarios: read-only access to one container, temporary upload permission, access that should be revoked through a stored access policy where applicable, or a token that expired unexpectedly. The storage security practice is useful after you can reason through these constraints.

Stored access policies add management to some SAS scenarios

Stored access policies can provide an additional management layer for supported SAS scenarios by associating permissions and time constraints with a named policy. This can make it easier to change or revoke access represented by service-level SAS tokens tied to that policy.

For AZ-104, focus on the administrative purpose rather than obscure syntax. Ask why a team might prefer a controllable policy relationship over issuing many long-lived independent tokens. Then practice identifying when the scenario actually calls for a SAS and when identity-based access would be more appropriate.

Identity-based access is often the preferred long-term model

Microsoft Entra-based authorization can allow Azure identities to access storage according to assigned roles, reducing reliance on shared secrets. The current AZ-104 objectives specifically include identity-based access for Azure Files, and identity concepts are important across storage services.

The practical advantage is accountability and lifecycle management. Access can follow a user, group, or workload identity and be changed through role assignments rather than distributing a shared secret. This aligns well with least privilege and centralized identity governance.

In a lab, assign a storage-related data role at a controlled scope and verify the difference between data access and management access. Remove the assignment and confirm the behavior changes. Then compare the experience with an account-key or SAS-based access path.

Network access to storage

Storage firewalls and virtual network restrictions control the network path

Authorization answers whether a principal is allowed to access data. Network controls answer whether the request can reach the service through an allowed path. Both can be correct or incorrect independently.

A storage account can restrict public network access or limit access based on network configuration. When troubleshooting, confirm the network path before changing identity permissions. A user can have the right role and still fail because the service rejects the source network. Likewise, a network can be permitted while the principal lacks authorization.

Build a scenario where storage works from one subnet but not another. Inspect the account’s networking configuration. Add or remove a permitted network path and retest. What matters is to learn the symptom of a network restriction rather than simply recognizing the setting name.

Service endpoints and private endpoints solve different connectivity problems

Storage often appears in networking scenarios because Azure provides multiple ways to control how workloads reach PaaS services. Service endpoints and private endpoints are not interchangeable.

A service endpoint extends the identity of a virtual network subnet to a supported Azure service while traffic still targets the service’s public endpoint architecture. A private endpoint gives a service a private IP address in a virtual network through a network interface associated with the private-link connection. The DNS design becomes especially important with private endpoints because the service name must resolve appropriately for clients using the private path.

For exam preparation, focus on requirement language. “Access using a private IP from the VNet” points toward private endpoint concepts. “Restrict service access to selected virtual network subnets” may involve service endpoints and service firewall configuration. Always evaluate DNS and authorization separately from connectivity.

The networking guide is a natural companion when storage networking remains confusing.

Resilience, replication, and encryption

Choose redundancy by failure requirement, not by acronym

Azure Storage redundancy options are often reduced to names such as LRS, ZRS, GRS, and related variants. That is not enough for scenario questions. You need to understand the failure boundary each option is designed to address and how geo-replication changes the resilience model.

Locally redundant storage keeps multiple copies within a single datacenter in a region. Zone-redundant storage distributes data across availability zones in a supported region, helping tolerate a zonal failure. Geo-redundant designs replicate to a secondary region as well, with variations in how zone redundancy or read access is incorporated.

The key question is: what must the workload survive? If the requirement specifically mentions a datacenter or zone failure within a region, choose an option aligned with zone resilience. If the requirement includes regional disaster resilience, geo-redundancy becomes relevant. More redundancy can mean different cost, replication, and recovery characteristics, so do not assume “highest redundancy” is automatically the best answer.

Use the storage resilience practice after you can explain the failure model in your own words.

Object replication addresses a different use case than account redundancy

Object replication can replicate block blobs between storage accounts according to configured rules. It should not be mentally collapsed into the storage account’s built-in redundancy setting.

Redundancy is a property of how Azure protects the storage account’s data within the platform’s replication model. Object replication is an administrative feature that can copy eligible blob data between source and destination accounts for scenarios such as distributing data or creating additional copies according to application needs.

When a question mentions cross-account blob replication rules, source and destination accounts, or object-level replication policy, do not answer with a change to the account’s LRS/ZRS/GRS setting. Identify which replication mechanism the requirement actually describes.

Understand storage encryption at the administrative level

Azure Storage encrypts data at rest, and the exam can test configuration-related aspects of storage encryption. The important administrative skill is recognizing encryption as a distinct control from network isolation and authorization.

A storage account can be private on the network and still need appropriate encryption configuration. A user can have correct RBAC and still not determine the encryption model. Do not treat “secure storage” as one setting; security is layered.

For study, know where encryption is configured, how key-management choices can affect operations, and how an organization might require a particular encryption posture through governance. Avoid getting lost in cryptographic theory that is outside the administrator-level objective.

Operational data movement tools

Use Storage Explorer and AzCopy as operational tools

The AZ-104 objectives include managing data with Azure Storage Explorer and AzCopy. These tools matter because an administrator often needs to inspect, transfer, or manage storage data outside the portal’s basic experience.

Practice connecting Storage Explorer using an appropriate authorization method, browsing containers or file shares, uploading and downloading test objects, and confirming the effect of access restrictions. Use AzCopy for a simple copy operation and observe how source, destination, and authentication are represented.

You do not need to memorize every command-line switch. You should recognize which tool fits an interactive management task versus a scripted or high-throughput data transfer and understand the authentication dependency.

Azure Files and Blob Storage lifecycle

Azure Files is a managed file-share service

Azure Files provides managed file shares accessible through supported protocols and identity or credential models depending on configuration. In AZ-104, the current blueprint includes creating and configuring a file share, identity-based access, snapshots, and soft delete.

Think of a file share as a hierarchical file-system experience rather than blob object storage. That distinction affects how applications access data and how administrators think about permissions, snapshots, and migration.

Create a small share, upload files, configure a quota if relevant to your study environment, and take a snapshot. Delete or change a file and reason about how the snapshot or soft-delete configuration affects recovery. The Files and Blob practice can reinforce the service differences.

Blob Storage organizes object data into containers

Blob Storage is designed for object data. Containers organize blobs, but they are not file-system folders in the same sense as Azure Files. Applications commonly use Blob Storage for documents, media, backups, logs, data lakes, and other object-oriented workloads.

For AZ-104, practice creating containers, uploading blobs, changing access-related settings, working with tiers, configuring soft delete, lifecycle rules, and versioning. Each feature solves a different lifecycle problem.

When comparing Azure Files and Blob Storage, ask how the application expects to access data. A legacy application expecting a mounted file share has different needs from an application designed to read objects through a storage API.

Storage tiers are lifecycle and cost decisions

Blob tiers allow organizations to align storage cost and access characteristics with data usage. Frequently accessed data may belong in a hotter tier, while infrequently accessed data may be moved to cooler or archive-oriented options where supported and appropriate.

The exam-relevant reasoning is not simply “cold data goes to cool storage.” Consider retrieval needs, minimum retention implications, access latency, and lifecycle policy. If data becomes inactive after 30 days but must remain quickly retrievable, one choice may fit better than an archive tier that has different rehydration behavior.

Create a lifecycle scenario rather than memorizing tier names. “Move log files to a lower-cost tier after 60 days and delete them after a year” naturally leads to lifecycle management. The rule expresses business behavior over time.

Soft delete protects against accidental deletion

Soft delete retains deleted data for a configured period, allowing recovery after accidental removal. The current objectives include soft delete for blobs and containers, along with snapshots and soft delete for Azure Files.

Do not confuse soft delete with versioning or backup. Soft delete addresses deletion recovery within the storage service. Versioning keeps prior versions of blob data after modifications. Backups may provide a different recovery mechanism and operational boundary.

Build an experiment: enable soft delete, create an object, delete it, and restore it. Then ask what happens if the object is modified rather than deleted. That leads naturally to versioning.

Blob versioning protects previous object states

Blob versioning automatically maintains versions when a blob changes, helping recover prior states. It is particularly useful for accidental overwrite scenarios, but it also affects storage consumption and lifecycle design.

A scenario that says “recover the previous content after an application overwrote the blob” points more directly toward versioning than a feature intended only for deleted objects. Again, the best answer depends on the precise failure mode.

Practice by uploading a blob, changing it several times, and observing version history. Restore or access an earlier version. Then consider how lifecycle rules might manage old versions so retention does not grow without control.

Lifecycle management automates data aging

Blob lifecycle management uses rules to transition or delete data based on conditions such as age and other supported filters. It is an automation tool for ongoing storage hygiene and cost optimization.

Think of lifecycle rules as policy-like behavior within the storage service rather than organizational Azure Policy. They act on stored data according to configured rules. A common scenario might move older blobs to cooler storage and later delete them.

When building a rule, state the intended business outcome first. Then choose conditions that implement that outcome. This prevents arbitrary configuration and makes the rule easier to validate.

Snapshots are point-in-time copies for supported scenarios

Snapshots provide point-in-time representations that can assist with recovery. Azure Files snapshots are explicitly relevant to the current objectives. The important concept is that a snapshot represents the state of data at a time, which can be used to recover prior content.

Compare snapshots with soft delete. A snapshot exists because you intentionally or programmatically captured a point in time. Soft delete retains deleted items for a period. Both support recovery, but through different mechanisms.

Use small lab files to observe the difference. Create a snapshot, modify the file, and compare the versions. Then delete a file with soft delete enabled and restore it. The hands-on contrast is more memorable than a definition table.

Analyze AZ-104 identity and governance scenarios

Scenario 1: temporary vendor upload

Requirement: a third-party vendor must upload a set of files into one blob container during a four-hour window. The vendor should not receive the storage account key and should not have permission to delete existing objects.

Start with authorization. A time-limited SAS scoped to the appropriate resource and permissions may fit the temporary delegated-access requirement. Ensure the token’s permissions do not exceed the upload requirement. Then consider networking: if the storage account is restricted, the vendor’s access path must also be allowed.

The key is that multiple controls may apply. A perfectly scoped SAS does not bypass a storage firewall, and an open network path does not provide authorization by itself.

Scenario 2: protect against accidental overwrite and deletion

Requirement: an application frequently updates blobs. The operations team must recover both accidentally deleted blobs and earlier content after an incorrect overwrite.

Soft delete addresses deletion recovery. Versioning addresses prior blob states after changes. Depending on requirements, both may be relevant. A lifecycle rule may also be needed to control the long-term accumulation of versions.

This is a good example of why “enable backups” is too broad an answer. Storage-native recovery features may solve the stated failure modes more directly.

Scenario 3: private application access to storage

Requirement: a workload in a virtual network must access a storage account through a private IP path, and the service name should resolve appropriately inside the network.

This points toward a private endpoint design with correct DNS integration. The storage account’s network settings must allow the intended private path, while authorization still determines whether the workload identity can access the data.

Troubleshooting should check name resolution, private endpoint state, routes and security controls where relevant, storage networking configuration, and data authorization. The networking practice can reinforce this cross-domain reasoning.

Scenario 4: regional resilience requirement

Requirement: critical data must have copies outside the primary Azure region to support a regional disaster scenario.

This is primarily a redundancy design question. Compare geo-redundant options and determine which meets the stated read-access and resilience needs. Do not answer with zone redundancy alone if the requirement explicitly includes loss of the primary region.

Then ask how the application would use the secondary data during an incident. Resilience configuration and application recovery behavior are related but not identical. A storage choice can protect copies without automatically providing a complete application failover plan.

Scenario 5: migrate and validate data

Requirement: an administrator must move a large set of files or blobs into Azure Storage and confirm the data is present.

Storage Explorer can be useful for interactive administration. AzCopy is often useful for command-line data transfer at scale. The correct choice depends on the workflow and automation needs. After transfer, validate object counts, sizes, or application access rather than assuming a successful command means the migration is complete.

A storage troubleshooting sequence

When storage access fails, use a layered process:

1. Identify the resource and operation being attempted.
2. Confirm the identity or credential in use.
3. Check authorization at the correct management or data plane.
4. Confirm the network path and storage firewall configuration.
5. Validate DNS when private endpoints are involved.
6. Check the specific storage service and object path.
7. Review logs or diagnostics if available.
8. Change one variable at a time and retest.

This sequence prevents the common mistake of granting broader permissions when the real issue is networking, or opening the network when the real issue is authorization.

Capstone lab and decision model

Build a storage lab that combines the domain

A strong capstone lab can include one storage account, a blob container, an Azure Files share, restricted network access, identity-based authorization, a temporary SAS, versioning or soft delete, a lifecycle rule, and a redundancy choice justified by a requirement.

Do not configure everything simultaneously. Build the environment incrementally and validate each control. First prove basic access. Then change authorization. Then restrict the network. Then add recovery features. This order lets you see the effect of each layer.

Finally, intentionally break access. Expire the SAS, remove a data role, change the network rule, or disrupt DNS for a private endpoint. Troubleshoot from the symptom and document the root cause.

A decision matrix for storage scenarios

When several storage features appear plausible, reduce the scenario to a small decision matrix. Start with the data type: file share or object data. Then identify the access model: long-term identity-based access, temporary delegated access, or broad administrative credential. Add the network requirement: public endpoint with restrictions, selected virtual networks, or private IP connectivity. Finally, add the durability and recovery requirement.

For example, a legacy application that expects a mounted file share, uses organizational identities, and needs recovery from accidental deletion naturally points toward Azure Files with an appropriate identity model and recovery configuration. A web application that stores image objects, needs private VNet access, and must preserve old versions after overwrites points toward Blob Storage, private endpoint and DNS considerations, and versioning. A data-transfer utility that needs four hours of write-only access to one container may fit a carefully scoped SAS.

The matrix is useful because it prevents one familiar feature from dominating your answer. A private endpoint can solve the network path but does not decide whether the data belongs in Files or Blob Storage. Versioning can solve an overwrite-recovery problem but does not authorize a user. Redundancy can improve platform resilience but does not replace retention controls.

Common mistakes and cross-domain dependencies

Common storage mistakes to avoid

AZ-104 candidates often make predictable storage errors:

• giving out account keys when a narrower access method would fit;
• assuming RBAC management permission automatically grants data access;
• forgetting that network restrictions and authorization are separate layers;
• confusing service endpoints with private endpoints;
• choosing redundancy by acronym rather than failure requirement;
• confusing storage redundancy with object replication;
• treating Azure Files and Blob Storage as interchangeable;
• confusing soft delete, snapshots, versioning, and backup;
• ignoring DNS in private endpoint scenarios;
• enabling lifecycle rules without understanding the business retention requirement.

If any item feels vague, build a one-scenario example and explain why the alternative control would not satisfy the same requirement.

Connect storage to the other AZ-104 domains

Storage questions often contain clues from other domains. A resource may be governed by policy, protected by RBAC, accessed from a virtual network, used by a VM or App Service, monitored for performance, and included in recovery planning. Treat those clues as part of one Azure environment rather than as distractions.

When studying compute, ask how the workload authenticates to storage. When studying networking, ask how storage traffic resolves and routes. When studying governance, ask whether the organization requires a particular redundancy or network posture. When studying monitoring, identify the metrics and logs that would reveal storage latency, failed requests, capacity growth, or authorization problems.

This cross-domain approach is also a good way to avoid overfitting to storage-specific practice questions. The exam may describe a storage problem through the behavior of an application or network path. If you can follow the dependency chain, you are better prepared for that wording.

Use the final review to test explanation quality

In the final stage of preparation, pick ten storage terms at random and explain each without using the term itself in the definition. For SAS, explain temporary delegated permissions. For private endpoint, explain private IP connectivity to a PaaS resource and the DNS dependency. For versioning, explain preservation of previous blob states. For ZRS, explain resilience across availability zones in a region.

Then turn every explanation into a requirement. If the requirement does not clearly point back to the concept, your explanation may be too vague. This exercise reveals whether your knowledge is operational enough to survive unfamiliar question wording.

A strong AZ-104 storage candidate does not need to memorize every portal option. What matters is to recognize the control plane, data plane, network path, durability model, and lifecycle behavior that the requirement actually depends on. Once those dimensions are clear, the specific storage feature is usually much easier to choose.

Final AZ-104 storage checklist

Before moving on from storage, Be ready to:

• create and configure a storage account;
• explain management access versus data access;
• compare account keys, SAS, stored access policies, and identity-based access at an administrator level;
• configure or reason about storage firewalls and virtual network restrictions;
• distinguish service endpoints from private endpoints and include DNS in the latter design;
• choose redundancy based on the required failure boundary;
• explain object replication separately from account redundancy;
• identify the purpose of storage encryption settings;
• use Storage Explorer and recognize when AzCopy is useful;
• create and manage Azure Files shares and Blob containers;
• reason about storage tiers and lifecycle rules;
• distinguish soft delete, snapshots, and versioning;
• troubleshoot access by checking identity, authorization, networking, DNS, and service configuration in sequence.

The AZ-104 exam can help you test these decisions after the concepts are stable. If storage remains one of your weaker domains, return to practical labs rather than trying to memorize more feature names.

Azure storage becomes manageable when you stop treating it as a catalog. Think in layers: identity and authorization, network path, resilience, service type, and data lifecycle. That mental model applies across many storage scenarios and gives you a reliable way to reason through unfamiliar AZ-104 questions.