Lesson 07 — Azure Blob Storage: Access, Lifecycle & Security

Domain 2 — Storage AZ-104: 15–20% ~30 min Prereq: Lesson 06 — Storage Accounts

Why Blob Storage Deserves Its Own Lesson

Blob storage is the most-used Azure storage service. Every application generating unstructured data — images, videos, logs, backups, telemetry exports, build artefacts — stores it in blob storage. The exam tests it at a depth that surprises many candidates: SAS token types and revocation mechanics, the precise behaviour of Archive rehydration, lifecycle management rule structure, and the interactions between soft delete, versioning, and immutability policies.

Beyond the exam, getting SAS token architecture wrong is one of the most common storage security vulnerabilities in real-world Azure deployments. Understand the three SAS types and when each one is appropriate.

Blob Types

A blob storage account organises data as: storage account → containers → blobs. You choose a blob type at creation — it cannot be changed afterwards.

TypeOptimised forMax sizeCommon use
Block blob Sequential read/write of large files 190.7 TiB Images, videos, backups, build artefacts, general unstructured data
Append blob Append-only operations (existing blocks immutable) 195 GiB Application logs, audit logs, diagnostic streams
Page blob Random read/write access 8 TiB VHD files for unmanaged VM disks (legacy — use Managed Disks)
Use append blobs for logs Append blobs are the only blob type where you can add data to the end without reading and rewriting the entire blob. Applications writing logs should use append blobs. Block blobs require a full download-modify-upload cycle to append — at log scale this is catastrophically inefficient.

Container Public Access Levels

Containers have a public access setting that controls anonymous (unauthenticated) access:

LevelAnonymous access permitted
Private (default)None — all requests require authentication
BlobAnonymous read of individual blobs if you know the URL — no container listing
ContainerAnonymous read of blobs AND anonymous listing of the container contents
Storage account-level anonymous access override Even if a container is set to Blob or Container access level, if the storage account has blob public access disabled at the account level, all anonymous access is blocked. The account-level setting takes precedence over the container-level setting. In production, disable anonymous blob access at the account level as a baseline security control.

Blob URL Structure

https://<accountname>.blob.core.windows.net/<container>/<blob-path>

Example:
https://mystorageaccount.blob.core.windows.net/images/profile/user-12345.jpg

Blob Access Tiers In Depth

Archive Tier: Rehydration

Archive-tier blobs are stored offline — the data is not available for reads until the blob is rehydrated to an online tier (Hot, Cool, or Cold). Rehydration works in two ways:

  1. Copy to new blob: use Copy Blob to copy the archived blob to a new online-tier blob. The original archive blob remains. This is the preferred approach as it is non-destructive.
  2. Change tier in-place: set the blob's tier directly to Hot or Cool. The blob transitions in place.
Rehydration priorityDurationSize constraint
Standard Up to 15 hours No limit
High Within 1 hour Objects under 10 GiB only
Archive blobs return 409 on direct read attempts If an application tries to read a blob in the Archive tier without rehydrating first, it receives HTTP 409 (Conflict). There is no automatic background rehydration on read — the operation simply fails. Applications must handle this explicitly: check tier before reading, or implement retry logic after initiating rehydration.

Tier Transitions

You can move blobs between any tier. Moving to a colder tier (hot → archive) is instant — no data movement latency. Moving to a warmer tier from archive requires rehydration as described above. Minimum storage duration penalties apply on early transitions to warmer tiers just as they do for deletions.

Lifecycle Management Policies

Lifecycle management policies automate blob tier transitions and deletions based on age criteria. They are defined as JSON rules and evaluated daily — Azure scans the storage account and applies matching rules.

Rule Structure

Each rule has three components:

  • Filters: scope which blobs the rule applies to — by blob type (blockBlob, appendBlob), by prefix match (e.g. logs/), by minimum/maximum blob size.
  • Actions: what to do — tierToCool, tierToCold, tierToArchive, or delete.
  • Conditions: the age trigger — daysAfterModificationGreaterThan, daysAfterCreationGreaterThan, or daysAfterLastAccessTimeGreaterThan (requires last access time tracking to be enabled).
Last access time tracking adds overhead Access-time-based lifecycle rules require enabling last access time tracking on the storage account. This adds a small performance and cost overhead because Azure must update the last-access timestamp on every read operation. Only enable it if you genuinely use access-time-based policies.

Example Lifecycle Policy JSON

{
  "rules": [
    {
      "name": "tiering-rule",
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["data/"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 },
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        }
      }
    }
  ]
}

