Shared Access Signatures and Lifecycle Policies

A Shared Access Signature (SAS) is a URI that grants restricted access rights to Azure Storage resources (blobs, files, queues, tables) without exposing the storage account key. It is a token appended to the storage service URL that includes authentication information and permissions. The SAS token is signed using either the storage account key (for account-level and service-level SAS) or a user delegation key (for user delegation SAS).

SAS tokens are essential for scenarios where you need to grant temporary, scoped access to storage resources—for example, allowing a client to upload a file directly to a blob container without giving them the full account key. The exam expects you to know the three types of SAS:

When you create a SAS token, you specify the following parameters:

The token is appended to the resource URI as query parameters. For example:

https://mystorageaccount.blob.core.windows.net/mycontainer/myblob.txt?sv=2018-03-28&ss=b&srt=sco&sp=rwdlac&se=2019-05-05T14:00:00Z&st=2019-05-04T14:00:00Z&spr=https&sig=...

When a request arrives with a SAS token, the Azure Storage service reconstructs the string-to-sign using the same parameters, computes the HMAC-SHA256 hash, and compares it to the provided signature. If they match and the token's constraints (time, IP, protocol) are satisfied, the request is allowed. If the signature does not match or any constraint is violated, the request is denied with a 403 (Forbidden) error.

A stored access policy is a JSON object stored on a container (blob), queue, table, or share that defines the start time, expiry time, and permissions for a SAS. By referencing a stored access policy via the signedidentifier parameter in the SAS token, you can revoke or modify the SAS without recreating the token—simply change the policy on the server side. This is a key security feature: if a SAS token is compromised, you can revoke it by deleting or modifying the stored access policy. Without a stored access policy, the only way to revoke a SAS is to regenerate the storage account key, which invalidates all SAS tokens signed with that key.

The stored access policy has an identifier (a unique string up to 64 characters) and the following fields:

Example of a stored access policy via REST API:

{
  "Id": "policy1",
  "Policy": {
    "Start": "2025-01-01T00:00:00Z",
    "Expiry": "2025-12-31T23:59:59Z",
    "Permission": "rw"
  }
}

In .NET, using the Azure.Storage.Blobs library:

BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);
BlobContainerClient containerClient = blobServiceClient.GetBlobContainerClient("mycontainer");
BlobClient blobClient = containerClient.GetBlobClient("myblob.txt");

// Generate service-level SAS for a blob
BlobSasBuilder sasBuilder = new BlobSasBuilder()
{
    BlobContainerName = "mycontainer",
    BlobName = "myblob.txt",
    Resource = "b", // b for blob, c for container
    ExpiresOn = DateTimeOffset.UtcNow.AddHours(1)
};
sasBuilder.SetPermissions(BlobSasPermissions.Read);

Uri sasUri = blobClient.GenerateSasUri(sasBuilder);
Console.WriteLine($"SAS URI: {sasUri}");

In Python, using the Azure Storage Blob SDK:

from datetime import datetime, timedelta
from azure.storage.blob import BlobServiceClient, generate_blob_sas, BlobSasPermissions

connection_string = "..."
blob_service_client = BlobServiceClient.from_connection_string(connection_string)
container_client = blob_service_client.get_container_client("mycontainer")
blob_client = container_client.get_blob_client("myblob.txt")

sas_token = generate_blob_sas(
    account_name=blob_client.account_name,
    container_name=blob_client.container_name,
    blob_name=blob_client.blob_name,
    account_key=blob_service_client.credential.account_key,
    permission=BlobSasPermissions(read=True),
    expiry=datetime.utcnow() + timedelta(hours=1)
)

sas_url = f"{blob_client.url}?{sas_token}"
print(f"SAS URL: {sas_url}")

Azure Storage lifecycle management allows you to define rules that automatically move blobs to cooler storage tiers (hot, cool, cold, archive) or delete them based on age or last modification time. This reduces storage costs and automates data retention policies. Lifecycle policies apply to blobs in Blob Storage and Azure Data Lake Storage Gen2 (hierarchical namespace enabled).

A lifecycle policy is a JSON document that contains one or more rules. Each rule has:

Filters: Define which blobs the rule applies to. You can filter by: - blobTypes: An array of blob types (e.g., ["blockBlob"]). - prefixMatch: An array of path prefixes (e.g., ["logs/", "backup/"]). - blobIndexMatch (optional): An array of key-value pairs for blob index tags.

Actions: Define what to do. Actions include: - baseBlob: Actions for the base blob (not snapshots or versions). Possible sub-actions: - tierToCool: Move to cool tier after a number of days. - tierToCold: Move to cold tier (preview). - tierToArchive: Move to archive tier. - delete: Delete the blob. - snapshot: Actions for snapshots (similar sub-actions). - version: Actions for previous versions (similar sub-actions).

Each action has a daysAfterModificationGreaterThan property (for base blobs) or daysAfterCreationGreaterThan (for snapshots/versions) that specifies the number of days after the blob was last modified or created.

Example lifecycle policy that moves blobs in the "logs/" prefix to cool tier after 30 days and deletes them after 90 days:

{
  "rules": [
    {
      "name": "logRetention",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["logs/"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "delete": {
              "daysAfterModificationGreaterThan": 90
            }
          }
        }
      }
    }
  ]
}

Azure Storage runs the lifecycle policy evaluation once per day. It scans all blobs in the storage account that match the rule filters and checks the last modification time (or creation time for snapshots/versions). If the condition is met, it performs the action. For tiering actions, the blob is moved to the target tier; for delete actions, the blob is permanently deleted. There is no charge for the policy evaluation itself, but you pay for the storage operations (change tier, delete) at standard rates.

Important considerations:

SAS tokens can be used to grant access to blobs that are subject to lifecycle policies. For example, you can generate a SAS token that allows read access to a container, and lifecycle policies will still automatically tier or delete blobs in that container. The SAS token does not affect lifecycle operations. However, if a blob is deleted by a lifecycle policy, any existing SAS tokens for that blob become invalid (the blob no longer exists).

A SaaS company allows customers to upload profile pictures and documents. Instead of sending files through the web server (which would consume bandwidth and CPU), the web app generates a service-level SAS token with write-only permissions to a specific container, expiring in 5 minutes. The client uploads directly to Azure Blob Storage using the SAS URI. This offloads traffic from the web server, reduces latency, and avoids exposing the storage account key. The company uses stored access policies on the container to centrally manage permissions and quickly revoke access if needed. They also restrict the SAS to HTTPS and to the client's IP range (if known). Misconfiguration: If the SAS token has too broad permissions (e.g., delete) or a long expiry, a malicious user could delete other blobs. They learned this the hard way when a customer's token was leaked and an attacker deleted files. Now they use short-lived tokens and stored access policies.

A financial services firm generates gigabytes of log files daily. They store logs in hot tier for the first 30 days (for active analysis), then move to cool tier for 60 days (for compliance), then to archive tier for 7 years (for regulatory retention), and finally delete. They implement a lifecycle policy with three rules: (1) after 30 days, tier to cool; (2) after 90 days (30+60), tier to archive; (3) after 7 years, delete. The policy uses prefix filters like logs/app1/ and logs/app2/. This automation saves 70% on storage costs compared to keeping everything in hot tier. Performance consideration: When logs are in archive tier, retrieval takes hours (rehydration). The firm ensures that any automated processes that need to access archived logs are designed to handle this delay. Misconfiguration: Initially, they set the archive transition too early (e.g., 30 days), causing frequent rehydration costs and user complaints. They adjusted the rules based on access patterns.

A research team uses Azure Data Lake Storage Gen2 for large datasets. They need to grant temporary access to external collaborators for specific folders. They generate user delegation SAS tokens (signed with Azure AD) for read-only access to a directory prefix, expiring in 24 hours. The tokens are distributed via a secure portal. User delegation SAS is preferred because it does not require sharing the storage account key and integrates with Azure AD RBAC. The team also uses stored access policies on the container to quickly revoke access if a collaborator's credentials are compromised. Scaling: With thousands of collaborators, they automate SAS generation via Azure Functions triggered by an approval workflow. Misconfiguration: They once forgot to set an expiry, creating a token that lasted indefinitely until they noticed excessive read requests. Now they enforce a maximum 24-hour expiry and use Azure Policy to audit SAS tokens.