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

Azure Files provides managed file shares that many clients mount at once like a network drive, while Azure Blob Storage provides object storage in containers that applications and browsers reach over HTTP(S). Choosing between them is the first decision the exam tests.

Azure Files exposes the SMB and NFS protocols, a real folder hierarchy and file-system semantics such as file locking, so several virtual machines can map the same drive letter and safely share files. Choose it when an application expects a file server and you want to lift and shift without rewriting, or to replace an on-premises file server. A managed disk, by contrast, is block storage attached to one VM (shared disks need cluster software to coordinate writes), and blob storage has no SMB locking or drive letter.

Blob Storage holds unstructured data — images, video, backups, logs, documents — as blobs inside containers. Every blob has its own URL, and a container can be opened for anonymous read, which Azure Files never allows: a file in a share can be fetched by URL only with a SAS token or other credential. Blob Storage is therefore the fit for public downloads, static content and very large, cheap archives.

Both services live in the same storage account and share its name, redundancy and network settings, but their data-protection features differ.

You create a file share in a storage account under Data storage > File shares > + File share, and the settings that matter are the protocol, the media and billing model (which decide whether access tiers exist), the size, and how clients will reach it.

Protocol and account kind

SMB is the default and works from Windows, Linux and macOS. NFS 4.1 is for Linux clients and is available only on SSD (premium) file shares (for classic shares, a FileStorage storage account); a standard general-purpose v2 account cannot host an NFS share. A share uses one protocol for its whole life.

Billing models and Azure Files access tiers

Azure Files has three billing models, and only one of them has access tiers.

The three pay-as-you-go tiers are all the same HDD hardware with different prices, so a tier is a cost decision, not a performance one. Transaction optimized has the highest storage price and the lowest transaction price, so it suits shares with heavy read/write activity. Hot is the general-purpose middle. Cool has the lowest storage price and the highest transaction price, so it suits data kept online but read rarely, such as archived records that must stay readable without a rehydration wait. You can change a pay-as-you-go share between these tiers in place (it costs transactions to move the data). Getting SSD latency, however, is not a tier change: you create a new share on SSD in a FileStorage account and copy the data into it with a tool such as AzCopy or Robocopy.

Mounting and network access

From Windows you map an SMB share with the UNC path \\account.file.core.windows.net\sharename; the portal generates a ready-made script. From Linux you mount SMB with cifs or NFS with the NFS client. SMB uses TCP port 445, and many home internet providers and corporate firewalls block that port outbound. That block sits on the client's network, so nothing on the storage account fixes it: firewall rules, virtual network rules and service endpoints only decide which networks Azure accepts traffic from. The fix is to give the client a private path — a Point-to-Site or Site-to-Site VPN, or ExpressRoute — to a private endpoint for the account, so SMB travels inside the tunnel. (Azure File Sync, which caches a share on an on-premises Windows Server, is another way to serve the data locally; it is not part of this task's current skills outline.)

NFS shares have no user or key authentication. Storage account keys, SAS tokens and Kerberos do not authorize an NFS mount; access is controlled at the network level, so an NFS share must be reached through a private endpoint or a virtual network rule (service endpoint), and the account should never be open to the whole internet. SMB shares, in contrast, are mounted with the account key or with identity-based authentication, which the Configure access to storage lesson covers.

Azure Files has two independent protection layers: share snapshots recover files to an earlier point in time, and file share soft delete recovers a share that was deleted.

Share snapshots

A share snapshot is a read-only, point-in-time copy of the entire share. Snapshots are incremental — each stores only the data that changed since the previous one — so frequent snapshots are affordable. You take them manually under File shares > the share > Snapshots, or on a schedule with Azure Backup, which manages share snapshots and their retention for you. To recover, you browse a snapshot and copy back a single file or folder, or restore the whole share. On Windows clients with the share mounted, snapshots appear in a file's Previous Versions tab, so users can restore one file themselves without affecting anything else on the share. A share that has snapshots cannot be deleted until its snapshots are deleted too (the portal offers to delete them together).

File share soft delete

Soft delete is configured at the storage-account level and is enabled by default for new storage accounts, with a default retention of 7 days (configurable from 1 to 365 days). A deleted share moves to a soft-deleted state instead of being destroyed. In the portal you turn on Show deleted shares and Undelete it, which restores the share with all its contents and its share snapshots — so if a share was deleted together with its snapshots, you undelete the share first and then recover files from the snapshots as usual.

