Microsoft AZ-104: Azure Storage — Study Guide

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Part of the Microsoft Azure Administrator Associate AZ-104 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Azure Storage underpins data services across Azure, offering durable, highly available object and file storage with granular security and flexible networking. Mastery requires understanding account types and redundancy, data lifecycle and protection for blobs, file share choices and synchronization, strong authentication and controlled network access, and operational tooling for bulk transfer and administration.

Storage account types and durability

General-purpose v2 (GPv2) accounts are the default and recommended choice for most scenarios. They support blobs (including Data Lake Storage Gen2 hierarchical namespace when enabled), files, queues, and tables, across standard HDD-backed and premium SSD-backed performance tiers (premium for block blob, page blob, or file shares depending on sub-type). BlobStorage accounts are legacy, blob-only accounts with limited features; they persist primarily for backward compatibility. FileStorage accounts are premium accounts specialized for Azure Files, delivering provisioned, predictable IOPS and throughput with low latency, and supporting both SMB and NFS 4.1.

Redundancy choices balance durability, availability, and cost:

LRS stores three synchronous copies in a single datacenter, suitable for intra-zone resilience but not for zone or regional failures.
ZRS stores three synchronous copies across distinct availability zones within a region, protecting from a zonal outage while maintaining read/write availability.
GRS stores three synchronous copies locally (LRS) plus three asynchronous copies to a paired secondary region. The secondary is non-readable until a failover.
RA-GRS is GRS with read access to the secondary endpoint, enabling read-mostly workloads to continue during primary disruption. This is the correct option when data must be readable from the secondary at all times.
GZRS combines ZRS in the primary region with asynchronous replication to a secondary region (LRS). It offers both zone fault tolerance and regional disaster recovery.
RA-GZRS adds read access to the secondary for GZRS.

Choose RA-GRS or RA-GZRS when cross-region reads are required, GRS/GZRS for cross-region DR without read access, ZRS for zone-level resilience with the lowest write latency, and LRS for cost-optimized durability without zone/region coverage.

Blob data management, tiers, and protection

Blob access tiers optimize cost by aligning storage pricing with access patterns. Hot tier provides the lowest per-GB access and transaction latency, recommended for frequently accessed data. Cool tier lowers storage cost with higher access and early deletion charges; use for data read infrequently (at least 30-day horizon). Archive tier is offline and the lowest cost per GB, with hours of rehydration latency and minimum retention charges; it is best for compliance or long-term backup. Tiers can be set per blob; a default access tier can be applied at the account or container level for new objects.

Lifecycle management policies automate tiering and retention. Rules evaluate daily and can filter by prefix, blob type, last modified time, and blob index tags. Actions include moving from hot to cool, cool to archive, rehydrate (in limited conditions), and deleting base blobs, snapshots, or versions after a specified age. Last access time-based policies can further refine transitions. Well-designed rules convert cost from manual oversight to policy-driven governance while ensuring compliance retention windows.

Data protection features should be enabled deliberately:

Blob soft delete preserves deleted or overwritten blobs for a retention window, allowing recovery without restoring from backup. It applies to base blobs and can be extended to snapshots and versions.
Versioning maintains a read-only version upon every overwrite or delete, offering point-in-time recovery per object and enabling application-safe concurrency.
Container soft delete protects containers from accidental deletion by retaining them for a configured period, enabling restore of the container and its contents.
Point-in-time restore for containers allows restoring one or more containers to a previous timestamp within a retention period. It requires blob versioning and the change feed, and is especially valuable for large-scale logical corruption recovery, reconstructing state to a consistent point across many objects.

Snapshots for block blobs provide additional ad hoc recovery points but are superseded by versioning in most operational designs. Ensure lifecycle policies and legal hold/immutability requirements do not conflict, especially when combining archive tiering and WORM retention.

Azure Files and Azure File Sync

Azure Files provides fully managed file shares with Azure-native elasticity and global availability. SMB shares support SMB 3.x features like encryption in transit, continuous availability on premium FileStorage shares in certain scenarios, and identity-based access control. NFS 4.1 shares are available only on premium FileStorage accounts, optimized for UNIX/Linux workloads; they use POSIX permissions and export policies, with access constrained to selected networks for security.

Identity-based authentication for SMB offers multiple options:

Active Directory Domain Services (AD DS) authentication, using a domain controller hosted on-premises or in Azure IaaS, supporting NTFS ACLs and Kerberos/NTLM.
Azure AD Domain Services (Azure AD DS), providing a managed domain without managing domain controller VMs.
Azure AD Kerberos for Azure Files, enabling modern, cloud-only identity for SMB access from Azure AD-joined Windows clients and Windows Server 2022, removing the need for traditional domain controllers while preserving Kerberos and ACL semantics. Integrate with RBAC and share-level permissions to align storage authorization with identity governance.

Azure File Sync extends Azure Files to on-premises Windows Servers, converting your Azure file share into a hub for multi-site sync with centralized cloud storage. A Storage Sync Service resource orchestrates replication. Within it, sync groups bind:

A cloud endpoint, which references an Azure file share in a storage account.
One or more server endpoints, each mapping a path on a registered Windows Server volume.

After installing the Azure File Sync agent and registering the server, add the server endpoint path (for example, D:\Shares\Projects). Cloud tiering can be enabled to maintain namespace locally while stubbing cold files; policies include volume free space targets and last-access heat-based eviction. On-demand recall restores file content transparently on access. Initial seed and recall strategies, DFS-N integration for referrals, and antivirus exclusions for the AFS system directories are core operational considerations. Change enumeration and journal-based sync minimize churn; throttling and offline data transfer seeding can protect bandwidth during initial replication.

Security, networking, and controlled access

Shared access signatures (SAS) grant scoped, time-bound access without exposing account keys. Service SAS targets a specific resource (blob, container, file share, queue, table) with defined permissions, start/expiry times, allowed IP ranges, protocols, and preauthorized object names. Account SAS spans multiple services and resource types within the account but cannot be bound to a stored access policy; it should be used sparingly due to broader scope. User delegation SAS is the recommended pattern for Blob service when using Azure AD; it is signed with a short-lived user delegation key obtained via Azure AD, producing an auditable, least-privilege token. Stored access policies attach to containers or shares and allow centralized revocation and permission/time updates for multiple issued SAS tokens by modifying or deleting the policy.

Azure AD authorization integrates with Blob and Queue, and with Azure Files through AD-based SMB models described earlier. For Blob and Queue, assign Azure RBAC roles such as Storage Blob Data Reader, Contributor, or Owner at the account, container, or resource group scope. Application access should prefer managed identities and OAuth over account keys, reducing key distribution risk and enabling conditional access and Privileged Identity Management at scale.

The storage firewall enforces network-origin restrictions when set to Selected networks:

Virtual network rules grant access to specific subnets that have Microsoft.Storage service endpoints enabled, or use private endpoints for per-resource private access via private IP in your VNet. Service endpoints are simpler to configure and preserve public endpoints; private endpoints provide the strongest isolation and egress control.
IP network rules permit public IPv4 addresses or CIDR ranges for on-premises or internet clients; use this for tightly scoped administrative access.
Resource instance rules allow trusted Azure service instances (for example, a Synapse workspace or a specific Logic App) to reach the storage account without broad “allow trusted Microsoft services” exceptions, by specifying the resource ID and supported service type, helping maintain least privilege.

Enable TLS 1.2+, require secure transfer, rotate account keys, and audit using Storage Analytics and Azure Monitor diagnostic settings. Combine network rules with Azure AD RBAC and SAS hygiene for a defense-in-depth posture.

Data movement and tooling

The Azure Import/Export service accelerates bulk data movement using encrypted disks. For import, prepare 2.5”/3.5” SATA HDD/SSD drives, encrypt them with BitLocker, and use the Azure Import/Export tool to write data and generate a drive manifest and journal files. Create an import job in the portal, upload the drive list and contact details, print shipping labels, and ship via the supported carrier to the Microsoft datacenter address provided. Track progress and upload journal files so Azure can resume copy if interrupted. For export, specify the containers or blobs, create the job, Microsoft writes to BitLocker-encrypted drives, and ships back; you use keys provided in the job to unlock. Always validate region availability, drive count and size limits, and retention windows for unclaimed shipments.

