This chapter covers Azure Storage Accounts, the foundational storage service in Microsoft Azure. Storage accounts are a core component of nearly every Azure solution, making them a high-priority topic on the AZ-104 exam, with approximately 15-20% of questions touching storage concepts. You will learn the different types of storage accounts, their performance tiers, replication options, access control mechanisms, and how to configure them using the Azure portal, CLI, and PowerShell. Mastery of storage accounts is essential for designing resilient, secure, and cost-effective cloud architectures.
Jump to a section
Think of an Azure Storage Account as a massive, multi-story public warehouse in a city. The warehouse itself is the storage account—a logical container that provides a unique address (the storage account name) and governs access policies. Inside, different sections serve different purposes: one area for bulk dry goods (Blob storage for unstructured data), another for temperature-controlled items (Table storage for structured NoSQL data), a vault for sensitive documents (File storage for SMB shares), and a small counter for quick pickups (Queue storage for message passing). The warehouse has a main entrance (the storage account endpoint) that all deliveries use. To enter, you need a badge (storage account key or shared access signature) that proves your identity and permissions. The warehouse manager (Azure Resource Manager) can set rules about who can enter, when, and what they can carry. Inside, each section is organized into aisles (containers or shares) and shelves (blobs or files). The warehouse has a billing system that charges based on how much space you occupy (capacity) and how often items are moved in/out (transactions). If you need faster access, you can rent a premium section with dedicated staff (premium storage for low latency). The warehouse also offers geo-replication: a sister warehouse in another city automatically copies your inventory for disaster recovery. This analogy mirrors how Azure Storage Accounts provide a unified namespace, tiered performance, access control, and data replication options.
What is an Azure Storage Account?
An Azure Storage Account is a logical container that groups Azure Storage services together. It provides a unique namespace for your storage data that is accessible from anywhere in the world over HTTP or HTTPS. The storage account serves as the administrative boundary for configuring access, replication, and performance settings. You cannot create any Azure Storage service (Blob, File, Queue, Table) without a storage account.
Types of Storage Accounts
Azure offers several types of storage accounts, each designed for specific workloads. The exam expects you to know the differences and use cases.
General-purpose v2 (GPv2): The most common storage account type. Supports all storage services (Blob, File, Queue, Table). Provides low-cost access to frequently and infrequently accessed data via hot, cool, and archive access tiers. Default for new storage accounts.
General-purpose v1 (GPv1): Legacy type, supports all services but lacks access tiers and advanced features like lifecycle management. Use only for older deployments or classic Azure Service Manager (ASM) resources.
BlobStorage: Legacy type that only supports block blobs and append blobs. No longer recommended; use GPv2 instead.
BlockBlobStorage: Premium performance tier for block blobs and append blobs. Ideal for high transaction rates and low latency (sub-10ms). Uses solid-state drives (SSDs).
FileStorage: Premium performance tier for Azure Files. Provides SMB shares with high IOPS and throughput. Backed by SSDs.
Azure Data Lake Storage Gen2: Built on Blob storage, adds a hierarchical namespace for file system semantics. Use for big data analytics workloads (e.g., Azure Databricks, HDInsight). Enabled via the 'Hierarchical namespace' setting on a GPv2 account.
Performance Tiers
Storage accounts offer two performance tiers: Standard and Premium.
Standard: Backed by magnetic hard disk drives (HDDs). Suitable for most workloads. Provides lower cost per GB but higher latency (10-50ms).
- Premium: Backed by SSDs. Designed for high-performance workloads requiring consistent low latency (single-digit milliseconds). Three sub-types: - *Premium block blobs*: For block blob and append blob storage (BlockBlobStorage account). - *Premium file shares*: For SMB file shares (FileStorage account). - *Premium page blobs*: For page blobs (used for unmanaged disks of VMs). Can be created via a GPv2 account with 'Performance' set to 'Premium'.
Replication Options
Replication ensures durability and availability. The exam tests your ability to choose the right option based on cost, availability, and compliance.
Locally-redundant storage (LRS): Three synchronous copies within a single datacenter in a single region. Protects against server rack and drive failures. Not resilient to datacenter-level disasters.
Zone-redundant storage (ZRS): Three synchronous copies across three Azure availability zones in the same region. Protects against zone failures (e.g., power outage, flood). Available only for GPv2, BlockBlobStorage, and FileStorage accounts.
Geo-redundant storage (GRS): LRS in the primary region plus asynchronous replication to a secondary paired region (LRS there). Provides six copies total. Protects against region-wide disaster. Failover to secondary is manual.
Read-access geo-redundant storage (RA-GRS): Same as GRS but data in the secondary region is readable (read-only). Useful for read-heavy applications that need access even during primary region outage.
Geo-zone-redundant storage (GZRS): ZRS in the primary region plus asynchronous replication to a secondary paired region (LRS). Combines zone and region resilience. Also has a read-access variant (RA-GZRS).
Default replication for new storage accounts is GRS (or RA-GRS for some regions). You can change replication after creation, but some changes may cause data loss (e.g., switching from GRS to LRS) or require a full copy (e.g., from LRS to ZRS).
Access Tiers for Blob Storage
GPv2 and BlobStorage accounts offer access tiers to optimize cost based on data access frequency:
Hot: Optimized for frequent reads/writes. Highest storage cost but lowest access cost.
Cool: For infrequent data (stored for at least 30 days). Lower storage cost, higher access cost (read/write).
Archive: For rarely accessed data (stored for at least 180 days). Lowest storage cost, but data must be rehydrated (takes hours) before reading. Offline tier.
Tiers can be set at the blob level or account level (default). Lifecycle management policies can automatically move blobs between tiers based on age.
Access Control and Security
Access to storage accounts is controlled via:
Storage Account Keys: Two keys (primary and secondary) that grant full control. Regenerate them regularly to maintain security.
Shared Access Signatures (SAS): Delegated access tokens with granular permissions (read, write, delete, list) and time constraints. Types: service SAS (scoped to a service), account SAS (scoped to the account), user delegation SAS (uses Azure AD credentials for Blob storage).
Azure AD Integration: For Blob and Queue storage, you can use Azure AD identities to control access via RBAC roles (e.g., Storage Blob Data Reader, Storage Queue Data Contributor). Recommended over keys for security.
Firewalls and Virtual Networks: Restrict access to specific IP addresses or Azure Virtual Network subnets. Can also allow access from selected Azure services (e.g., Azure SQL Database).
Private Endpoints: Use private IP addresses from a VNet to access storage account data, keeping traffic within the Microsoft backbone.
How Storage Accounts Work Internally
When you create a storage account, Azure assigns a unique DNS name: <accountname>.blob.core.windows.net for Blob, <accountname>.file.core.windows.net for File, etc. Each request to the storage account is authenticated (via key, SAS, or Azure AD) and then routed to the appropriate service endpoint. The storage account acts as a namespace; the actual data is stored across many storage nodes (scale units) within the Azure datacenter. The replication engine ensures that writes are durably stored according to the selected replication type. For LRS, a write must be acknowledged by all three replicas before the client receives a success response. For ZRS, replicas span availability zones. For GRS/RA-GRS, writes are committed locally, then asynchronously replicated to the paired region (typically within 15 minutes).
Configuration and Management Commands
You can manage storage accounts using Azure CLI, PowerShell, or the portal.
Azure CLI example – Create a GPv2 storage account with LRS:
az storage account create \
--name mystorageaccount \
--resource-group myResourceGroup \
--location eastus \
--sku Standard_LRS \
--kind StorageV2Get storage account keys:
az storage account keys list \
--account-name mystorageaccount \
--resource-group myResourceGroupGenerate a SAS token for a container:
az storage container generate-sas \
--account-name mystorageaccount \
--name mycontainer \
--permissions rwdl \
--expiry 2025-12-31T23:59:00Z \
--https-onlyPowerShell example – Create a storage account:
New-AzStorageAccount -ResourceGroupName myResourceGroup `
-Name mystorageaccount `
-Location eastus `
-SkuName Standard_LRS `
-Kind StorageV2Interaction with Other Azure Services
Azure Virtual Machines: Use storage accounts for VM disks (page blobs) and diagnostic logs (block blobs).
Azure Functions: Triggered by blob/queue events; store function code in a storage account.
Azure SQL Database: Can import/export data using storage account blobs.
Azure CDN: Can serve content from storage account blobs with custom domain.
Azure Backup: Stores backup data in a Recovery Services vault, which uses storage accounts internally.
Limits and Defaults
Storage account name: 3-24 characters, lowercase letters and numbers only, globally unique.
Maximum number of storage accounts per region per subscription: 250 (default limit, can be increased).
Maximum capacity per storage account: 5 PiB for standard accounts, 100 TiB for premium block blob accounts.
Maximum ingress/egress: Varies by account type and replication; e.g., standard GPv2 LRS: ingress 25 Gbps, egress 50 Gbps.
Maximum blob size: 4.75 TiB (block blobs, with up to 50,000 blocks per blob).
Maximum file share size: 100 TiB with large file shares enabled.
Exam Tips
Know the difference between LRS, ZRS, GRS, RA-GRS, GZRS, RA-GZRS and when to use each.
Remember that changing replication from GRS to LRS is a one-way downgrade (no automatic data copy; you must copy data manually).
Understand that Archive tier is offline and requires rehydration (takes up to 15 hours).
SAS tokens start immediately upon creation; no delay.
Azure AD authentication is supported for Blob and Queue storage only (not File, Table).
Storage account keys give full access; use SAS or Azure AD for least privilege.
The 'Hierarchical namespace' setting for Data Lake Storage Gen2 cannot be disabled once enabled.
Lifecycle management policies can move blobs to cool tier after 30 days and archive after 180 days.
For production workloads requiring high availability across zones, use ZRS or GZRS.
For disaster recovery across regions, use GRS or GZRS.
Conclusion
Azure Storage Accounts are the bedrock of data storage in Azure. Understanding the types, replication, access control, and performance tiers is critical for the AZ-104 exam and real-world administration. Practice creating and configuring storage accounts using the portal and CLI to reinforce these concepts.
Create a Storage Account
In the Azure portal, navigate to 'Storage accounts' and click 'Create'. Choose a subscription and resource group. Enter a globally unique name (3-24 alphanumeric lowercase). Select a region (e.g., East US). Choose performance tier: Standard (HDD) or Premium (SSD). For Premium, you must also select the account kind (BlockBlobStorage, FileStorage, or GPv2 with premium page blobs). Select replication: LRS, ZRS, GRS, RA-GRS, GZRS, or RA-GZRS. For GPv2, you can set the default access tier (Hot or Cool). Click 'Review + create' and then 'Create'. This step establishes the logical container and its global endpoint.
Configure Networking and Security
After creation, go to 'Networking' under 'Security + networking'. You can enable 'Firewalls and virtual networks' to restrict access. Choose 'Selected networks' and add IP address ranges or virtual network subnets. For private connectivity, create a private endpoint: specify the VNet and subnet, and a private DNS zone. Enable 'Allow trusted Microsoft services' if needed (e.g., for Azure Backup). Under 'Access keys', you can view and regenerate the two storage account keys. Under 'Shared access signatures', generate SAS tokens with specific permissions, start/expiry times, and allowed services. Under 'Azure AD', assign RBAC roles like 'Storage Blob Data Contributor' to users or service principals.
Create a Container or File Share
For Blob storage, create a container (like a folder). In the portal, go to 'Containers' under 'Data storage', click '+ Container', enter a name (lowercase, 3-63 characters), and set public access level (Private, Blob, Container). For Azure Files, go to 'File shares', click '+ File share', enter a name (lowercase, 3-63 characters), and set quota (max 100 TiB). For Table or Queue, go to 'Tables' or 'Queues' and create a new resource. These containers isolate data within the storage account and are the entry points for data operations.
Upload and Manage Data
Upload blobs to a container using the portal, Azure CLI, PowerShell, or SDKs. In the portal, select a container, click 'Upload', choose files, and optionally set blob type (Block, Page, Append) and access tier (Hot, Cool, Archive). For Azure Files, upload files directly to the share. You can also set metadata, tags, and snapshots. For large datasets, use AzCopy (command-line tool) for high-performance transfers. Data is stored as blocks (for block blobs) or pages (for page blobs) across storage nodes. Access logs and metrics can be enabled to monitor usage.
Configure Lifecycle Management
To automate tier transitions, go to 'Lifecycle management' under 'Blob service'. Add a rule: specify a rule name, choose a scope (limit to blobs by prefix or blob index match), and add conditions. For example, 'If blob age > 30 days, move to Cool tier'; 'If blob age > 180 days, move to Archive'; 'Delete blobs after 365 days'. The policy runs once per day. This reduces cost by automatically moving cold data to cheaper storage. Note: Archive blobs cannot be read directly; they must be rehydrated (takes up to 15 hours) to Hot or Cool tier.
Monitor and Troubleshoot
Use Azure Monitor metrics (e.g., 'Availability', 'Egress', 'Success E2E Latency') to track performance. Set up alerts for key metrics like 'Storage Account Availability < 100%'. Enable diagnostic settings to send logs (StorageRead, StorageWrite, StorageDelete) to a Log Analytics workspace for analysis. Use 'Storage Explorer' (desktop tool) to visually manage data. For connectivity issues, test DNS resolution of the storage account endpoint (e.g., 'nslookup mystorageaccount.blob.core.windows.net'). Check network security rules and SAS token expiry. For high latency, consider using Premium storage or enabling CDN.
In enterprise environments, Azure Storage Accounts are used for diverse workloads. One common scenario is hosting static websites. A company creates a GPv2 storage account, enables 'Static website' feature, and uploads HTML, CSS, and JS files to the $web container. They then configure a custom domain (e.g., www.contoso.com) with Azure CDN for global distribution and SSL termination. This replaces traditional web servers, reducing cost and management overhead. They set the default access tier to Cool because the site is read-heavy but infrequently updated. They also enable geo-replication (RA-GRS) to serve content from a secondary region during a regional outage. Misconfiguration often occurs when the public access level is set to 'Blob' instead of 'Container', causing 403 errors on the custom domain.
Another scenario is backup and disaster recovery. An enterprise uses Azure Backup to back up on-premises SQL Server databases to a Recovery Services vault, which internally uses a storage account. They choose LRS for local backups (cost savings) and GRS for critical backups requiring off-site protection. They configure lifecycle policies to move backup blobs to Cool tier after 30 days and Archive after 180 days. They also enable soft delete for blobs to recover from accidental deletion. A common issue is hitting the storage account capacity limit (5 PiB) due to long retention periods; they mitigate by using multiple storage accounts or enabling large file shares for file backups.
A third scenario is big data analytics. A data science team uses Azure Data Lake Storage Gen2 (hierarchical namespace enabled on a GPv2 account) to store petabyte-scale data. They mount the storage account to Azure Databricks clusters using ABFS (Azure Blob File System) driver. They set performance to Premium for high throughput. Access is controlled via Azure AD RBAC (Storage Blob Data Contributor) and ACLs (POSIX-style) at the directory level. They enable diagnostic settings to log all data access for compliance. Problems arise when the hierarchical namespace is not enabled at creation time; it cannot be added later, forcing a data migration. Also, enabling soft delete on ADLS Gen2 is not supported; they must use snapshots instead.
The AZ-104 exam tests storage accounts under objective 2.1 'Create and configure storage accounts'. Specific sub-objectives include: choosing the appropriate storage account type (GPv2, premium), selecting replication strategy (LRS, ZRS, GRS, etc.), configuring network access (firewall, VNet, private endpoints), and implementing access control (keys, SAS, Azure AD). Questions often present a scenario and ask you to pick the correct configuration.
Common wrong answers and why candidates choose them: 1. Choosing GRS when ZRS is correct: Candidates see 'high availability' and assume geo-replication. But if the requirement is resilience within a single region (e.g., across zones), ZRS is correct. GRS adds cross-region replication but with potential minutes of data loss during failover. The exam loves testing the difference between 'availability' and 'disaster recovery'. 2. Selecting Archive tier for data that needs immediate access: Archive is offline; rehydration takes hours. Candidates confuse Archive with Cool. Remember: Archive = offline, Cool = online but lower access cost. 3. Using storage account keys when Azure AD is better: Keys grant full control. If the scenario mentions 'least privilege' or 'Azure AD integration', Azure AD roles (e.g., Storage Blob Data Reader) are the correct answer. Candidates often default to keys because they are familiar. 4. Enabling hierarchical namespace on an existing GPv2 account: This is not possible. The setting must be enabled at creation. Candidates think they can convert later.
Specific numbers and terms that appear verbatim:
LRS: 3 copies in a single datacenter.
GRS: 6 copies (3 in primary, 3 in secondary).
Archive storage: minimum 180 days; rehydration time: up to 15 hours.
Storage account name length: 3-24 characters.
Maximum storage accounts per region: 250.
Default replication: GRS (or RA-GRS for some regions).
SAS token expiry: can be set in the past to invalidate immediately.
Edge cases:
If a storage account is deleted, the name becomes available after a period (typically 20 minutes).
Changing replication from LRS to ZRS is not a direct conversion; you must use the 'azcopy' tool or Azure Storage Resource Provider to migrate.
Soft delete for blobs is enabled at the storage account level, not per container.
The 'Allow storage account key access' setting must be enabled to use keys; if disabled, only Azure AD authentication works.
How to eliminate wrong answers: Identify the key requirement—availability, durability, cost, or compliance. If the scenario mentions '99.99% availability' and 'zone failure', ZRS is the answer. If '99.9999999999% durability' and 'region failure', GRS. If 'read access during outage', RA-GRS. For access control, if 'Azure AD' is mentioned, choose Azure AD roles over keys. For performance, if 'sub-millisecond latency' is needed, choose Premium.
General-purpose v2 (GPv2) is the default and recommended storage account type for most workloads.
LRS stores 3 copies in a single datacenter; ZRS stores 3 copies across zones; GRS adds asynchronous cross-region replication.
Archive tier is offline; rehydration takes up to 15 hours; minimum storage duration is 180 days.
Storage account names must be globally unique, 3-24 characters, lowercase alphanumeric.
Azure AD authentication is supported for Blob and Queue storage only; keys work for all services.
Hierarchical namespace (ADLS Gen2) must be enabled at creation time and cannot be changed later.
SAS tokens provide delegated access with granular permissions and time constraints; cannot be revoked individually.
Lifecycle management policies can automatically move blobs to Cool or Archive tiers based on age.
Premium storage (SSD) is for low-latency workloads; standard storage (HDD) is for general use.
Changing replication from LRS to ZRS or GRS requires data migration; not a simple setting change.
These come up on the exam all the time. Here's how to tell them apart.
Locally-Redundant Storage (LRS)
3 synchronous copies within a single datacenter.
Protects against drive and rack failures.
Not resilient to datacenter or zone failure.
Lowest cost replication option.
Available for all storage account types.
Zone-Redundant Storage (ZRS)
3 synchronous copies across 3 availability zones in one region.
Protects against zone failure (e.g., power outage, flood).
Provides 99.99% availability for blobs and files.
Higher cost than LRS.
Not available for all account types (e.g., not for GPv1).
Storage Account Keys
Two keys (primary and secondary) grant full access to the account.
Must be stored securely; if compromised, attacker has full control.
No granular permissions; keys cannot be scoped to containers or blobs.
Regeneration invalidates all SAS tokens based on the key.
Supported for all storage services (Blob, File, Queue, Table).
Azure AD Authentication
Uses Azure AD identities and RBAC roles (e.g., Storage Blob Data Reader).
Granular permissions at container or blob level.
Recommended for security; eliminates key management overhead.
Supported only for Blob and Queue storage (not File or Table).
Can use managed identities for Azure resources for secure access.
Mistake
All storage accounts support all Azure Storage services (Blob, File, Queue, Table).
Correct
Only General-purpose v2 (GPv2) and v1 (GPv1) support all four services. Premium accounts (BlockBlobStorage, FileStorage) support only their specific service. BlobStorage legacy accounts only support block and append blobs.
Mistake
Geo-redundant storage (GRS) provides automatic failover with no data loss.
Correct
GRS replicates asynchronously, meaning there is a potential for data loss (typically 15 minutes) during a region failure. Failover must be initiated manually by the customer. RA-GRS allows read access to the secondary region during an outage, but writes are not possible until failover completes.
Mistake
The Archive access tier is suitable for data that needs to be accessed occasionally.
Correct
Archive is an offline tier. Data must be rehydrated to Hot or Cool tier before reading, which can take up to 15 hours. It is intended for long-term backup and compliance data that is rarely accessed. For occasionally accessed data, use Cool tier.
Mistake
You can enable hierarchical namespace on any existing GPv2 storage account.
Correct
Hierarchical namespace (for Azure Data Lake Storage Gen2) can only be enabled during storage account creation. Once created, it cannot be enabled or disabled. You must create a new storage account with the setting enabled and migrate data.
Mistake
Shared access signatures (SAS) can be revoked after they are issued.
Correct
SAS tokens are self-contained and cannot be revoked individually. To invalidate a SAS, you must regenerate the storage account key (if using a service SAS based on key) or create a new user delegation key (if using user delegation SAS). The best practice is to set short expiry times and store SAS securely.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
LRS replicates data three times within a single datacenter, protecting against drive failures but not datacenter outages. ZRS replicates across three availability zones in the same region, protecting against zone failures. GRS replicates to a paired region asynchronously (typically within 15 minutes) for disaster recovery; failover is manual. RA-GRS is like GRS but also allows read access to the secondary region at all times. For the exam, choose LRS for cost-sensitive, non-critical data; ZRS for high availability within a region; GRS for disaster recovery; RA-GRS if you need read access during an outage.
Yes, you can change replication settings in the Azure portal. However, some changes have limitations. For example, switching from LRS to GRS is straightforward. But switching from GRS to LRS is a one-way downgrade; you must manually copy data if you want to keep the secondary copy. Switching to ZRS is not a direct conversion; you must use the Azure Storage Resource Provider or AzCopy to migrate data. The exam tests that you know you cannot simply change to ZRS without additional steps.
A SAS is a token that grants limited access to storage account resources for a specified time period. You can control permissions (read, write, delete, list), allowed services (blob, file, queue, table), and IP restrictions. SAS is ideal for granting temporary access to clients without exposing storage account keys. For example, you can generate a SAS URL for a blob that allows a user to download it for 24 hours. SAS tokens are secure because they are time-limited and scoped. However, they cannot be revoked individually; to invalidate them, you must regenerate the storage account key or user delegation key.
Go to the storage account's 'Networking' blade, select 'Firewalls and virtual networks', and choose 'Selected networks'. Under 'Virtual networks', add the VNet and subnet that should have access. You can also add IP address ranges for on-premises clients. Optionally, enable 'Allow trusted Microsoft services' to allow Azure services (e.g., Azure SQL Database) to access the storage account. For more secure access, use private endpoints, which assign a private IP from your VNet to the storage account, keeping traffic off the public internet.
Azure Data Lake Storage Gen2 (ADLS Gen2) is built on Blob storage but adds a hierarchical namespace, allowing you to organize data into directories and subdirectories with POSIX-like permissions (ACLs). It supports file system semantics (rename, move) and is optimized for big data analytics workloads (e.g., Hadoop, Spark). To use ADLS Gen2, you must enable the 'Hierarchical namespace' setting when creating a GPv2 storage account. It cannot be enabled later. ADLS Gen2 also integrates with Azure AD for access control. Performance is similar to Blob storage, but the hierarchical namespace improves throughput for directory operations.
Hot tier is for frequently accessed data with the highest storage cost but lowest access cost. Cool tier is for infrequently accessed data (stored for at least 30 days) with lower storage cost and higher access cost. Archive tier is for rarely accessed data (stored for at least 180 days) with the lowest storage cost but data is offline and requires rehydration (takes up to 15 hours) before reading. Use lifecycle management to automatically move blobs between tiers based on age. For the exam, remember that Archive is offline and has a minimum 180-day retention; early deletion incurs an early deletion fee.
By default, you can create up to 250 storage accounts per region per subscription. This limit can be increased by submitting a support request. Each storage account can hold up to 5 PiB of data (standard accounts) or 100 TiB (premium block blob accounts). For large-scale workloads, you may need multiple storage accounts to stay within these limits. The exam may test this limit, so remember the number 250.
You've just covered Azure Storage Accounts — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?