• Changing the retention period or disabling soft delete is not retroactive: shares already soft-deleted keep the retention they were deleted under.
• A soft-deleted share still counts toward the account's capacity (for provisioned shares, its provisioned size). To purge one early, undelete it, disable soft delete, delete it again, then re-enable soft delete.
• Soft delete protects whole shares, not individual files; recovering a single deleted or overwritten file is the job of snapshots.

Blobs live in containers, which you create under Data storage > Containers > + Container. The settings that matter are the anonymous access level, any immutability policy (next section), and an understanding of the blob types applications will write into it.

Anonymous access level

Two settings above the container also apply. First, the account setting Allow Blob anonymous access is disabled by default on new accounts; while it is off, the container level is greyed out at Private, so you enable it in the account's Configuration first. Second, anonymous requests are still subject to the account's networking firewall: if public network access is limited to selected virtual networks and IP addresses, an anonymous caller from an unlisted IP is refused even though the container is public. Keep containers private unless there is a clear reason to publish, and use SAS tokens for scoped, temporary sharing.

Blob types and how each is written

You do not choose a blob type when you create a container; the type is fixed when each blob is created, and it decides which write operations work.

Access tiers, lifecycle tiering actions and point-in-time restore apply to block blobs, which is another reason to know which type a workload uses.

An immutability policy stores blobs in a WORM (write once, read many) state: while it applies, blobs can be created and read but not modified or deleted — by anyone, including subscription owners. Container-level policies come in two kinds, and they can be combined.

A time-based policy starts unlocked, a testing state in which you can shorten, lengthen or delete it. Locking it is what makes it compliant with regulations such as SEC 17a-4(f): once locked, the policy cannot be deleted and its interval can only be extended, never shortened. Locking is irreversible, so test unlocked first.

Because WORM forbids modifying existing blobs, an append-only writer fails after a policy is applied unless you allow protected appends. allowProtectedAppendWrites lets new blocks be appended to append blobs while existing data stays protected; allowProtectedAppendWritesAll extends that to new blocks on block blobs as well (used by tools that write block blobs incrementally). For a time-based policy, these settings can be changed only while the policy is unlocked. Immutability can also be set per blob version (version-level immutability, which requires blob versioning); the exam focus for this task is the container-level choice between retention and legal hold.

An access tier trades storage cost against access cost and retrieval latency for block blobs: hotter tiers cost more to store and less to read, cooler tiers the reverse, with minimum retention periods and, for archive, a delay before data can be read at all.

Hot, cool and cold are online tiers read immediately; archive is offline. You set the tier at two scopes: the account's default access tier, which new blobs without an explicit tier inherit (hot unless you change it; archive can never be the default), and a per-blob tier set explicitly or by a lifecycle rule. For data read a few times a year that must still open instantly, cold is the cheapest online choice.

Archive is not available everywhere. It is supported only on accounts using LRS, GRS or RA-GRS; accounts on ZRS, GZRS or RA-GZRS cannot archive blobs. If policy requires zone redundancy, cold is the cheapest tier available — changing redundancy just to archive would break the requirement.

Early deletion. A blob that is deleted, overwritten or moved to a different tier before its tier's minimum retention period incurs an early-deletion charge for the remaining days, prorated. For example, a blob moved to cool and deleted after 10 days is charged for the 20 days it still owed, and a blob moved out of archive after 45 days is charged for 135 days.

Rehydrating archived blobs

An archived blob cannot be read, copied to archive, snapshotted or modified until it is rehydrated to an online tier. There are two ways:

• Set Blob Tier on the blob to hot, cool or cold — it rehydrates in place, and the blob's tier shows as archive (with a pending status) until the operation finishes.
• Copy the archived blob to a new blob with an online destination tier — the original stays in archive, so you pay for two copies.

Either way you choose a rehydration priority. Standard can take up to 15 hours. High costs more and is processed first; it can complete in under one hour for blobs smaller than 10 GB, though that is not guaranteed and larger blobs take longer. A pending request cannot be cancelled, and its priority can only be raised from Standard to High — by calling Set Blob Tier again with the same target tier and High priority — never lowered. High-priority retrieval throughput is limited per storage account (on the order of 10 GiB per hour), so rehydrating a large volume at High priority still takes time.

