Domain 2: Implement and Manage Storage
Exam weight: 15–20%
Storage tests your ability to provision and operate Azure's data services. The trickiest parts are replication type trade-offs, SAS token mechanics, and access tier transitions — all of which appear repeatedly in exam questions and live lab tasks.
2.1 Storage Account Types
All Azure storage services (Blob, Files, Queues, Tables) live inside a storage account. The account type determines which services and performance tiers are available.
| Account kind | Services | Performance |
|---|---|---|
| General Purpose v2 (GPv2) | Blob, Files, Queues, Tables | Standard or Premium |
| Blob Storage (legacy) | Blob only | Standard — upgrade to GPv2 instead |
| Premium Block Blobs | Block blobs only | Premium SSD |
| Premium File Shares | Azure Files only | Premium SSD |
| Premium Page Blobs | Page blobs only (VM disks) | Premium SSD |
Exam tip: For any new deployment, use GPv2. The exam will sometimes offer "Blob Storage account" as an option — it's a legacy type that you should not choose unless the question specifically requires it.
2.2 Redundancy (Replication)
This is the highest-frequency storage topic in the exam. Know every acronym, what it protects against, and whether reads can be made from the secondary.
| Replication | Full name | Copies | Protects against | Read from secondary? |
|---|---|---|---|---|
| LRS | Locally Redundant Storage | 3 in 1 datacenter | Hardware failure | No |
| ZRS | Zone-Redundant Storage | 3 in 3 zones, 1 region | Zone (datacenter) failure | No |
| GRS | Geo-Redundant Storage | 3 LRS primary + 3 LRS secondary region | Regional failure | No (unless RA-GRS) |
| GZRS | Geo-Zone-Redundant Storage | 3 ZRS primary + 3 LRS secondary region | Zone + regional failure | No (unless RA-GZRS) |
| RA-GRS | Read-Access GRS | Same as GRS | Regional failure | Yes — secondary endpoint |
| RA-GZRS | Read-Access GZRS | Same as GZRS | Zone + regional failure | Yes — secondary endpoint |
Secondary Endpoint Format
For RA-GRS/RA-GZRS, the secondary read endpoint is:
https://<account>-secondary.blob.core.windows.net
Exam trap: GRS replicates data to a secondary region but you cannot read from the secondary by default. Only RA-GRS (and RA-GZRS) enable reads from the secondary. Questions that say "users in a secondary region must be able to read data even during a primary region outage" → RA-GRS or RA-GZRS.
Exam trap: You can only failover a GRS account to the secondary region if Microsoft declares the primary unavailable — or you manually initiate customer-managed failover. After failover, replication is broken; you must re-enable it.
2.3 Access Tiers
Access tiers apply to Blob storage and control the cost balance between storage cost and access cost.
| Tier | Storage cost | Access cost | Minimum storage duration | Use case |
|---|---|---|---|---|
| Hot | Highest | Lowest | None | Frequently accessed data |
| Cool | Lower | Higher | 30 days | Infrequent access, kept ≥30 days |
| Cold | Lower than Cool | Higher than Cool | 90 days | Infrequent access, kept ≥90 days |
| Archive | Lowest | Highest + rehydration time | 180 days | Rarely accessed, long-term |
Archive Rehydration
Blobs in Archive tier are offline — you cannot read them directly. You must rehydrate first:
- Priority: Standard — up to 15 hours
- Priority: High — under 1 hour (higher cost)
Rehydration options:
- Change the blob tier to Hot or Cool (
Set Blob Tier) - Copy the blob to a Hot/Cool destination
Exam trap: Archive blobs cannot be read without rehydration. Questions about "immediate read access" → answer must not use Archive tier.
Lifecycle Management Policies
Automate tier transitions and deletions based on rules:
{
"rules": [{
"name": "move-to-cool",
"type": "Lifecycle",
"definition": {
"filters": { "blobTypes": ["blockBlob"], "prefixMatch": ["logs/"] },
"actions": {
"baseBlob": {
"tierToCool": { "daysAfterModificationGreaterThan": 30 },
"tierToArchive": { "daysAfterModificationGreaterThan": 90 },
"delete": { "daysAfterModificationGreaterThan": 365 }
}
}
}
}]
}
2.4 Blob Types
| Type | Description | Use case |
|---|---|---|
| Block blob | Optimized for large objects uploaded in blocks | Files, media, backups |
| Append blob | Optimized for append-only operations | Logs, event streams |
| Page blob | Random read/write in 512-byte pages | Azure VM disks (VHDs) |
Exam tip: VM unmanaged disks = Page blobs. You cannot change blob type after creation.
2.5 Access Control Options
Three ways to authorize access to storage — each with different trade-offs:
1. Access Keys (Account Keys)
- Two keys per account (Key1, Key2) — rotate without downtime.
- Full access to everything in the account — no scoping possible.
- Should be stored in Azure Key Vault, not in code.
- Listing keys is blocked by a ReadOnly lock.
2. Shared Access Signatures (SAS)
A SAS is a URI that grants scoped, time-limited access.
| SAS type | Signs with | Revoke how |
|---|---|---|
| Account SAS | Account access key | Rotate the key (affects all SAS signed with it) |
| Service SAS | Account access key | Rotate the key |
| User Delegation SAS | Entra ID credentials | Revoke via az storage account revoke-delegation-keys |
Exam tip: User delegation SAS is the most secure type — it uses Entra identity, not the account key, so rotating keys doesn't affect it. It's scoped to Blob or Data Lake only.
Stored Access Policy
A Stored Access Policy (SAP) is defined on a container (not the account). SAS tokens can reference a SAP by name, which allows you to revoke the SAS without rotating the key — just delete or modify the SAP.
Exam trap: You can only revoke a standalone SAS (not linked to a SAP) by rotating the signing key. If a question says "revoke specific SAS without affecting other SAS tokens" → the answer involves a Stored Access Policy.
3. Managed Identity + Role Assignment
Assign a storage data role to the managed identity:
Storage Blob Data Reader— read blobsStorage Blob Data Contributor— read/write/delete blobsStorage Blob Data Owner— full control including POSIX ACLs
Exam tip: For service-to-storage auth, managed identity + RBAC data role is the recommended approach. It eliminates credentials entirely.
2.6 Azure Files
Azure Files provides SMB and NFS file shares in the cloud — a lift-and-shift replacement for on-prem file servers.
| Protocol | Port | Auth options |
|---|---|---|
| SMB 3.0 | 445 | AD DS, Entra ID, Storage Account Key |
| NFS 4.1 | 2049 | VNet integration (no public access) |
Exam trap: Port 445 (SMB) is blocked by many ISPs and corporate firewalls. If users can't mount a file share from home, the fix is to use Azure VPN or Azure File Sync to cache files locally, not to change the port.
Azure File Sync
Extends Azure Files to on-premises servers:
- Install the Azure File Sync agent on Windows Server.
- Enables cloud tiering: frequently accessed files stay local; cold files are tiered to Azure (appear as stubs).
- Multiple servers can sync to the same share — replacing DFS.
2.7 Storage Security
Encryption
- At rest: All data is encrypted by default using Microsoft-managed keys (256-bit AES).
- Customer-managed keys (CMK): Bring your own key stored in Azure Key Vault — you control rotation and revocation.
- In transit: HTTPS is enforced by default (
Secure transfer requiredis on).
Versioning and Soft Delete
| Feature | What it does | Scope |
|---|---|---|
| Blob versioning | Keeps every previous version of a blob on overwrite | Per storage account |
| Blob soft delete | Retains deleted blobs for a configurable retention period | Per storage account |
| Container soft delete | Retains deleted containers | Per storage account |
Immutability (WORM)
WORM (Write Once Read Many) policies prevent deletion or modification for a set period:
- Time-based retention: Data cannot be modified or deleted for a defined interval.
- Legal hold: Data locked until the hold is explicitly removed.
Used for compliance scenarios (financial records, healthcare). Even storage account admins cannot delete data under an active WORM lock.
Section Takeaways
| Topic | Key Point |
|---|---|
| GPv2 | Default choice for all new storage accounts |
| LRS vs ZRS vs GRS | LRS = 1 DC; ZRS = 3 zones; GRS = 2 regions |
| RA-GRS vs GRS | Only RA-GRS allows reading from secondary |
| Archive tier | Must rehydrate before reading — up to 15 hours standard |
| SAS revocation | Standalone SAS = rotate key; SAP-linked SAS = delete/modify SAP |
| User delegation SAS | Most secure — uses Entra ID, not account key |
| Managed identity for storage | Best practice — no credentials to manage |
| ReadOnly lock + storage | Blocks listKeys — even for Owners |
| SMB port 445 | Often blocked by ISPs — use VPN or File Sync as workaround |
| WORM policy | Even admins cannot delete data under active retention/hold |
Confusing Points — Clarified
Q: If GRS replicates to a second region, why can't I read from it? A: Replication is asynchronous and the secondary is a failover target, not a read replica. Microsoft wants to avoid you building apps that depend on eventual consistency without realizing it. You must opt into RA-GRS explicitly to get read access to the secondary.
Q: What happens to SAS tokens if I rotate the account key? A: Any SAS signed with that key immediately becomes invalid. This is why SAP-linked SAS tokens are better — you can invalidate just the policy without rotating the key.
Q: Can I change a blob's access tier at any time? A: Yes, but early deletion fees apply if you move out of Cool (before 30 days), Cold (before 90 days), or Archive (before 180 days).
Q: What's the difference between Storage Blob Data Contributor and Contributor?
A: Contributor is an Azure RBAC management-plane role — it can manage the storage account (create containers, change settings) but cannot read/write blob data without also having a data plane role. Storage Blob Data Contributor grants data-plane access (read/write blob content). Both are often needed together.