Azure Files and Blob Storage for AZ-104: Tiers, Recovery and Lifecycle

Introduction

Azure Files and Blob Storage management for AZ-104 combines file-share provisioning, blob tiers, data recovery and lifecycle policies. This lesson completes the skills area Implement and manage storage (15–20% of the exam). The study guide objective is configure Azure Files and Azure Blob Storage: create and configure a file share, create and configure a container, configure storage tiers, configure soft delete for blobs and containers, configure snapshots and soft delete for Azure Files, configure blob lifecycle management, and configure blob versioning.

The lessons on Azure Storage access controls and storage account types and redundancy established the account-level design. Now you work at the level of the data services themselves. Azure Files gives you managed SMB and NFS file shares that replace on-premises file servers. Azure Blob Storage holds unstructured objects (documents, images, logs, backups) at very low cost per gigabyte. The exam tests whether you can pick the right tier, protect data against accidental deletion, and automate cost control without losing data you still need.

After this lesson you will be able to create file shares and containers, choose and change access tiers, enable the right combination of soft delete, versioning and snapshots for a recovery requirement, and write a lifecycle management rule that moves and deletes data automatically.

Learning objectives

• Create an Azure Files share, choose its tier, and mount it over SMB or NFS.
• Create a blob container, choose its public access level, and distinguish block, append and page blobs.
• Compare the Hot, Cool, Cold and Archive access tiers, including minimum retention periods and rehydration.
• Configure soft delete for blobs, containers and file shares, and explain what each one protects.
• Use snapshots and blob versioning, and explain how they differ from soft delete.
• Write and interpret a lifecycle management policy.

Azure Files

Azure Files provides fully managed file shares in the cloud. The classic Microsoft.Storage model places shares inside storage accounts and is the model used by the CLI examples below. Current NFS documentation also describes standalone Microsoft.FileShares resources, which do not require a storage account; check their distinct feature support before choosing that model. Clients mount a share over SMB (versions 3.x are recommended; SMB 3.x provides encryption in transit), over NFS 4.1 (Linux workloads, available on premium shares only), or access it through the REST API.

File share media, billing models and tiers

The table shows the familiar premium SSD choice and HDD pay-as-you-go tiers. Azure Files also offers provisioned v2 for HDD and SSD, allowing capacity, IOPS and throughput to be provisioned independently; Microsoft recommends v2 for new file-share deployments. Do not equate every standard/HDD share with pay-as-you-go billing. In the classic model, GPv2 accounts provide HDD pay-as-you-go shares; FileStorage configurations support provisioned models. A pay-as-you-go account can contain shares with different Transaction optimized, Hot and Cool tiers. Changing media from HDD to SSD requires a new share and a data copy.

Key properties when you create a share:

• Name: 3–63 characters, lowercase letters, digits and hyphens.
• Quota: maximum size of the share. For pay-as-you-go shares, quota is a capacity cap and used storage drives capacity charges. Provisioned models bill configured capacity/performance; in v2, provisioned storage, IOPS and throughput are separate settings.
• Protocol: SMB or NFS. NFS 4.1 requires SSD shares and uses network restrictions plus POSIX UID/GID permissions and root squash, rather than SMB identity authentication. Do not disable secure transfer as a blanket NFS prerequisite: current Azure Files supports TLS through the AZNFS mount helper, with protocol-specific encryption-in-transit settings. A plain kernel NFS mount cannot satisfy a TLS-required configuration.

For example, create a Hot SMB share in an existing classic GPv2 pay-as-you-go account:

az storage share-rm create --resource-group rg-files --storage-account stcontosofiles \
  --name teamshare --enabled-protocols SMB --quota 100 --access-tier Hot

This management-plane command needs share write permissions; mounting and reading files require separate data authorization and network access.

Mounting a share

For an administrative Shared Key mount over SMB on Windows, the portal generates a PowerShell script such as:

$connectTestResult = Test-NetConnection -ComputerName stcontosofiles.file.core.windows.net -Port 445
if ($connectTestResult.TcpTestSucceeded) {
    cmd.exe /C "cmdkey /add:`"stcontosofiles.file.core.windows.net`" /user:`"localhost\stcontosofiles`" /pass:`"<storage-account-key>`""
    New-PSDrive -Name Z -PSProvider FileSystem -Root "\\stcontosofiles.file.core.windows.net\teamshare" -Persist
} else {
    Write-Error -Message "Unable to reach the Azure storage account via port 445."
}