One side effect matters for automation: Set Blob Tier does not change the blob's last-modified time. A lifecycle rule that archives blobs by days since modification will therefore see a freshly rehydrated old blob as still old and archive it again on its next ruy — see the daysAfterLastTierChangeGreaterThan condition in the lifecycle section.

Blob data has three account-level recovery features — blob soft delete, container soft delete and blob versioning — and the exam tests both which one to enable and how a restore actually works with each.

Blob soft delete

Blob soft delete keeps deleted data for a retention period of 1 to 365 days. A deleted blob becomes soft-deleted, and you recover it with Undelete Blob, which also restores its soft-deleted snapshots. Soft delete also covers overwrites: when versioning is off, overwriting a blob saves the old content as a soft-deleted snapshot. Everything protected this way expires when the retention window passes.

Container soft delete

Container soft delete is a separate setting (also 1–365 days) that recovers a whole deleted container with its blobs. It does not protect individual blob deletions in a container that still exists — that needs blob soft delete — so enable both to cover both mistakes. A container can be restored only to its original name; if a new container with that name has been created since, the restore fails until you move any data you need out of the new container and delete it. Neither feature protects against deleting the storage account itself (use a resource lock for that).

Blob versioning

With versioning on, every write or delete automatically preserves the previous state as a version with its own version ID; the latest write is the current version. Versions do not expire — they persist until you or a lifecycle rule deletes them — so versioning is the choice when every prior state must be kept indefinitely, while soft delete is a time-limited safety net. Every version is billed, so pair versioning with a lifecycle rule that deletes old versions.

Which restore path works

When both features are on, overwrites and deletes create versions, not soft-deleted snapshots, and soft delete protects those versions from being deleted. Undelete Blob never promotes a version to current: it only restores soft-deleted versions or snapshots, so recovery always ends by copying the wanted version over the base blob.

Point-in-time restore

Point-in-time restore rolls a set of block blobs (a whole account, containers, or prefix ranges) back to their state at an earlier time. It requires blob soft delete, change feed and blob versioning to be enabled, and its restore window must be shorter than the soft-delete retention. It cannot restore a deleted container (that is container soft delete), and it is heavier than needed to recover one blob — use it for bulk rollback, such as after a faulty job corrupts many blobs.

Blob lifecycle management is a per-account policy of up to 100 rules that move blobs to cooler tiers and delete them automatically as they age — the answer whenever a scenario asks for tiering or clean-up "automatically, without scripts". Each rule has filters, which pick the blobs, and actions with conditions, which say what happens and when.

Filters

• blobTypes (required): blockBlob and/or appendBlob. Page blobs are not managed.
• prefixMatch: strings that start with the container name — sample-container/blob1 matches every blob in sample-container whose name begins with blob1. Prefixes are literal: no wildcards. Without a prefix filter, the rule applies to every container in the account.
• blobIndexMatch: blob index tag conditions (for example Project = Contoso), for targeting blobs by tag rather than by name.

Actions and conditions

Actions are tierToCool, tierToCold, tierToArchive and delete, set separately for the current blob (baseBlob), version and snapshot. Tiering actions apply only to block blobs; for append blobs the only action is delete. Conditions on the current blob are:

With last access time tracking on, a tierToCool action based on last access can also set enableAutoTierToHotFromCool, which moves a cool blob back to hot automatically when it is accessed again. An active policy processes objects periodically, and a new or changed policy can take up to 24 hours to take effect and start its first run — so blobs that already qualify are not moved the moment you save it.

A worked scenario

Log files are read heavily for a month, occasionally for a quarter, rarely after that, and must be kept one year. One rule filtered on blockBlob and the logs/ prefix does it: after 30 days since modification, tier to cool; after 90 days, tier to archive (on an LRS/GRS/RA-GRS account) with daysAfterLastTierChangeGreaterThan so a log someone rehydrates is left online; after 365 days, delete. Add a version action that deletes previous versions after 30 days if versioning is on. Pair it with blob and container soft delete for human error, and the account manages cost and recovery without scripts.