Configure Azure Files and Azure Blob Storage (AZ-104)

Azure Files and Azure Blob Storage are two services inside a storage account, and choosing the right one is the first decision the exam tests. Azure Files provides fully managed file shares that behave like a traditional network drive: they expose the SMB and NFS protocols, present a folder hierarchy, and can be mounted with a drive letter or mount point by many clients at once. Choose Azure Files when applications or users need a shared file system they can lift and shift without rewriting, or when you want to replace an on-premises file server.

Azure Blob Storage is object storage built for massive amounts of unstructured data — images, video, backups, logs, and documents — addressed over HTTP(S) rather than a file-share protocol. Data lives in containers (similar to top-level folders) as blobs, and blobs come in three types: block blobs for most files and streaming content, append blobs optimized for logging where you only add to the end, and page blobs that back Azure virtual machine disks. Choose Blob Storage for scalable object data, static website content, and archival.

Both services live in the same storage account, so they share its name, redundancy, and access keys — but their features differ. Files has share snapshots and Azure File Sync; Blob has access tiers, versioning, and lifecycle management. Knowing which feature belongs to which service is a recurring exam theme, so keep the two mental models distinct as you read the rest of this lesson.

You create a file share inside a storage account under Data storage > File shares > + File share. You give it a name, pick a protocol — SMB (the default, for Windows, Linux, and macOS) or NFS (for Linux workloads, which requires a premium FileStorage account) — and set a quota. The quota is a soft size limit in GiB that caps how large the share can grow; on standard shares you are billed for data actually stored, while premium shares are provisioned to the quota you set.

To use the share, you mount it. From Windows you map it as a network drive using the UNC path \\account.file.core.windows.net\sharename; the portal generates a ready-made net use or PowerShell command that includes the storage account key. From Linux you mount an SMB share with cifs or an NFS share with the nfs client. SMB shares reach clients over port 445, so that outbound port must be open — a common reason a mount fails from an on-premises network that blocks it.

Azure Files offers two performance options: standard shares on general-purpose v2 accounts backed by HDD, and premium shares on FileStorage accounts backed by SSD for low-latency, IOPS-heavy workloads. On the exam, a scenario asking for a shared drive multiple machines mount at once points to Azure Files, and NFS support signals a premium FileStorage account.

Azure Files gives you two independent layers of data protection. A share snapshot is a read-only, point-in-time copy of an entire file share. You take one from File shares > the share > Snapshots > + Add snapshot, and snapshots are incremental — each stores only the blocks that changed since the previous one, so they are storage-efficient. When a user deletes or corrupts a file, you browse the relevant snapshot and restore just that file, or you restore the whole share. On Windows clients, snapshots surface through the familiar Previous Versions tab, letting users self-serve recovery.

Soft delete for Azure Files protects against deleting the entire share. When enabled at the storage-account level, a deleted file share is not removed immediately but retained for a retention period you set (from 1 to 365 days), during which you can restore it in full. Without soft delete, deleting a share is permanent and unrecoverable — with it, an accidental deletion is a quick undo within the window.

The two features solve different problems: snapshots recover individual files and folders to an earlier state, while soft delete recovers a whole share you deleted. Together they cover both accidental file edits and accidental share deletion. For the exam, remember that share snapshots are incremental point-in-time copies and that soft delete for Azure Files is a share-level recycle bin with a configurable retention window.

Azure File Sync lets you keep an Azure file share synchronized with one or more on-premises Windows Servers, turning each server into a fast local cache of a share that lives in the cloud. It is the answer whenever a scenario asks you to sync an on-premises file server to Azure or to centralize branch-office file servers without giving up local performance.

The building blocks are worth knowing by name. A Storage Sync Service is the top-level Azure resource. Inside it you create a sync group, which ties together one cloud endpoint (your Azure file share) and one or more server endpoints (a path on a registered Windows Server running the Azure File Sync agent). Everything in the sync group stays in sync: a file written on any server or in the cloud share propagates to all the others.

The feature that makes it powerful is cloud tiering. With cloud tiering enabled, frequently accessed (hot) files stay cached on the local server for fast access, while cold files are tiered up to Azure and replaced on the server by a small pointer called a reparse point. When a user opens a tiered file, Azure File Sync transparently recalls it. You control tiering with a volume free-space policy (keep a percentage of the disk free) and an optional date policy (tier files not accessed in N days). The result: a server with a small disk can front a share far larger than itself. For the exam, cloud tiering plus on-premises caching of an Azure file share equals Azure File Sync.

Blobs live in containers, which you create under Data storage > Containers > + Container. You give the container a name and, critically, set its public access level, which controls whether anonymous callers can read its contents without a credential. There are three levels, and choosing the right one is a frequent exam and security question.

