AZ-104
Deep Dive
Azure's service for object, file, queue, and table storage. The AZ-104 tests account types, redundancy, access tiers, security, and transfer tools.
Contents
A Storage Account is the top-level container for all of Azure's storage services. Inside an account you can have Blob Storage, Azure Files, Queue Storage, and Table Storage, each with its own unique endpoint.
The account name must be globally unique across Azure (3-24 characters, lowercase letters and numbers only). The endpoint takes the form: https://<account>.blob.core.windows.net
Unique namespace
Every object has a unique URL based on the account name. Enables direct HTTP/HTTPS access to any object.
The account name is part of the public URL — choose one that is descriptive and free of sensitive data.
Durability
A minimum of 3 copies of every piece of data in the primary region. With GRS/GZRS there are 3 additional copies in the secondary region.
Azure guarantees 11 nines (99.999999999%) of durability with LRS. With GRS: 16 nines.
Scalability
Up to 5 PiB of capacity per account. Up to 20,000 IOPS. Bandwidth of up to 60 Gbps ingress / 60 Gbps egress.
If you need more throughput: use multiple accounts or Storage v2 with prefix-based partitioning.
| Type | Performance | Included services | Recommended use |
|---|---|---|---|
| Standard (GPv2) | Standard (HDD) | Blob, File, Queue, Table, Data Lake | General case. The default and recommended type for most scenarios. |
| Premium Block Blob | Premium (SSD) | Block Blobs and Append Blobs only | High-performance workloads: IoT, real-time analytics, low latency. |
| Premium File Share | Premium (SSD) | Azure Files only | Enterprise applications that need <1ms latency for SMB shares. |
| Premium Page Blob | Premium (SSD) | Page Blobs only | Unmanaged VM disks (legacy). Managed Disks are preferred today. |
| Standard GPv1 (legacy) | Standard (HDD) | Blob, File, Queue, Table | Do not create new ones. Migrate to GPv2 to access access tiers and other features. |
Golden rule for the exam
GPv2 Standard is the right type for almost everything. If the question mentions "high IOPS," "low latency," "SSD" → Premium Block Blob. If it mentions "enterprise Azure Files" → Premium File Share. If you see GPv1 → always migrate to GPv2.
Blob Storage
Unstructured object storage. Three blob types: Block Blob (files up to 190.7 TiB), Append Blob (logs), Page Blob (disks, random access).
Use cases
Images, videos, backups, logs, ML data, static website hosting.
.blob.core.windows.net
Azure Files
SMB (v2.1, 3.0) and NFS file shares mountable from Windows, Linux, or macOS. Compatible with apps that use standard file system APIs.
Use cases
Lift-and-shift of applications that use file shares, home directories, shared config.
.file.core.windows.net
Queue Storage
Messages up to 64 KB, maximum retention of 7 days. A message can be read by one consumer at a time (temporary visibility). Up to 500 TiB per queue.
Use cases
Decoupling components, asynchronous processing, task backlogs.
.queue.core.windows.net
Table Storage
Schemaless NoSQL key-value store. Each entity has a PartitionKey + RowKey (composite PK) + dynamic attributes. Up to 252 properties per entity.
Use cases
Configuration data, time-series historical data, catalogs without complex relationships.
.table.core.windows.net
Blob types — comparison
| Type | Max. size | Operations | Typical use |
|---|---|---|---|
| Block Blob | 190.7 TiB | Put Block + Put Block List (block-based upload) | General files, video, images, backups |
| Append Blob | 195 GiB | Append Block only (existing blocks cannot be updated) | Logs, auditing — append-only writes |
| Page Blob | 8 TiB | Random read/write in 512-byte pages | VM VHDs (legacy), DB disks |
The redundancy configuration determines how many copies of the data exist, and where. This is one of the most frequently tested Storage questions on the AZ-104.
| Type | Copies | Location | Protects against | Read from secondary |
|---|---|---|---|---|
| LRS | 3 | Same datacenter (1 AZ) | Disk/rack failure | ✗ |
| ZRS | 3 | 3 Availability Zones (same region) | Datacenter/AZ failure | ✗ |
| GRS | 6 | 3 in the primary region (LRS) + 3 in the secondary region (LRS) | Full region failure | ✗ |
| RA-GRS | 6 | Same as GRS | Region failure + read from secondary always | ✗ |
| GZRS | 6 | 3 across 3 primary AZs + 3 in the secondary region (LRS) | AZ + region | ✗ |
| RA-GZRS | 6 | Same as GZRS | AZ + region + read from secondary | ✗ |
Geo-replication facts
• The secondary region is fixed by Azure (you don't choose it) — e.g.: East US → West US
• Replication to the secondary is asynchronous — there can be lag (RPO not guaranteed)
• With GRS/GZRS the secondary is read-only ONLY during failover (unless it is RA-*)
• Failover is started manually from the Azure Portal or PowerShell (or automatically in disasters)
Quick decision tree
→ Non-critical data, lowest cost: LRS
→ High availability within the region, AZ protection: ZRS
→ Geographic DR, no need to read from secondary: GRS
→ DR + read from secondary (e.g.: analytics): RA-GRS
→ Maximum resiliency (AZ + geo): GZRS or RA-GZRS
Access tiers let you optimize cost based on access frequency. Only available on GPv2 and Premium Block Blob accounts.
| Tier | Storage | Access/transfer | Latency | Min. storage duration | Ideal use |
|---|---|---|---|---|---|
| Hot | High | Low | Milliseconds | None | Frequently accessed data: active apps, websites |
| Cool | Low | Medium | Milliseconds | 30 days | Occasionally accessed data: short-term backups, 30-90 day-old data |
| Cold | Very low | High | Milliseconds | 90 days | Rarely accessed data that still needs online availability: inactive files |
| Archive | Minimum | Very high | Hours (rehydration) | 180 days | Long-term retention, compliance, inaccessible historical data |
Archive — special behavior
• Blobs in Archive are not directly accessible — they must first be "rehydrated"
• Standard Rehydration Priority: up to 15 hours | High Priority: <1 hour (extra cost)
• You can copy the blob to a Hot/Cool/Cold tier in another container without modifying the original
• If you delete a blob in Archive before 180 days: prorated early-deletion charge
Authentication and authorization methods
Entra ID (RBAC)
RecommendedThe recommended method. Assign Storage roles (Storage Blob Data Reader, Contributor, etc.) to users, groups, or Managed Identities. No key management needed.
Account Keys
Avoid in productionTwo 512-bit keys that grant full access to the account. Rotate periodically. Store in Azure Key Vault, never in code. Anyone with the key has unlimited access.
Shared Access Signature (SAS)
For temporary accessA delegated access token with limited permissions, resource, and time. Three types: Account SAS, Service SAS, User Delegation SAS (signed with Entra ID credentials — more secure).
Anonymous Access (Public)
Only for explicitly public contentAllows reading blobs without authentication. Configurable at the container level (container: list + read, blob: read only). Disabled by default on new accounts.
Storage RBAC roles — key for the exam
Exam trap
Storage Account Contributor is a control-plane role: it can change configuration and view keys, but it CANNOT read/write blob data directly via Entra ID. For data access you need the specific "Data" roles.
Encryption
• Encryption at rest: automatic AES-256 for all data. Cannot be disabled.
• Microsoft-managed keys (MMK): the default, no configuration needed.
• Customer-managed keys (CMK): you control the key in Azure Key Vault. Allows rotation and revocation.
• Encryption in transit: HTTPS required ("Secure transfer required" — enabled by default).
• Infrastructure encryption: double encryption at the infrastructure level (for maximum compliance requirements).
Public endpoint (default)
Accessible from the internet. You can restrict it via the Storage Firewall: allow only specific IPs or VNet subnets (Service Endpoints).
Storage Account → Networking → Firewalls and virtual networks
Service Endpoints
Extends the VNet's identity to the Storage service. Traffic still travels over Azure's network but access is restricted to the configured subnet only.
VNet → Subnets → Service endpoints → Microsoft.Storage
Private Endpoints
Creates a private IP inside your VNet for the Storage Account. Traffic never goes out to the internet. A Private DNS Zone is used for resolution. More secure than Service Endpoints.
Storage → Networking → Private endpoint connections → New
Azure DNS zones for Storage
With Private Endpoints you need to create Private DNS Zones (e.g., privatelink.blob.core.windows.net) so DNS resolution returns the private IP instead of the public one.
Normally created automatically when you create the Private Endpoint.
Automates blob tier transitions and age-based deletion. Reduces costs without manual intervention.
Structure of a lifecycle rule
Filter
Defines which blobs the rule applies to. Options: name prefix (e.g., logs/2023/), blob type (blockBlob, appendBlob), size.
Action
What to do with blobs matching the filter: transition to Cool/Cold/Archive, delete the blob, delete previous versions, delete snapshots.
Time condition
The action runs when the blob reaches N days since: creation, last modification, last access (if tracking enabled), or last access to the base version.
Example: progressive archiving policy
→ 0-30 days: Hot (frequent access)
→ 30-90 days: transition to Cool (modification > 30 days)
→ 90-365 days: transition to Cold (modification > 90 days)
→ 365+ days: transition to Archive (modification > 365 days)
→ 7+ years: delete (modification > 2555 days)
A SAS is a signed URI that delegates limited access to Storage resources without exposing the account keys.
| Type | Signed with | Scope | Revocation |
|---|---|---|---|
| Account SAS | Account Key | Multiple services and operations on the entire account | Rotating the account key (affects ALL SAS) |
| Service SAS | Account Key | A specific service (Blob, File, Queue, Table) | Rotating the account key or using a Stored Access Policy |
| User Delegation SAS | Entra ID credentials (OAuth) | Only Blob Storage and Data Lake | Revoking the user's Entra ID credentials. The most secure. |
SAS URI parameters
Stored Access Policies
A Stored Access Policy (SAP) lets you revoke a SAS without rotating the account keys. It's defined on the container/queue/share and the SAS references it.
→ Create a SAP: Portal → container → Access policy → Add policy
→ A service SAS can reference the SAP with the si=policyName parameter
→ To revoke: delete or modify the SAP → all SAS referencing it become invalid
→ Maximum of 5 SAPs per container/resource
AzCopy
A high-performance CLI to copy data to/from/between Storage Accounts. Supports Blob, File, ADLS Gen2. Authenticate with SAS or Entra ID (azcopy login).
azcopy copy "local_path" "https://account.blob.core.windows.net/container?SAS" --recursive
azcopy sync "source/" "destination/" --delete-destination=true
azcopy copy "source_blob?SAS" "destination_blob?SAS" (server-side copy — does not go through the client)
Storage Explorer
A cross-platform GUI for managing Storage Accounts. Supports Blob, File, Queue, Table, CosmosDB, ADLS. Ideal for occasional operations and exploration.
Drag & drop files to/from containers
Manage access policies and SAS
Edit Table Storage entities directly
Azure Data Box — bulk offline transfer
Data Box Disk
Up to 35 TB (5 SSD disks of 8 TB each)
Small migrations, initial data
Data Box
80 TB
Datacenter-to-Azure migration, physical device shipment
Data Box Heavy
770 TB
Bulk migrations, initial data lakes
Use Data Box when a network transfer would take more than 7 days. Azure ships the physical device, you load the data, ship it back, and Azure imports it.
Did you get this topic?
Test what you just learned
A company needs its Storage Account to be accessible only from a specific VNet, without traffic going over the internet. What configuration should they use?
Put what you learned to the test with original AZ-104 exam questions.
Start AZ-104 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.