This policy targets block blobs under the data/ prefix and: moves them to Cool after 30 days, to Archive after 90 days, and deletes them after 365 days of inactivity — all without any manual intervention.

Lifecycle Rules for Versions and Snapshots

Lifecycle management rules can also target blob versions and snapshots separately from the current version. This is important when blob versioning is enabled: previous versions accumulate and incur storage costs. A separate rule can archive or delete previous versions after a defined period.

Shared Access Signatures (SAS)

A SAS is a URI with embedded query parameters that grants scoped, time-limited access to storage resources without sharing the account key. This is the standard mechanism for granting third-party or temporary access to specific blobs or containers.

The Three SAS Types

TypeSigned withScopeSecurity level
Account SAS Storage account key Multiple services in one account Lowest — key compromise invalidates all account SAS
Service SAS Storage account key One service (e.g. one blob container) Medium — tighter scope but still key-signed
User Delegation SAS Entra ID credentials Blob and ADLS Gen2 only Highest — no account key involved; backed by identity
Always prefer User Delegation SAS User Delegation SAS (UDS) is the most secure SAS type because it is not signed with a storage account key. Even if the SAS URI is leaked, rotating the account key does not invalidate it — but revoking the user's access in Entra ID or waiting for UDS expiry does. For Blob and ADLS Gen2 workloads, there is no reason to use an Account or Service SAS if you have Entra ID identities available.

SAS Key Parameters

A SAS URI includes these query parameters (abbreviated):

  • sp — signed permissions: r=read, w=write, d=delete, l=list, a=add, c=create
  • st / se — start time and expiry time (ISO 8601)
  • sip — allowed IP addresses or ranges
  • spr — protocol restriction (https only in production — never allow HTTP)
  • sig — the HMAC-SHA256 signature computed from the parameters

Stored Access Policies

A Stored Access Policy is a named policy defined on a container (or queue/table/file share). You attach a Service SAS to a Stored Access Policy instead of baking the permissions and expiry directly into the SAS URI. The benefit: you can revoke the SAS by deleting the policy, without rotating the storage account key.

Revoking a SAS — The Full Matrix

SAS typeHow to revoke immediately
Account SAS or Service SAS (no stored policy) Rotate the storage account key used to sign it — invalidates ALL SAS signed with that key
Service SAS with Stored Access Policy Delete or modify the Stored Access Policy on the container
User Delegation SAS Revoke the user's Entra ID permissions, or wait for expiry. Rotating the key has no effect.
Rotating keys invalidates ALL key-signed SAS simultaneously When you rotate a storage account key, every Account SAS and Service SAS signed with that key — across all applications, all environments — becomes invalid instantly. Before rotating, audit all consumers of key-signed SAS and have a plan for issuing new ones. This is a significant operational risk, which is another reason to prefer User Delegation SAS and Entra ID-based access.

Data Protection Features

Azure Blob Storage has multiple overlapping data protection capabilities. Understanding when to use each — and how they interact — is critical for both production design and exam questions.

Protection Feature Overview

FeatureProtects againstRecovery method
Soft delete (blobs) Accidental blob deletion or overwrite Undelete within retention period (1–365 days)
Soft delete (containers) Accidental container deletion (must enable separately) Undelete container within retention period
Blob versioning Overwrites — each write creates a new version Promote any previous version to current
Point-in-time restore Bulk accidental delete or corruption across blobs Restore all block blobs to a past timestamp
Immutability (WORM) Regulatory requirement — blobs cannot be modified or deleted N/A — data cannot be altered until policy expires
Change feed Audit trail — durable ordered log of all blob changes Replay log for event-driven recovery or auditing

Point-in-Time Restore Dependencies

Point-in-time restore for block blobs requires all three of the following to be enabled on the storage account:

  1. Blob versioning — maintains previous states
  2. Blob soft delete — protects deleted blobs during the restore window
  3. Change feed — provides the ordered change log that restoration uses

The restore point cannot be older than the soft delete retention period and cannot be more recent than the last 15 minutes (to allow change feed propagation).

Immutability Policies (WORM)

WORM (Write Once Read Many) compliance is implemented via two policy types:

  • Time-based retention policy: blobs cannot be modified or deleted until the retention period expires. Can be applied at the container or blob-version level. Can be locked (making the policy itself immutable — required for SEC 17a-4 and similar regulations).
  • Legal hold: blocks modification and deletion indefinitely until the legal hold tag is removed. Used during litigation or regulatory investigation when no defined retention period is known.