AzCopy is the command-line utility for high-performance transfers. Authenticate using Azure AD (interactive or service principal) for Blob and Azure Files, or attach SAS tokens to source/destination URLs, or use account keys (environment variables or login command where supported). Core operations include copy for one-time transfers and sync for directional mirroring that compares source and destination and transfers deltas. Typical patterns include local-to-blob, blob-to-blob (including intra- and inter-account service-side copy), and share-to-share. Use recursive transfers, include/exclude patterns, concurrency tuning, and checksum validation. For archival workflows, set the destination blob tier on upload. When syncing, understand that sync deletes at the destination can be enabled or suppressed; choose mode based on backup versus distribution semantics.

Azure Storage Explorer provides a GUI for multi-tenant, multi-cloud administration. Connect using Azure AD sign-in, account name/key, or SAS URIs. Manage containers and shares by creating folders, uploading and downloading, editing metadata, setting object tiers, viewing snapshots and versions, and restoring deleted items when soft delete is enabled. Generate SAS tokens with precise permissions, IP ranges, and start/expiry, and share them with developers or partners under stored access policies where applicable. Storage Explorer integrates seamlessly with AzCopy for high-throughput operations while surfacing progress and retries.

Practical Problem Scenario

Starbucks must consolidate branch file servers into Azure, provide cross-region disaster recovery, protect against accidental deletions, and migrate 100 TB of historical media assets on a tight timeline without saturating WAN links.

Choose account architecture and redundancy

Create a premium FileStorage account in the primary region for low-latency SMB and NFS shares, and a GPv2 account for blob-based media archives. Configure RA-GZRS on the GPv2 account so media assets are readable from the secondary during regional incidents, and ZRS on FileStorage for zonal resilience and consistent write availability. This pairing delivers premium file share performance and blob DR with read access.

Secure access and networking

Enable Selected networks on both accounts. For branch access to SMB shares, create private endpoints per share in a Hub VNet and expose them via Azure VPN/ExpressRoute to branches. Add resource instance rules for a Synapse workspace that runs analytics on media stored in blobs, limiting that service’s access to just this storage account. This design isolates storage from the public internet and maintains least-privilege access for PaaS analytics.

Identity-based authorization

Enable Azure AD Kerberos for Azure Files to allow Azure AD-joined Windows clients to access SMB shares using corporate identities, and configure NTFS ACLs for role-based access. For blob access by applications, assign managed identities the Storage Blob Data Contributor role at the container scope and use user delegation SAS for short-lived delegated operations. This reduces key exposure and centralizes authorization.

Data protection and lifecycle

Turn on blob versioning, blob soft delete, container soft delete, and the change feed. Configure point-in-time restore for containers with a 14-day window. Add lifecycle rules to move blobs not accessed for 30 days to Cool and for 180 days to Archive, excluding files tagged legalHold=true. These settings protect against logical deletion and lower storage costs over time.

Bulk migration

Create Azure Import jobs for 100 TB of media. Encrypt SATA SSDs with BitLocker, prepare drives with the Import/Export tool to generate manifests and journal files, ship via the approved carrier to the provided datacenter address, and monitor job status in the portal. This avoids WAN saturation and completes seeding quickly.

Ongoing sync and branch consolidation

Deploy Azure File Sync on each remaining branch Windows Server. Register servers to a Storage Sync Service, create a sync group with the cloud endpoint pointing to the premium SMB share, and add server endpoints for each branch path. Enable cloud tiering with a 20% free space target to keep hot files local and cold files as stubs. This provides fast local access with cloud-scale centralization.

Operations and tooling

Use AzCopy with Azure AD authentication for incremental uploads from content creation systems to a hot-tier ingestion container, then rely on lifecycle rules for tier transitions. Administrators use Azure Storage Explorer to manage containers, restore deleted items, generate SAS for partners with explicit IP restrictions and short expiries, and adjust blob tiers when accelerating access to archived items. This combination streamlines daily operations while maintaining security and auditability.

Each service choice aligns with the requirement: premium FileStorage for low-latency SMB/NFS, GPv2 with RA-GZRS for blob DR and cost tiers, private endpoints and resource instance rules for strict network control, Azure AD-based auth for least privilege, Import/Export for fast initial seeding, Azure File Sync with cloud tiering for branch consolidation, and AzCopy/Storage Explorer for efficient, governed operations.

← Azure Load Balancing and Traffic Management · All domains · Azure App Service and PaaS Compute →

Practice these questions → · Timed practice on ExamRoll.io →