Anonymous access only works if the storage account also permits it — a modern account has Allow Blob anonymous access disabled by default, which overrides any container setting until an administrator turns it on. Keep containers private unless there is a clear reason to publish, and use SAS tokens (covered in the access-control topic) for scoped, temporary sharing instead of opening a container.

You do not choose the blob type when you create the container; the type — block, append, or page — is determined when each blob is uploaded. For the exam, know that private requires a credential for every read, blob allows anonymous read of known blob URLs, and container additionally allows anonymous listing.

Azure Blob Storage lets you match cost to how often data is read by choosing an access tier. Tiers trade storage cost against access cost and retrieval latency: hotter tiers cost more to store but less to read and are instantly available, while cooler tiers cost less to store but charge more per read and impose minimum retention periods and, for archive, a wait before you can read at all.

The critical distinction is that hot, cool, and cold are all online tiers you can read immediately, whereas archive is offline: the blob's data is not readable until you rehydrate it. You can set the tier at two scopes — a default account-level tier (hot or cool) that new blobs inherit, and a per-blob tier you set explicitly, including cold and archive, which are only settable per blob or by a lifecycle rule. On the exam, wording like rarely accessed, must rehydrate before reading is the archive tier, while removing a blob from a cool or cold tier before its minimum retention period incurs an early-deletion charge.

Rehydrating archived blobs

Because the archive tier stores data offline, you cannot read, copy, snapshot, or overwrite an archived blob directly — attempting to read it fails. To bring it back online you must rehydrate it, and rehydration is not instantaneous, which is the single most important operational fact about archive. There are two ways to do it: change the blob's tier from archive to an online tier (hot, cool, or cold), which rehydrates it in place; or copy the archived blob to a new blob in an online tier, leaving the original in archive. Either way you choose a rehydration priority — Standard, which can take up to about 15 hours, or High, which is faster (often under an hour for smaller blobs) but costs more.

A practical example: a compliance team asks for a report archived two years ago. You submit a rehydration by setting the blob's access tier to hot with Standard priority, wait for the operation to complete, then download it. If they needed it within the hour, you would pay for High priority instead. The lesson administrators must internalize is that archive is cheap to store but slow to read, so reserve it for data you are confident you will rarely, if ever, need quickly — backups you must retain for years, not files you might open next week.

Two account-level features protect blob data from mistakes, and the exam expects you to tell them apart. Soft delete is a recycle bin: when enabled, a deleted blob (or an overwritten one) is retained for a retention period you configure — typically 1 to 365 days — during which you can undelete it and recover the data. There are two flavors: blob soft delete recovers individual deleted blobs, and container soft delete recovers a whole deleted container. Enable both to survive both an accidental blob deletion and an accidental container deletion. Once the retention window passes, the data is permanently gone.

Blob versioning solves a related but different problem: keeping history when a blob is overwritten. With versioning on, every time you modify or overwrite a blob, Azure automatically preserves the previous state as a version with its own version ID, and the newest write becomes the current version. You can list every version of a blob and restore or read any earlier one, giving you a full change history without managing it yourself. Versioning also works hand-in-hand with lifecycle management, which can clean up old versions on a schedule.

For the exam, keep the trigger words straight: recover accidentally deleted blobs means soft delete, while automatically keep previous versions on overwrite means blob versioning. They are complementary — soft delete undoes deletions, versioning undoes overwrites — and administrators typically enable both together on important data.

Blob lifecycle management is the automation you configure so blobs move to cheaper tiers and eventually delete themselves without anyone touching them. You author a policy made of rules; each rule targets a set of blobs (by container prefix or blob index tags) and defines actions that fire based on age — days since the blob was last modified or last accessed. Available actions include tierToCool, tierToCold, tierToArchive, and delete, and rules can also manage previous versions and snapshots separately from current blobs. Lifecycle management is the exam answer whenever a scenario asks to automatically move blobs to cooler tiers over time or purge stale data on a schedule.

Concrete scenario. Your team stores log files that are read heavily for a month, occasionally for a quarter, rarely after that, and must be kept one year for compliance. You create a single lifecycle rule on the logs container: after 30 days since last modification, tier to cool; after 90 days, tier to archive; after 365 days, delete. Azure evaluates the policy once per day and applies each action as blobs cross those age thresholds — no scripts, no scheduled jobs, and the cost drops automatically as data cools.

To make that pipeline safe against mistakes, you pair it with the recovery features from the previous section: enable blob soft delete and container soft delete (say a 30-day window) so an accidental deletion is recoverable, and turn on blob versioning so an overwrite never loses the prior copy. The lifecycle policy handles cost over time; soft delete and versioning handle human error. For the exam, that combination — lifecycle rules for tiering and cleanup, soft delete and versioning for accidental-deletion protection — is the model configuration for managing blob data at scale.