Azure Storage Account questions on the AZ-104 exam cover performance tiers, blob access tiers, redundancy options, and which storage service (Blob, Files, Queue, Table) is appropriate for a given workload. These questions reward knowing the definitions precisely.
Performance Tiers
Standard — Uses hard disk drives (HDD). Lower cost. Suitable for most general-purpose workloads including backups, archives, and infrequently accessed data.
Premium — Uses solid-state drives (SSD). Low latency, high throughput. Required for high-performance workloads.
Premium has sub-types:
- BlockBlobStorage — High transaction rates for blob workloads
- FileStorage — High-performance file shares (Azure Files Premium)
- Page Blob — Virtual machine disks (managed disks use this internally)
Exam trap: Premium storage cannot be converted to Standard after creation, and vice versa. The tier is set at account creation.
Blob Access Tiers
For Standard storage accounts with blob data:
| Tier | Use Case | Storage Cost | Access Cost |
|---|---|---|---|
| Hot | Frequently accessed data | Highest | Lowest |
| Cool | Infrequently accessed (30+ days) | Lower | Higher |
| Cold | Rarely accessed (90+ days) | Lower still | Higher still |
| Archive | Long-term retention, rarely accessed | Lowest | Highest + rehydration |
Archive tier data is offline — it must be rehydrated to Hot or Cool before it can be read. Rehydration can take hours.
Minimum retention: Cool = 30 days, Cold = 90 days, Archive = 180 days. If you delete data before the minimum retention period, you are charged for the remaining days.
Exam scenario: "A company stores medical images that are accessed daily for the first 30 days after creation, then rarely accessed for legal retention for 7 years. Which tiers should be used?"
Hot for the first 30 days, then transition to Archive via lifecycle management policy.
Redundancy Options
| Option | Full Name | Copies | Protection Against |
|---|---|---|---|
| LRS | Locally Redundant Storage | 3 copies in 1 datacenter | Hardware failure |
| ZRS | Zone-Redundant Storage | 3 copies across 3 zones | Datacenter/zone failure |
| GRS | Geo-Redundant Storage | 6 copies (3 primary + 3 secondary region) | Regional disaster |
| RA-GRS | Read-Access Geo-Redundant | GRS + read access to secondary | Regional disaster + read failover |
| GZRS | Geo-Zone-Redundant | ZRS primary + LRS secondary | Zone + regional failure |
| RA-GZRS | Read-Access GZRS | GZRS + read access to secondary | Maximum protection |
Exam trap: with GRS, the secondary region is not readable by default — data is only accessible after Microsoft initiates a failover. RA-GRS allows reading from the secondary endpoint at all times.
"A company requires data to remain available for reads even if the primary Azure region fails, without waiting for Microsoft to initiate failover" — RA-GRS or RA-GZRS.
Storage Services
Azure Blob Storage — Unstructured object storage. Used for images, videos, backups, logs, and any data that does not need a file system structure.
Azure Files — Managed file shares accessed via SMB or NFS protocol. Ideal for lift-and-shift of on-premises file servers, or applications that need a shared file system across multiple VMs.
Azure Queue Storage — Message queuing for asynchronous communication between application components. Messages can be up to 64 KB.
Azure Table Storage — NoSQL key-value store for structured data. Cheap and scalable, but limited query capability compared to Cosmos DB.
Exam scenario: "An application needs to pass messages between a web front-end and a background processing service. Which storage service should be used?" — Queue Storage.
"A company wants to move their on-premises Windows file server to Azure and allow access via the same SMB protocol" — Azure Files.
Lifecycle Management Policies
Lifecycle management policies automatically transition blobs between access tiers or delete them based on age:
Transition blobs to Cool tier after 30 days
Transition blobs to Archive after 90 days
Delete blobs after 365 days
This is how you implement a tiered storage strategy without manual intervention. The exam tests this as the correct approach for cost optimisation when data access patterns follow predictable age-based curves.
Practice AZ-104 storage questions to cement the tier and redundancy options before exam day.
Replication Option Decision Guide — The Exam's Scenario Mapping
The six replication options in Azure Storage map to specific failure scenarios, and the exam always frames them as scenarios rather than asking for definitions. Memorise the mapping:
- Single availability zone failure, same region → ZRS (Zone-Redundant Storage). Data copies across 3 AZs in one region.
- Entire region failure, need failover → GRS (Geo-Redundant Storage). Synchronous LRS in primary, async copy to secondary region. Secondary is read-only only after failover is initiated.
- Region failure, need read access during outage without waiting for failover → RA-GRS (Read-Access Geo-Redundant). Secondary endpoint is always readable:
accountname-secondary.blob.core.windows.net. - AZ failure + region failure protection → GZRS (Geo-Zone-Redundant Storage). ZRS in primary, LRS in secondary.
- AZ failure + region failure + read access during outage → RA-GZRS. The most resilient and most expensive option.
Price order from lowest to highest: LRS → ZRS → GRS → RA-GRS → GZRS → RA-GZRS.
The exam trap: "Which replication option allows reading data from the secondary region during a primary region outage without manually initiating a failover?" Answer: RA-GRS or RA-GZRS — not GRS or GZRS, which require failover before secondary reads are possible.
Storage Account Kind — GPv2 vs BlockBlobStorage vs FileStorage
Azure has four storage account types and the exam tests when to use each:
General Purpose v2 (GPv2) — Supports blob storage (all tiers), Azure Files, Queue storage, and Table storage. This is the default and correct choice for almost every scenario. When in doubt, the answer is GPv2.
General Purpose v1 (GPv1) — Legacy, lacks blob access tiers (no Cool or Archive). The exam occasionally offers this as a distractor. It's not the right choice for new deployments.
BlockBlobStorage — Premium performance tier for block blobs only. Use when you need sub-10ms latency for blob operations. Does not support ZRS by default in all regions. Cannot convert to GPv2 after creation.
FileStorage — Premium performance tier for Azure Files (SMB/NFS) only. Required when you need premium file shares.
The exam pattern: "An application requires the lowest possible latency for storing and retrieving unstructured binary data as blobs." → BlockBlobStorage. "A company needs a general-purpose storage account that supports all storage services." → GPv2.
Note: GPv1 accounts can be upgraded to GPv2 in-place. BlockBlobStorage and FileStorage accounts cannot be converted — you must migrate data.
Azure Files vs Azure Blob — When to Use Each
These two services get confused in exam questions that don't spell out the use case clearly.
Azure Blob Storage is object storage. Files are stored as flat objects with metadata. No native file-system hierarchy (though you can simulate directories with path-style names). Used for: backups, log files, images served to web applications, VM disk snapshots, data lakes. Access via REST API, SDKs, or AzCopy. Cannot be mounted as a drive natively.
Azure Files is a fully managed file share accessible via SMB 3.0 or NFS 4.1. It can be mounted as a drive letter on Windows (net use Z: \\accountname.file.core.windows.net\sharename) or mounted on Linux via cifs-utils. Used for: lift-and-shift of on-premises file servers, shared application configuration, home drives.
Azure File Sync extends Azure Files by caching frequently accessed files on Windows Server on-premises while tiering cold files to the cloud. This is the answer for: "A company has 20TB of data on an on-premises file server and wants to reduce local storage while keeping frequently used files accessible at LAN speed."
Exam trap: "A developer needs to store images uploaded by users to serve them on a web application." → Blob Storage. "A company is moving a legacy application that reads files via a UNC path." → Azure Files.
SAS Token Types — Account vs Service vs User Delegation
Shared Access Signatures grant time-limited, scoped access to storage resources without sharing account keys. Three types:
Account SAS — Grants access across multiple storage services (blob, file, queue, table) for the same storage account. Signed with the account key. If the account key is rotated, the SAS is immediately revoked.
Service SAS — Grants access to a specific resource within one service (e.g., a specific blob container). Also signed with the account key.
User Delegation SAS — Signed with Entra ID (Azure AD) credentials instead of the account key. Supports only Blob and Data Lake Storage Gen2. Maximum validity: 7 days. This is the most secure option because it doesn't expose account keys and can be revoked by revoking the user's permissions.
The exam pattern: "A storage administrator needs to generate a SAS token that does not expose the storage account key and can be revoked by removing the user's permissions." → User Delegation SAS.
Azure CLI to create one:
az storage blob generate-sas \
--account-name mystorageaccount \
--container-name mycontainer \
--name myblob.txt \
--permissions r \
--expiry 2026-06-01 \
--auth-mode login \
--as-user
Soft Delete and Versioning — The Data Protection Layer
Neither soft delete nor blob versioning is enabled by default on new storage accounts. Both protect against accidental deletion but work differently.
Blob soft delete retains deleted blobs (and their snapshots) for a configurable retention period (1–365 days). During this period, a deleted blob appears in the portal only if you toggle "Show deleted blobs." You can restore it with the Undelete operation. After the retention period, the blob is permanently gone.
Blob versioning automatically keeps every version of a blob when it's modified or deleted. Unlike soft delete, you don't need to act within a retention period — old versions persist until you explicitly delete them or a lifecycle policy removes them. Deletion of the current version creates a delete marker; previous versions remain accessible.
The exam question: "A storage administrator accidentally deleted important blobs. The company needs a solution that automatically retains previous versions of all blobs." → Versioning. "The company wants deleted blobs to be recoverable for 30 days." → Soft delete with 30-day retention.
Enable in portal: Storage account → Data protection → Blob soft delete / Enable versioning.
Azure Storage Firewall — Restricting Access by Network
By default, storage accounts accept connections from all networks. The storage firewall lets you lock this down.
Configuration options:
- Selected networks — Allow specific public IP ranges (e.g., your office NAT IP) and/or specific VNet subnets (using service endpoints).
- Disabled (allow all) — Default, open to everything.
- Enabled with no rules — Blocks everything except the exceptions below.
The "Allow trusted Microsoft services to access this storage account" checkbox is important — when the firewall is enabled, Azure services like Azure Backup, Azure Site Recovery, Azure Monitor diagnostics, and Event Grid need this exception to reach the storage account. Without it, backup jobs fail.
Private endpoints create a private IP inside your VNet that maps to the storage account. Traffic never leaves the Azure backbone. This is stronger than service endpoints: service endpoints use the public endpoint of the storage account (but route over the Azure backbone), while private endpoints create a genuinely private IP.
Exam scenario: "A company requires that their storage account is only accessible from within their Azure VNet and not from the public internet." → Private endpoint (most secure) or service endpoint with storage firewall configured to allow only that VNet subnet.