6.2 Unstructured Data Storage Design

Why Unstructured Data Storage Decisions Matter on AZ-305

Not all data fits a document or table model. Video files, log archives, virtual machine disks, medical images, and lift-and-shift file shares are all unstructured data — bytes with no enforced internal schema. The "Recommend a solution for storing unstructured data" objective tests whether you can route a scenario to the right one of Azure's three unstructured storage services on the first read: Blob Storage, Azure Files, and Azure Data Lake Storage (ADLS) Gen2.

Azure Blob Storage: The Default Object Store

Blob Storage stores unstructured data as objects (blobs) inside containers within a storage account. There are three blob types:

Blob Storage is accessed via REST calls or an SDK — it is not natively mountable as a network drive. That gap is exactly why Azure Files exists.

Azure Files: A Real File Share in the Cloud

Azure Files provides fully managed file shares accessed over SMB (Windows, Linux, and macOS clients) or NFS (Linux clients only), plus a REST API. Because it behaves like a traditional file server, it is the default choice whenever a scenario says the application or its users expect to mount a drive letter or a UNC path.

Identity-based access uses Microsoft Entra Domain Services, on-premises Active Directory Domain Services (AD DS), or Microsoft Entra Kerberos — a hybrid-identity design point revisited in Chapter 3's authorization coverage. Azure File Sync caches an Azure file share on an on-premises Windows Server so branch offices keep local read/write performance while the cloud share remains the source of truth — the standard answer for "replace an aging on-prem file server without losing local performance."

Trap: Azure Files does not support RA-GRS or RA-GZRS (there is no continuously readable secondary), and NFS shares are Linux-only — a requirement for Windows NFS clients should route you back to SMB, or to a different service entirely.

Azure Data Lake Storage Gen2: Analytics at Object-Storage Scale and Price

ADLS Gen2 is not a separate service — it is a set of capabilities layered on top of Blob Storage, unlocked by enabling hierarchical namespace (HNS) on the storage account. HNS turns a flat container of blobs into a true directory tree, which makes operations like renaming or deleting a folder a single atomic metadata operation instead of an expensive per-object enumeration across every blob sharing that name prefix.

Key ADLS Gen2 characteristics:

• Hadoop-compatible access via the Azure Blob File System (ABFS) driver, used by Spark, Hive, and other HDFS-based frameworks — this is the answer whenever a scenario mentions Hadoop, Spark, Databricks, or Synapse Analytics reading raw files.
• POSIX-style access control lists (ACLs) at the file and directory level, layered on top of Azure RBAC, giving finer-grained security than plain Blob Storage containers offer.
• Massive scalability — no imposed limits on account size or file count; individual files can range from a few KB to hundreds of TB.
• Inherits Blob Storage's tiering, lifecycle management, and redundancy options, because it is Blob Storage underneath — covered in the next section.

Choosing Between the Three

Storage Account Types and Protocol Nuances

The service you get depends partly on the storage account type selected at creation:

A subtler exam trap: Blob Storage accounts with hierarchical namespace enabled can also expose data over the NFS 3.0 protocol directly (distinct from Azure Files' NFS support), which is useful for Linux-based big-data or HPC workloads that need POSIX file semantics against object storage without paying for a separate file-share service. Similarly, SFTP can be enabled directly on a Blob Storage account with hierarchical namespace, letting external partners upload files without provisioning a dedicated FTP server. Both NFS 3.0 and SFTP endpoints require hierarchical namespace to be enabled — another reason ADLS Gen2's HNS setting keeps reappearing across different unstructured-data requirements on the exam, not just analytics ones.

Scenario Walkthrough

A media company stores 500 TB of raw video assets that data scientists analyze with Databricks notebooks. They need directory-level access control so that only the analytics team can see the "raw" folder while marketing can browse only the "published" folder.

Design: a standard Blob Storage account with hierarchical namespace enabled (ADLS Gen2), because the workload needs both Hadoop-compatible (Databricks) access and folder-level POSIX ACLs — a plain Blob Storage container has no concept of folder-scoped permissions this granular; it can only apply access at the container or blob level.

Key Takeaways Recap

Blob Storage is the generic object store; Azure Files is for anything expecting a real file system over SMB or NFS; ADLS Gen2 is Blob Storage with hierarchical namespace turned on for big-data analytics and folder-level security. All three share the same underlying access-tier and redundancy model covered next in Section 6.3.