Locking an immutability policy is irreversible When you lock a time-based retention policy on a container, you cannot reduce the retention period or delete the policy — you can only extend it. This is intentional (SEC 17a-4 compliance requires it) but means a misconfigured retention period can result in unbillable storage that cannot be deleted for years. Verify the retention period carefully before locking.

Check Your Understanding

Click any option to see immediate feedback. Answers represent correct behaviour in a real Azure environment.

1. A security audit finds your application is using storage account access keys embedded in its configuration. What is the most secure replacement approach?

The most secure approach eliminates secrets entirely. A managed identity authenticates to Azure storage via Entra ID — no key, no SAS, no secret to store, rotate, or leak. DefaultAzureCredential automatically uses the managed identity when running in Azure. Storing keys in Key Vault (option B) still requires a secret to exist and be retrieved. A User Delegation SAS (option C) still has a time-limited URI that can be leaked. Key rotation (option D) reduces the exposure window but does not eliminate the secret.

2. A blob is in the Archive tier. An application tries to read it immediately without rehydrating. What happens?

Archive blobs are physically offline — they are not immediately accessible under any circumstances. Reading an archived blob returns HTTP 409 (Conflict) with error code BlobArchived. There is no automatic rehydration on read. The application must first call SetBlobTier to initiate rehydration (Standard: up to 15 hours; High priority: under 1 hour for blobs under 10 GiB), then poll until the blob is online before reading.

3. You need to ensure a container's blobs cannot be deleted for 7 years to meet compliance requirements. How do you implement this?

Time-based immutability (WORM) policies are the correct answer for compliance retention requirements. They prevent deletion and modification at the storage engine level, not through RBAC or locks. Soft delete (option B) only retains deleted blobs for a maximum of 365 days — insufficient for 7 years. Resource locks (option C) can be removed by anyone with Owner role. RBAC (option D) can be reassigned. Only WORM provides the tamper-resistant protection that compliance frameworks require.

4. You create a Service SAS for a blob container valid for 7 days. After 2 days you discover the SAS URI has been leaked. What is the fastest way to invalidate it?

For a Service SAS (or Account SAS) not backed by a Stored Access Policy, rotating the account key is the only immediate revocation mechanism. This invalidates every SAS signed with that key simultaneously. The operational cost is significant — all other services using that key must be updated. This is why Stored Access Policies (which allow targeted revocation) and User Delegation SAS (which can be revoked via Entra ID) are preferred for production scenarios.

5. You want blobs automatically moved to Archive tier 90 days after last modification, and deleted entirely after 365 days. Which feature implements this?

Lifecycle Management policies are the built-in, serverless, zero-maintenance answer. They evaluate daily and apply tier transitions and deletions automatically based on modification date (or creation date, or last access time if tracking is enabled). Azure Functions (option B) and Automation runbooks (option C) are functional but require you to build and maintain custom code. Azure Backup retention (option D) does not apply to individual blob tiers — it is for backup recovery points.

6. Your application generates append-only log files stored in Azure Blob Storage. Which blob type should you use?

Append blobs are the correct and purpose-built answer. Each append operation adds a new block to the end of the blob — existing blocks are immutable and the operation is atomic. This is ideal for logging. Block blobs (option B) support append via Put Block, but the full-write pattern described is not how the SDK works — the real issue is that block blobs don't have a native append semantic for concurrent writers. Page blobs (option C) are for random I/O. "Standard file blobs" (option D) is not a real blob type.
Primary source for this lesson Introduction to Azure Blob Storage (Microsoft Learn)

Also read: Grant limited access with SAS, Lifecycle management overview, and Immutable blob storage overview.

Questions for your teacher (the AI agent)
This lesson covered blob types, access tiers, SAS tokens, lifecycle management, and data protection. Go deeper on:
  • Walk me through generating a User Delegation SAS using the Azure CLI with specific permissions and a 2-hour expiry.
  • How do I set up point-in-time restore and what are the exact steps to initiate a restoration to a specific timestamp?
  • What is the difference between a versioning delete marker and a soft-deleted blob — how do they interact in Cost Management?
  • Can I apply a lifecycle policy rule specifically to previous blob versions to prevent unbounded version accumulation?
  • How does a legal hold interact with a time-based retention policy on the same container?
Coming up: Lesson 08 — Azure Files: SMB, NFS & Sync The next lesson shifts from unstructured blob storage to structured file shares. Azure Files provides fully managed SMB and NFS file shares in the cloud. We cover share types, authentication (Kerberos vs. on-premises AD DS vs. Entra Kerberos), Azure File Sync for hybrid scenarios, and snapshot management. This is a common exam domain for candidates with a Windows Server background.