AZ-104 · Implement and manage storage · Updated August 7, 2026
Azure Files vs Azure Blob Storage: Choosing File Shares vs Object Storage
Azure Files and Azure Blob Storage both live inside a storage account, and both are commonly the right answer to “where does this data go” on the AZ-104 exam, which is exactly why they get confused. The distinction comes down to how the data gets accessed. Blob Storage is object storage: applications talk to it over REST using a container/blob namespace, and there’s no concept of mounting it as a drive letter without an extra layer on top. Azure Files is a real network file share, reachable over SMB or NFS, that Windows, Linux, and macOS clients mount and browse exactly like a traditional file server. Once you know which access pattern a scenario describes, choosing between them stops being a guess.
What Blob Storage is built for
Blob Storage stores unstructured data as objects inside containers, addressed by a URL rather than a file path. Applications read and write blobs through the Azure Files REST API, SDKs, or tools like AzCopy and Storage Explorer, and the service scales to enormous volumes of data without requiring you to think about drive capacity. It supports block blobs, append blobs, and page blobs, and every one of the Hot, Cool, Cold, and Archive access tiers applies to block blobs specifically. Blob Storage is the natural fit for application data, backups, media files, logs, static website content, and data lake workloads, anything an application reads and writes programmatically rather than something a person needs to browse in File Explorer.
What Azure Files is built for
Azure Files provides fully managed file shares accessed over SMB (Windows, Linux, and macOS clients) or NFS (Linux clients only), plus a REST API for programmatic access from any platform. Because it speaks SMB and NFS natively, an Azure file share mounts as a network drive with no client-side software beyond the OS’s built-in mount tooling, and existing applications that expect a UNC path or a mounted volume keep working without rewrites. That makes Azure Files the tool of choice for replacing or supplementing an on-premises file server, hosting FSLogix profile containers for Azure Virtual Desktop, sharing application configuration across VM instances, and providing persistent, shared volumes for stateful containers.
Comparing the two side by side
| Azure Blob Storage | Azure Files | |
|---|---|---|
| Access pattern | Object storage, addressed by URL | Network file share, mounted as a drive |
| Protocols | REST API, SDKs | SMB, NFS, REST API |
| Client support | Any platform via REST/SDK | SMB: Windows, Linux, macOS. NFS: Linux only |
| Mountable as a drive | No (without a third-party gateway) | Yes, natively |
| Access tiers | Hot, Cool, Cold, Archive | Transaction optimized, Hot, Cool (premium tier is a separate performance option) |
| Identity-based auth | Microsoft Entra ID, SAS, account keys | AD DS, Microsoft Entra Domain Services, Microsoft Entra Kerberos |
| Typical use case | Application data, backups, media, data lakes | File server replacement, shared config, FSLogix, container volumes |
| Redundancy options | LRS, ZRS, GRS, GZRS, and read-access variants | ZRS and GRS (varies by tier) |
Both services share the same redundancy model at the storage-account level, but Azure Files doesn’t support quite as many redundancy combinations as Blob Storage does, and premium file shares in particular are more restrictive, so check the specific SKU before assuming every redundancy option is available.
Identity-based authentication for Azure Files
SMB Azure file shares support three identity sources for Kerberos-based authentication, and a storage account can only use one of them at a time, applied to every file share in the account:
- On-premises Active Directory Domain Services (AD DS). The storage account joins your existing on-premises AD DS, and users authenticate with their normal domain credentials. This requires the on-premises AD DS to already be synced to Microsoft Entra ID (via Microsoft Entra Connect Sync or Microsoft Entra Connect cloud sync), and clients need unimpeded network connectivity to a domain controller. This is the natural choice when you’re replacing an on-premises file server and want a seamless credential experience for domain-joined machines.
- Microsoft Entra Kerberos. Microsoft Entra ID itself issues the Kerberos tickets, which means clients don’t need network connectivity to a domain controller at all. It supports both hybrid identities (which still require an underlying AD DS synced to Microsoft Entra ID) and cloud-only identities. This is the right call when clients can’t reach on-premises domain controllers, when you’re storing FSLogix profiles for Microsoft Entra-joined virtual desktops, or when you need to authenticate macOS clients.
- Microsoft Entra Domain Services. A managed, traditional Windows Server AD domain that Microsoft Entra ID runs as a child of your tenant. VMs joined to the managed domain authenticate against it using Kerberos. This fits organizations that already run Microsoft Entra Domain Services for other workloads and want file share auth to use the same managed domain.
Regardless of which identity source you pick, Azure Files still supports the storage account key as a fallback authentication method, but Microsoft recommends identity-based authentication for production workloads because it lets you set granular share, directory, and file-level permissions instead of handing out an all-or-nothing account key. Blob Storage, by contrast, is more commonly secured with Microsoft Entra ID role assignments or a shared access signature scoped to a container or blob.
Azure File Sync for hybrid scenarios
When an organization wants to keep an on-premises file server but back it with cloud-scale storage and cloud-based resiliency, Azure File Sync is the bridge. It designates an Azure file share as the central hub, and one or more registered Windows Servers, on-premises or in Azure, sync their data to and from that hub through a sync group made of a cloud endpoint (the Azure file share) and one or more server endpoints (the local paths being synced).
The feature that makes this practical at scale is cloud tiering: frequently accessed files stay cached on the local server’s disk, while infrequently accessed files get tiered to the Azure file share, leaving only a lightweight pointer on the local disk. The full namespace remains visible and browsable locally regardless of what’s tiered, and opening a tiered file transparently recalls it from Azure. This lets a branch office run on a much smaller local disk than the full dataset would otherwise require. Azure File Sync also supports multi-site sync, so multiple office locations can share one namespace with changes propagating through the cloud hub, and it simplifies disaster recovery: since Azure holds the authoritative, redundant copy, a failed on-premises server can be replaced by installing the sync agent on a new one and letting it resync rather than restoring from local backup.
How the AZ-104 exam tests this
- “Mount as a network drive” vs “accessed by an application via API.” This is the single fastest way to tell whether a scenario wants Azure Files or Blob Storage. Any mention of mapping a drive letter, mounting to
/mnt, or replacing a file server points to Azure Files. - NFS-only workloads. If a scenario specifies NFS and Linux-only clients, that’s Azure Files (NFS shares), not Blob Storage, and not the SMB side of Azure Files either.
- Choosing an identity source for Azure Files. Expect scenarios built around network connectivity constraints (no path to a domain controller favors Microsoft Entra Kerberos), platform constraints (macOS needs Microsoft Entra Kerberos), or an organization already standardized on Microsoft Entra Domain Services.
- Hybrid file server modernization. A scenario describing a branch office running low on local disk space, needing centralized backup, or needing multi-site access to the same files is describing Azure File Sync with cloud tiering, not a straight lift of files into Blob Storage.
- FSLogix and Azure Virtual Desktop profile storage. Expect this paired with Azure Files specifically, since FSLogix profile containers require an SMB share, which Blob Storage cannot provide directly.
For the full map of how storage services, redundancy, and access control fit together on the exam, see the AZ-104 study guide.