SMB uses TCP port 445. Many consumer ISPs and some corporate firewalls block outbound 445. If the test fails, check DNS, routing, network rules and port reachability. If internet TCP 445 is blocked, use a VPN or ExpressRoute path to a file private endpoint; the endpoint alone does not bypass the blocked internet port. Using the storage account key to mount gives full control over the share and is not suitable for end users; for per-user permissions use identity-based authentication (on-premises AD DS, Microsoft Entra Domain Services, or Microsoft Entra Kerberos for supported hybrid or cloud-only identities), which you studied in the access lesson. Share-level access is then granted with Azure RBAC roles such as Storage File Data SMB Share Contributor, and file-level permissions are Windows NTFS ACLs.

For Linux NFS shares, use the documented AZNFS helper when TLS is required. Native mount -t nfs with NFS 4.1 options is appropriate only for a configuration that explicitly permits non-TLS NFS; keep the network restricted in either case.

Azure File Sync (awareness)

Azure File Sync turns a Windows Server into a cache of an Azure file share. Files that are rarely used are tiered to the cloud and replaced by pointers; the full namespace stays visible locally. The AZ-104 does not go deep on it, but you should recognize it as the answer to "keep local file-server performance while centralizing data in Azure".

Snapshots and soft delete for file shares

Two features protect file shares:

• Share snapshots are read-only, point-in-time copies of an entire share. They are incremental: only data that changed since the previous snapshot is stored, so cost stays low. A share supports up to 200 snapshots. Users can restore previous file versions from Windows Explorer (Previous Versions) or you can restore from the portal. Deleting a share that has snapshots requires explicitly including those snapshots in the delete operation. With share soft delete enabled, undeleting the share restores its contents and snapshots during retention. Snapshot-based Azure Backup uses share snapshots; vaulted backup is a separate protection option.
• Soft delete for file shares protects against deletion of the whole share. A deleted share is kept in a deleted state for a retention period of 1 to 365 days and can be undeleted from the portal. It is enabled by default for new storage accounts with a 7-day retention. Soft delete does not protect individual files that were overwritten or deleted inside a share; snapshots do.

Exam tip: "A user accidentally deleted a file" → restore from a share snapshot (or Azure Backup). "An administrator accidentally deleted the entire share" → soft delete for file shares.

Azure Blob Storage

Blob Storage stores objects in containers. The hierarchy is storage account → container → blob. Container names are 3–63 characters, lowercase letters, digits and hyphens. Blob names can include slashes to simulate folders (a flat namespace, unless hierarchical namespace for Data Lake Storage Gen2 is enabled).

Blob types

The blob type is chosen when the blob is created and cannot be changed. Access tiers (including Archive) apply to block blobs.

Public access level of a container

