Microsoft Azure Certifications (e.g. AZ-104, AZ-900) Implement and Manage Storage (AZ-104) Syllabus

What is a stored access policy and what advantage does it give over an ad-hoc SAS?

A stored access policy is defined on a container/share/table/queue and a service SAS can reference it. It centralizes the SAS's start time, expiry, and permissions, allowing you to modify or immediately revoke the SAS by changing/deleting the policy—something not possible with a standalone ad-hoc SAS (short of regenerating the key).

How can you revoke an active SAS token?

For an ad-hoc SAS: regenerate the signing account key (revokes all SAS signed with it). For a SAS tied to a stored access policy: delete or modify the policy. For a user delegation SAS: revoke the user delegation key (Revoke user delegation keys). You can also set short expiry times to limit exposure.

What is identity-based (Microsoft Entra ID) access to Azure Storage and its key benefit over keys/SAS?

Azure Storage supports authorizing Blob, Queue, Table, and Files requests with Microsoft Entra ID via OAuth tokens and Azure RBAC. Benefits: no secret to leak, fine-grained role assignments, conditional access, and full audit trail tied to a user or managed identity.

Name two common built-in RBAC roles for accessing blob data and the difference between them and the 'Owner' role.

Storage Blob Data Reader (read/list blobs) and Storage Blob Data Contributor (read/write/delete blobs). These data-plane roles grant access to blob data itself. Management roles like Owner/Contributor manage the resource and keys but do NOT, by themselves, grant data-plane (blob content) access via Entra ID.

What identity-based authentication options exist for Azure Files (SMB)?

Azure Files supports three: on-premises Active Directory Domain Services (AD DS), Microsoft Entra Domain Services, and Microsoft Entra Kerberos for hybrid identities. NTFS permissions on files/folders plus share-level RBAC roles (e.g., Storage File Data SMB Share Reader/Contributor/Elevated Contributor) control access.

What encryption protects data at rest in Azure Storage, and is it optional?

All data written to Azure Storage is automatically encrypted at rest using Storage Service Encryption (SSE) with 256-bit AES. It is enabled by default, cannot be disabled, and incurs no additional cost.

Compare Microsoft-managed keys, customer-managed keys, and customer-provided keys for storage encryption.

Microsoft-managed keys: default, Microsoft handles all key management. Customer-managed keys (CMK): you supply/manage keys in Azure Key Vault or Managed HSM for account-level encryption control and rotation. Customer-provided keys (CPK): the client passes a key on each Blob request for per-request encryption.

What is infrastructure encryption in Azure Storage?

An optional second layer of encryption (double encryption) applied at the infrastructure level using a separate Microsoft-managed key, in addition to the standard service-level encryption. It must be enabled at account creation and protects data even if one encryption key is compromised.

What is the structure of the blob storage hierarchy?

Storage account → containers → blobs. A container groups blobs (like a directory at the top level). Blobs live inside containers; flat namespace by default (virtual folders are simulated by '/' in blob names) unless hierarchical namespace (Data Lake Gen2) is enabled.

What are the three types of blobs and their uses?

Block blobs: store text/binary objects up to ~190.7 TiB, optimized for upload/streaming (the default). Append blobs: optimized for append operations like logging. Page blobs: random read/write 512-byte pages up to 8 TiB, used for Azure VM disks (VHDs).

What public access levels can a blob container have?

Private (no anonymous access—default), Blob (anonymous read of blobs only, not container listing), and Container (anonymous read and list of blobs and container metadata). Anonymous access also requires that it be allowed at the account level.

List the Azure Blob storage access tiers and their intended access frequency.

Hot: frequently accessed/hot data, highest storage cost, lowest access cost. Cool: infrequently accessed, stored ≥30 days, lower storage cost, higher access cost. Cold: rarely accessed, stored ≥90 days. Archive: rarely accessed, stored ≥180 days, offline, lowest storage cost but requires rehydration to read.

Which blob access tiers can be set at the account level, and which is blob-level only?

Hot and Cool can be set as the default at the account level (and per blob). Cold and Archive are blob/object-level tiers only—Archive cannot be a default account tier and applies to individual blobs.

What is required to read data from an archived blob, and what are the rehydration priorities?

Archive is offline; the blob must be rehydrated to an online tier (Hot/Cool) or copied to a new online blob. Two priorities: Standard (may take up to ~15 hours) and High (often under 1 hour for objects under 10 GB). The data is unreadable until rehydration completes.

What is a blob lifecycle management policy and what actions can it automate?

