Section 6 of 14
This domain is about Azure Storage accounts and the four services they host: blobs, files, queues, and tables. You need to understand redundancy, access tiers, security (SAS, keys, RBAC), and the tools used to move data around.
| Type | Use case |
|---|---|
| General Purpose v2 (GPv2) | The default. Use this for almost everything. Supports all 4 services, all redundancy options, all access tiers. |
| General Purpose v1 (GPv1) | Legacy. Does NOT support ZRS, GZRS, or lifecycle management. If you see GPv1 in a question, your first move is usually 'upgrade to GPv2'. |
| Premium Block Blob | High-performance blob storage on SSD |
| Premium File Storage | High-performance SMB/NFS file shares. BILLED ON PROVISIONED SIZE, not data written. |
| Premium Page Blob | Specialized for low-latency page blobs. Rarely seen on the exam. |
Premium Files is billed on the provisioned size of the share, not how much data you actually write. The performance scales with provisioned capacity, so you pay for the size whether you use it or not. Standard tiers bill on actual data stored.
| Service | What it stores | When to use |
|---|---|---|
| Blob | Unstructured data - images, video, documents, backups | Massively scalable object storage |
| File | SMB and NFS file shares | Lift-and-shift apps that need file shares, no rewrite |
| Queue | Messages between app components | Decouple producers and consumers (FIFO-ish) |
| Table | NoSQL key-value pairs, no schema | Structured non-relational data, simple lookups |
Every storage service has its own subdomain. The format is always: https://<account>.<service>.core.windows.net/<container-or-share>/<object>
| Service | Endpoint suffix |
|---|
| Blob | blob.core.windows.net |
| File | file.core.windows.net |
| Queue | queue.core.windows.net |
| Table | table.core.windows.net |
| Data Lake Gen 2 | dfs.core.windows.net |
Example: a blob named employee-data.json in container 'may-2023' in storage account 'monthly-report' has the URL https://monthly-report.blob.core.windows.net/may-2023/employee-data.json. The exam will test whether you can construct these URLs.
Redundancy is how many copies of your data exist and where they live. The minimum is always three copies. The question is just how spread out they are.
| Option | Copies | Protects against | When to use |
|---|---|---|---|
| LRS - Locally Redundant Storage | 3 copies in 1 datacenter | Hardware failure | Cheapest, dev/test, non-critical data |
| ZRS - Zone Redundant Storage | 3 copies across 3 availability zones | Datacenter failure in a region | Low-cost high availability within a region |
| GRS - Geo Redundant Storage | LRS in primary + LRS in paired region | Regional disaster | Business continuity |
| GZRS - Geo Zone Redundant Storage | ZRS in primary + LRS in paired region | Zone AND regional failure | Best protection available |
| RA-GRS / RA-GZRS | GRS/GZRS + read access to secondary | Regional disaster with read failover capability | Read-heavy DR scenarios |
Common exam scenarios Survive a datacenter failure, lowest cost → ZRS Survive a regional disaster → GRS or GZRS Need to read the secondary region without failing over → RA-GRS or RA-GZRS GRS does NOT allow reads from secondary until you fail over. RA-GRS does.
Replication to the secondary region is ASYNCHRONOUS - there is a small lag (usually minutes)
You can manually trigger failover from primary to secondary
The Azure portal shows the 'last sync time' indicating how up-to-date the replica is
Data written but not yet replicated when failover occurs is lost
Object replication lets you replicate blobs to a different storage account in any region - not just the paired region. You define replication rules per container, and can filter by prefix. Useful when you want fine-grained, non-paired-region replication.
GPv1 storage accounts DO NOT support ZRS or GZRS. If a question mentions GPv1 needing zone redundancy, the FIRST step is to upgrade to GPv2.
Access tiers are about balancing storage cost vs access cost. You pay more to STORE data in Hot, but less to READ it. Archive is the cheapest to store, but the most expensive to read and requires rehydration.
| Tier | Best for | Min duration | Storage cost | Access cost | Notes |
|---|---|---|---|---|---|
| Hot | Frequently accessed | None | Highest | Lowest | Default for new blobs |
| Cool | Infrequently accessed | 30 days | Medium | Higher | Online, instant access |
| Cold | Rarely accessed | 90 days | Low | High | Online, instant access |
| Archive | Long-term retention | 180 days | Lowest | Highest | OFFLINE - requires rehydration |
Archive is offline - rehydration required You cannot read directly from Archive. You must rehydrate first by changing the tier back to Hot, Cool, or Cold. Standard rehydration: up to 15 hours. High Priority rehydration: under 1 hour (for blobs under 10 GB) - costs more. Minimum durations: deleting before the minimum still bills you for the full minimum period.
Cool tier: minimum 30 days. Delete before that, you still pay for 30 days.
Cold tier: minimum 90 days.
Archive tier: minimum 180 days.
Lifecycle management rules automate tier transitions and deletions based on time conditions. You create rules that say things like 'move blobs to Cool after 30 days of last access' or 'delete after 365 days'.
| Supported account types for lifecycle mgmt |
|---|
| General Purpose v2 |
| Blob Storage account |
| Premium Block Blob |
| Azure Data Lake Storage Gen 2 |
Lifecycle management does NOT work with GPv1, File Storage, or standard FileShare-only accounts. If a question shows a GPv1 storage account needing tiering, the first step is to upgrade to GPv2.
daysAfterCreationGreaterThan - based on when the blob was created
daysAfterModificationGreaterThan - based on when the blob was last modified (most common)
daysAfterLastAccessTimeGreaterThan - based on when the blob was last accessed (requires last access tracking enabled)
If the question says 'move to Cool after 45 days NOT UPDATED' - the answer is daysAfterModificationGreaterThan. If it says 'NOT ACCESSED', it is daysAfterLastAccessTimeGreaterThan. Read carefully.
If multiple rules match a blob at the same time (e.g. one rule says 'move to Cool after 5 days', another says 'move to Archive after 5 days', another says 'delete after 5 days'), lifecycle management picks the CHEAPEST action. Delete is always cheaper than tier change. Archive is cheaper than Cool.
| Action | Block Blob | Append Blob | Page Blob |
|---|---|---|---|
| Tier to Cool / Cold / Archive | Yes | No | No |
| Delete | Yes | Yes | Yes |
Storage Service Encryption (SSE) is ALWAYS ON for every storage account. It cannot be disabled. You do not configure it. If a question says 'SSE is optional', the answer is False.
By default, SSE uses Microsoft-managed keys
You can switch to customer-managed keys (CMK) stored in Azure Key Vault
Use CMK when you need to control rotation, audit who uses the key, or revoke access
Supports RSA and RSA-HSM keys. Bit length 2048, 3072, or 4096 (4096 is max)
Encryption scopes let you use DIFFERENT keys for different containers or even individual blobs within the same storage account. Useful for multi-tenant ISV scenarios where each customer needs their own encryption key without spinning up separate storage accounts.
| Method | When to use | Security level |
|---|---|---|
| Storage Account Keys | Full admin access - emergency or legacy use | Lowest - treat like passwords |
| Entra ID + RBAC (data plane) | Recommended for internal Azure-to-Azure | Highest - no secrets to manage |
| Managed Identity | VMs/apps accessing storage | Highest - no secrets in code |
| SAS - Shared Access Signature | Time-limited delegated access | Medium - depends on signing key |
| SAS type | Description |
|---|---|
| Account SAS | Access to multiple services in the storage account |
| Service SAS | Access to one specific service (Blob, File, Queue, Table) |
| User Delegation SAS | Signed with Entra ID credentials - MOST SECURE |
User Delegation SAS is the answer for secure temporary access When the question asks for the 'most secure way to grant temporary access to a specific blob/container', the answer is User Delegation SAS - NOT account keys, NOT service SAS signed with the account key. If you disable account key access (which you should), service SAS tokens signed by the account key stop working too. User Delegation SAS still works because it is signed by Entra ID, not the account key.
Always use HTTPS when generating or distributing SAS
Use the SHORTEST expiration time necessary - never long-term
Reference Stored Access Policies where possible (allows revocation without regenerating)
Never share storage account keys directly
Use User Delegation SAS over service SAS when Entra ID is available
SAS tokens are TIME-LIMITED by design. They are NOT permanent access until revoked. If a question states 'SAS provides permanent access until revoked', the answer is False.
| Method | What it does |
|---|---|
| Public endpoint (default) | Anyone with credentials can reach the storage account |
| Service Endpoint | Restricts access to specific subnets in a VNet. Public endpoint still exists but only listed subnets can use it. |
| Private Endpoint | Gives the storage account a PRIVATE IP in your VNet. Public endpoint can be fully disabled. |
| IP firewall rules | Restrict by specific public IP ranges |
If the question says 'must be accessible ONLY via private IP, no public internet exposure', the answer is Private Endpoint - NOT Service Endpoint. Service Endpoint still uses the public endpoint, it just locks down who can talk to it.
| Tool | What it does | When to use |
|---|---|---|
| AzCopy | Command-line bulk data transfer | Cross-account, on-prem to Azure, cross-cloud, scripted/automated transfers |
| Azure Storage Explorer | GUI for browsing storage | Manual inspection, uploads, troubleshooting. CANNOT create new storage accounts. |
| Azure File Sync | Sync Windows file servers with Azure Files | Hybrid file shares, cloud tiering |
| Azure Import/Export | Ship physical drives to Azure datacenters | Smaller offline migrations (terabytes, not hundreds) |
| Azure Data Box | Microsoft-supplied hardware for offline migration | Large migrations (tens to hundreds of TB), 256-bit encrypted |
| Azure Data Box Heavy | Higher capacity Data Box | Hundreds of TB, limited bandwidth scenarios |
| Service | Supported auth methods |
|---|---|
| Blob storage | Entra ID AND SAS |
| File storage | SAS only |
AzCopy with File Storage supports SAS only. You CANNOT use Entra ID. This is a Microsoft trick question. For Blob storage, both Entra ID and SAS work.
azcopy make - create a container or file share
azcopy copy - copy data between source and destination
azcopy sync - sync data, only transferring changes
azcopy list - list objects
Azure File Sync lets you sync on-premises Windows file servers with Azure Files. The cloud share is the source of truth, but users access files locally on their nearest server. Cloud Tiering offloads cold files to Azure to save local disk space.
Create a Storage Sync Service in Azure
Install the Azure File Sync agent on the on-prem server
Register the server with the Storage Sync Service
Create a Sync Group and a Cloud Endpoint (an Azure file share)
Add a Server Endpoint (a folder path on the registered server)
Sync Group constraints A Sync Group has exactly ONE cloud endpoint (one Azure file share). A Sync Group can have MULTIPLE server endpoints (one per server, or more across different servers). You CANNOT have two server endpoints from the SAME server in the SAME sync group.
When you add a server endpoint to an existing sync group, Azure File Sync does NOT automatically overwrite files - it compares and merges. Files in the cloud and files on the server are reconciled, not blindly replaced.
Files added to a CLOUD endpoint take up to 24 hours to be detected and synced to server endpoints. Files added to a SERVER endpoint sync to other endpoints much faster (typically minutes).
Soft delete protects blobs and file shares from accidental deletion
Default retention is configurable, typically 7-14 days
Versioning keeps prior versions of blobs when overwritten
Snapshots create point-in-time copies of file shares or blobs
Change Feed logs every change to blobs (useful for audit and replication)
Key Vault stores secrets, keys, and certificates. It is the answer to almost every 'where do I put my password' question on the exam.
Secrets - any string value (passwords, connection strings, API keys)
Keys - cryptographic keys for encryption/decryption (RSA, EC, AES)
Certificates - X.509 certificates with private keys
When a question mentions storing passwords or secrets The answer is almost always Azure Key Vault + an access policy. The access policy grants the VM or app permission to retrieve the secret from the vault. Never store passwords in ARM template parameters as plain text.
Vault Access Policies - the legacy authorization model, granular per-vault
RBAC - the newer recommended model, integrates with Azure RBAC
Both can be used, but you cannot mix them on the same vault for the same identity
Managed disks are the storage attached to VMs. Microsoft handles the underlying storage account; you just see the disk. There are four performance tiers.
| Disk type | Best for | Performance |
|---|---|---|
| Standard HDD | Backup, dev/test, infrequent access | Lowest |
| Standard SSD | Web servers, light DBs, dev/test that needs SSD | Medium |
| Premium SSD | Production workloads, databases | High - guaranteed IOPS |
| Premium SSD v2 | Newer, flexible IOPS/throughput sizing | Higher |
| Ultra Disk | Mission-critical, lowest latency | Highest - sub-ms latency |
The 's' in a VM size (e.g. Standard_D4s_v5) means it supports Premium SSDs. Without the 's', you can only attach Standard HDDs and SSDs. Always look for the 's' suffix when premium storage is in the requirements.
| Method | How it encrypts | Notes |
|---|---|---|
| SSE with platform keys | Microsoft manages keys | Default, always on |
| Disk Encryption Set (DES) + CMK | Customer-managed key in Key Vault | Encrypts disks at the platform level |
| Azure Disk Encryption (ADE) | BitLocker (Windows) or DM-Crypt (Linux) inside the guest | Encryption survives if the disk is downloaded from Azure |
| Encryption at Host | Encrypts cache + temp disk on the host | Combines well with DES for full coverage |
If the question says 'encryption must persist if the disk is downloaded from Azure', the answer is Azure Disk Encryption (ADE) - it encrypts inside the guest OS using BitLocker/DM-Crypt, so the encryption travels with the disk.
Data disks can be detached from a RUNNING VM If a question asks how to move a data disk between VMs with minimum downtime, the answer is to detach the data disk WHILE THE VM IS RUNNING. No stop required. Exception: OS disks DO require the VM to be stopped to detach.