A container has one of three access levels: Private (no anonymous access, the default), Blob (anonymous read of a blob if the caller knows its URL), and Container (anonymous read and listing of the container's blobs). Anonymous access works only if the storage account setting Allow Blob anonymous access is enabled. Disabling that account-level setting overrides every container and is the recommended secure default; you reviewed it in the lesson on access to storage.

Create a private container with Entra data permissions, such as Storage Blob Data Contributor:

az storage container create --account-name stcontosoprod01 --name marketing \
  --public-access off --auth-mode login

Worked example: publishing marketing images

Scenario. Contoso wants product images served to anyone on the internet, but wants to prevent anyone from listing the container contents.

Reasoning.

1. Anonymous access must be allowed on the storage account (Allow Blob anonymous access = Enabled).
2. The container must allow anonymous read of blobs only, which is the Blob access level. The Container level would also allow listing.
3. Private would require a SAS token or Entra ID on every request, which contradicts "anyone on the internet".

Solution. Enable anonymous access on the account and set the container access level to Blob.

Why the others are weaker. Container exposes the full listing of images, including unreleased products. Private plus a long-lived SAS works but forces every page to embed tokens and gives no simple revocation path. This answer assumes clients read directly from Blob Storage. A CDN or proxy with an authenticated private origin is another architecture and can serve public content without enabling anonymous origin access.

Access tiers

Access tiers trade storage price against access price. You pay less per GB at the cooler tiers, and more per read.

Key facts:

• The account default access tier for GPv2 can be Hot, Cool or Cold. Blobs without an explicit tier inherit it. You can set a tier on an individual blob (Hot, Cool, Cold or Archive) which overrides the default.
• Archive is offline. You cannot read an archived blob. To use it you must rehydrate it, either by changing its tier to Hot, Cool or Cold (Set Blob Tier) or by copying it to a new blob in an online tier (Copy Blob). Rehydration takes hours: Standard priority can take up to 15 hours, and High priority is faster (typically under one hour for objects smaller than 10 GB) at a higher price.
• Early deletion fee. Deleting or moving a blob out of Cool, Cold or Archive before the minimum retention period is billed for the remaining days.
• Hot/Cool/Cold/Archive tier assignment applies only to supported block blobs. Append and page blobs do not inherit these block-blob tiers. Premium block-blob data cannot use these standard access tiers in place; copy it to a compatible standard account if tiering is required. Archive is supported with LRS, GRS or RA-GRS, not ZRS/GZRS/RA-GZRS, and is incompatible with blob encryption scopes.

Worked example: choosing a tier

Scenario. Fabrikam stores monthly audit exports. They are read twice in the first month, almost never afterward, but must be kept for seven years for compliance. Retrieval within 24 hours is acceptable for old exports.

Reasoning.

1. First month, occasional reads → Hot or Cool. Compare the region's storage, read, retrieval and transaction charges: two reads alone do not prove Cool is cheaper. For this example, assume Hot during the active month.
2. After month 1 the data is almost never read and the retrieval delay is acceptable → Archive is the cheapest storage.
3. Doing this by hand for every blob is error-prone, so a lifecycle management rule moves blobs automatically: Cool after 30 days and Archive after 90 days. A separate retention control prevents premature deletion; schedule cleanup only after the required retention expires. A fixed 2,555-day timer is not always seven calendar years because of leap days.

Why not keep everything Hot? It meets the requirement but costs several times more over seven years. Why not Archive from day one? The two reads in the first month would each need rehydration, which takes hours, and the early deletion rules punish any mistake.

Protecting blob data

Azure offers four overlapping mechanisms. The exam loves asking which one fits.

Soft delete for blobs and containers

When blob soft delete is enabled, a deleted blob (or a blob overwritten with a new one, when versioning is off) is retained in a soft-deleted state. You choose the retention period from 1 to 365 days. Restoring is done with Undelete in the portal, with az storage blob undelete or with PowerShell. Container soft delete is a separate setting: it protects against the deletion of the container itself, which blob soft delete does not.

az storage account blob-service-properties update \
  --account-name stcontosoprod01 --resource-group rg-prod \
  --enable-delete-retention true --delete-retention-days 14 \
  --enable-container-delete-retention true --container-delete-retention-days 14

Soft-deleted data is billed at the same rate as active data until the retention period ends.

Snapshots

A blob snapshot is a read-only copy of a blob taken at a moment in time. Its name is the blob URI plus a snapshot=<DateTime> value. You can read, copy or delete a snapshot, but not modify it. A snapshot is billed only for blocks that differ from the base blob. A blob that has snapshots cannot be deleted unless you also delete the snapshots (--delete-snapshots include).

Blob versioning

When versioning is enabled, supported write operations create a version identified by a version ID. Not every low-level operation creates one (for example staging blocks alone does not). The latest is the current version. Overwriting a blob creates a new previous version; deleting the current version makes it a previous version and the blob appears deleted. You can restore by promoting a previous version (copy it over the current version) or reading it directly by version ID.

Important interactions:

• Versioning removes the need to take manual snapshots for most "undo" scenarios, because versions are created automatically.
• With versioning enabled and blob soft delete also enabled, deleted versions remain recoverable for the soft-delete retention period.
• Point-in-time restore for eligible Hot/Cool block blobs in a standard GPv2 account without hierarchical namespace requires three prerequisites: soft delete for blobs, change feed and blob versioning. Its retention must be at least one day shorter than blob soft-delete retention. It restores blob data ranges, not deleted container or account resources. Blob versioning is also unsupported in HNS accounts; do not apply this combined design unchanged to Data Lake Storage.
• Many versions raise storage cost, so pair versioning with a lifecycle rule that tiers or deletes old versions.

Exam tip: When a question asks for automatic protection from overwrite with the ability to restore any earlier state of a blob, the answer is versioning. When it asks for protection from deletion only, with a time-limited safety net, the answer is soft delete. Manual and point-in-time copies of a single blob suggest snapshots.

Immutable storage (awareness)

Immutability policies (time-based retention and legal hold) make blobs write-once, read-many (WORM). They are used for regulatory requirements where even administrators must not delete data before a retention period. Soft delete and versioning provide recovery, rather than an enforced WORM retention guarantee. Lock a time-based immutability policy after testing so administrators cannot shorten or remove it while retention is active. Immutability does not preserve data forever after the configured retention ends.

Lifecycle management

A lifecycle management policy is a JSON document of rules attached to a storage account. A rule has a filter set and actions.

• Filters: blobTypes (blockBlob, appendBlob), prefixMatch (container name and optional blob prefix), and blobIndexMatch (blob index tags).
• Actions on the base blob: tierToCool, tierToCold, tierToArchive, delete. Conditions are expressed as: daysAfterModificationGreaterThan, daysAfterCreationGreaterThan, daysAfterLastAccessTimeGreaterThan (requires last access time tracking to be enabled on the account) and daysAfterLastTierChangeGreaterThan.
• Actions can also target snapshots and versions (for example delete versions older than 90 days).

{
  "rules": [
    {
      "enabled": true,
      "name": "age-out-audit-exports",
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "audit/exports" ]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 },
            "delete": { "daysAfterModificationGreaterThan": 2557 }
          },
          "version": {
            "delete": { "daysAfterCreationGreaterThan": 90 }
          }
        }
      }
    }
  ]
}