A rule-based policy (JSON) on a storage account that automatically transitions blobs between tiers or deletes them based on age/last-modified or last-accessed time. Actions include tierToCool, tierToCold, tierToArchive, delete, and equivalents for snapshots/versions—used to optimize cost.

In a lifecycle policy, what does 'daysAfterModificationGreaterThan' control?

It is the condition specifying the number of days since the blob was last modified (or since creation/last access depending on filter) after which the associated action (tier change or delete) is applied. Example: tierToArchive after $\text{daysAfterModificationGreaterThan} = 180$.

What is blob soft delete and what does it protect against?

Soft delete retains deleted or overwritten blobs (and optionally containers) for a configurable retention period (1–365 days), allowing recovery before permanent deletion. It protects against accidental deletion or overwrite of data.

What is blob versioning and how does it differ from snapshots?

Blob versioning automatically maintains previous versions of a blob each time it is modified or deleted, so you can restore or read earlier states. Snapshots are read-only, manually (or policy) created point-in-time copies. Versioning is automatic on write; snapshots are explicit captures.

What is point-in-time restore for block blobs and what must be enabled for it?

Point-in-time restore lets you restore one or more containers to a prior state within a retention window. It requires that soft delete, versioning, and the blob change feed all be enabled on the account.

What is an immutable blob storage policy, and what are its two types?

Immutable storage enforces WORM (Write Once, Read Many) so data cannot be modified or deleted for a period. Two types: time-based retention policy (immutable for N days) and legal hold (immutable until the named tag/hold is removed). Used for compliance (e.g., SEC 17a-4).

What protocols and OS support does Azure Files provide?

Azure Files offers fully managed file shares accessible via SMB (2.1/3.0/3.1.1) on Windows, Linux, and macOS, and via NFS (v4.1) on premium shares for Linux. It also supports access through the Azure Files REST API and Azure File Sync.

What are the two tiers/billing models for Azure file shares?

Standard file shares (transaction-optimized, hot, cool) use a pay-as-you-go model on HDD-backed storage. Premium file shares use SSD-backed storage in a FileStorage account with a provisioned model—you pay for provisioned GiB, IOPS, and throughput regardless of usage.

What port must be open to mount an Azure file share over SMB, and why is it often a problem?

SMB uses TCP port 445. Many ISPs and corporate firewalls block port 445 outbound, which prevents direct internet mounting. Workarounds include VPN/ExpressRoute, a private endpoint, or SMB over QUIC (port 443) via Azure File Sync/Windows Server.

What is Azure File Sync and what does it enable?

Azure File Sync centralizes file shares in Azure Files while caching them on one or more on-premises (or cloud) Windows Servers. The server presents a local SMB/NFS share with the performance of a local file server, while Azure holds the master copy—enabling multi-site sync and cloud tiering.

List the core components of an Azure File Sync deployment.

Storage Sync Service (top-level Azure resource), Sync Group (defines the sync topology), Cloud Endpoint (an Azure file share in the sync group), Server Endpoint (a path on a registered Windows Server), and the Azure File Sync agent installed on each registered server.

What is cloud tiering in Azure File Sync?

Cloud tiering is an optional Azure File Sync feature that keeps frequently accessed (hot) files cached locally on the server while tiering infrequently used (cool) files up to the Azure file share, leaving a pointer/reparse point locally. It conserves on-premises disk space; you set a free-space or date policy.

What is the difference between the cloud endpoint and a server endpoint in a sync group?

A cloud endpoint is the Azure file share that serves as the authoritative cloud copy in the sync group (only one per sync group). A server endpoint is a specific folder path on a registered Windows Server; multiple server endpoints can sync to the same cloud endpoint, enabling many-site synchronization.

How are Azure file shares backed up, and what service is used?

Azure file shares are protected by Azure Backup using a Recovery Services vault. Backup uses share snapshots; you define a backup policy with schedule and retention. Snapshots are stored within the storage account and enable item-level (file/folder) and full-share restore.

What is the difference between snapshot-based protection and soft delete for Azure Files?

Share snapshots are read-only point-in-time copies (manual or via Azure Backup) used to restore files. Soft delete for file shares retains a deleted share (and its snapshots) for a configurable retention period (1–365 days) so the whole share can be recovered after accidental deletion.

What two restore granularities does Azure Backup support for Azure file shares?

Full-share restore (restore the entire file share to a snapshot's state, to the original or an alternate location) and item-level (individual file/folder) restore. Restores can overwrite originals or write to an alternate location to avoid data loss.