The JSON is a cleanup example, not a regulatory retention guarantee. Previous-version age is measured from the version's original creation, not from the date it became noncurrent. The 90-day version rule can therefore delete an old version soon after an overwrite; choose retention according to the actual recovery requirement. Current-version cleanup also waits for prior versions and snapshots to be removed.

Rules to remember:

• Lifecycle processing is asynchronous. A new or changed policy can take up to 24 hours before its first run starts; large accounts and workload pressure can delay completion. A threshold makes an object eligible, rather than scheduling an exact deletion time.
• A rule must define at least one action. If several actions apply to the same blob, the cheapest action wins (delete is applied before archive, archive before cool).
• Tier-transition actions are not supported on premium block blob accounts; deletion is.
• Append blobs support deletion only.
• Moving blobs using lifecycle rules is billed as set-tier operations, and respects the minimum retention periods (early deletion fees may apply).
• Microsoft also documents smart tier for automatic movement between online Hot, Cool and Cold tiers based on access patterns. This is distinct from the explicit lifecycle conditions taught here; match its documented eligibility to the workload rather than treating it as Archive rehydration.

Worked example: interpreting a policy

Scenario. A policy has one rule with tierToCool at 30 days since last modification, tierToArchive at 60 days, and delete at 365 days, with prefix logs/. Assume a compatible standard account, no versions/snapshots or immutability restriction, and completed policy runs after each threshold. A block blob logs/app.log was last modified 70 days ago. What action is eligible now, and what happens after 365 days?

Reasoning.

1. At 70 days both the cool (30) and archive (60) conditions are satisfied; the archive action is the later, cooler tier, so an evaluation selects Archive; a completed successful run places it there.
2. Once age is greater than 365 days, deletion is eligible and a later run removes the blob (or soft-deletes it if configured). Because the blob has been in Archive since day 60, the 180-day minimum is satisfied (about 305 days).
3. An archived blob cannot be edited directly. Rehydrate it before updates; a later content write resets last-modified time. Rehydration alone does not reset last-modified time, so use daysAfterLastTierChangeGreaterThan on the Archive action to avoid immediately rearchiving restored data.

Why not "still Cool"? Conditions are independent; the Archive condition is met, so it applies.

Comparison: protection tool for the situation

Pitfalls and exam tips

• Archive tier is not a default tier. The GPv2 account default can be Hot, Cool or Cold. Archive is set per blob or by lifecycle rule.
• Rehydration is not instant. If a scenario needs data back within minutes, Archive is wrong unless High priority rehydration of a small blob is accepted.
• Soft delete for containers is separate from soft delete for blobs. Enabling one does not enable the other.
• File share soft delete does not recover files inside the share. Use snapshots.
• Port 445. A mount that fails from home but works from the office is almost always an ISP block of port 445.
• Last access time rules require access tracking to reflect per-blob reads. A null LastAccessTime can use the date tracking was enabled; missing timestamps do not prove the rule can never execute.
• Lifecycle processing is asynchronous. Monitor completed runs rather than expecting an immediate move or an exact daily deadline.
• Minimum retention periods are the source of early deletion charges; avoid designing rules that bounce data between tiers.
• Both HDD and SSD shares have provisioned options. Pay-as-you-go HDD tiers charge for used capacity; provisioned v2 charges configured capacity, IOPS and throughput.

Mini case study: Northwind document platform

Northwind runs a document platform with these requirements:

1. Final scanned invoices arrive in invoices. They are read often for 30 days, then rarely, and must be protected from alteration/deletion for at least seven calendar years. Retrieval of older archived invoices may take hours.
2. Staff edit separate working documents in working. Versions originally created within the last 90 days must remain recoverable after supported overwrites.
3. After a whole-container deletion last quarter, the team wants future container deletions to be recoverable for 14 days. This cannot recover a historical deletion that preceded protection.
4. The finance team uses an SMB share mounted from branch offices. One user accidentally deleted a spreadsheet yesterday and an administrator wants to restore it.

Proposed solution.

• Use a compatible flat-namespace account, enable blob versioning, and scope a previous-version cleanup rule to working/, deleting versions older than 90 days from their creation. Enable blob soft delete for 14 days as an extra net. This is not a promise of 90 days after a version becomes noncurrent.
• Enable container soft delete with 14-day retention.
• Protect finalized invoices with a tested, locked time-based immutability policy whose configured duration covers at least seven calendar years. Use a compatible LRS/GRS/RA-GRS account if Archive is required. Add tiering for invoices/: Cool after 30 days, Archive after 180 days. Do not copy the 90-day working-version cleanup to invoices, and arrange deletion separately after retention/holds permit it; lifecycle deletion does not operate on blobs in immutable containers.
• For the finance share, restore the spreadsheet from a share snapshot (and schedule daily snapshots through Azure Backup).

Commentary. Versioning provides accessible history for supported overwrites; blob soft delete without versioning can also retain soft-deleted overwrite snapshots, but is not the same version-history design. Locked immutability, rather than a delayed lifecycle delete alone, enforces the finalized-invoice retention requirement. Container soft delete is required for requirement 3; blob soft delete does not restore containers. Archive is acceptable because retrieval after 180 days can wait for rehydration. Soft delete for file shares would not have helped the user who deleted just one file.

For the backup options that complement snapshots and soft delete, see Azure backup and disaster recovery.

Key terms

• Share snapshot: incremental read-only copy of an Azure file share.
• Soft delete: retention of deleted objects for a configurable period (1–365 days).
• Access tier: Hot, Cool, Cold or Archive pricing level for a block blob.
• Rehydration: moving an archived blob to an online tier so it can be read.
• Blob version: automatically preserved earlier state of a blob.
• Lifecycle management: rule-based automation of tiering and deletion.
• Early deletion fee: charge for removing data before the tier's minimum retention.
• Immutable storage: WORM policy preventing modification or deletion.

Summary checklist

• I can choose between Premium, Transaction optimized, Hot and Cool file share tiers.
• I know SMB uses port 445 and what to do when it is blocked.
• I can distinguish file share snapshots from soft delete for file shares.
• I know the three container access levels and the account-level anonymous access switch.
• I remember minimum retention: Cool 30, Cold 90, Archive 180 days.
• I know Archive is offline and how rehydration works.
• I can pick among soft delete, versioning, snapshots and point-in-time restore.
• I can read and write a lifecycle management rule.

Official sources

• AZ-104 study guide: https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/az-104 (opens in a new tab)

• Azure Blob Storage lifecycle management overview: https://learn.microsoft.com/en-us/azure/storage/blobs/lifecycle-management-overview (opens in a new tab)

• Access tiers best practices: https://learn.microsoft.com/en-us/azure/storage/blobs/access-tiers-best-practices (opens in a new tab)

• Lifecycle management policy structure: https://learn.microsoft.com/en-us/azure/storage/blobs/lifecycle-management-policy-structure (opens in a new tab)

• Plan Azure Files media and billing models (opens in a new tab)

• Azure Files billing models (opens in a new tab)

• NFS support and encrypted mounts (opens in a new tab)

• Azure file-share snapshots (opens in a new tab)

• File-share soft delete (opens in a new tab)

• Blob access tiers and defaults (opens in a new tab)

• Blob soft-delete behavior (opens in a new tab)

• Blob versioning limits (opens in a new tab)

• Point-in-time restore eligibility (opens in a new tab)

• Locked immutable retention (opens in a new tab)