15-20% of exam
Implement and Manage Storage
Configure storage accounts, redundancy, blob lifecycle management, and secure access with SAS tokens and network rules.
Manage Azure Identities and GovernanceImplement and Manage StorageDeploy and Manage Azure Compute ResourcesImplement and Manage Virtual NetworkingMonitor and Maintain Azure Resources
Storage accounts and redundancy options
A storage account is the top-level namespace for Blob, File, Table, and Queue storage, and determines the redundancy and performance characteristics of everything inside it.
Redundancy options
- LRS (locally redundant storage): copies data three times within a single datacenter.
- ZRS (zone-redundant storage): copies data across three availability zones in the same region.
- GRS (geo-redundant storage): copies data to a paired secondary region, asynchronously; the secondary copy isn't readable unless a failover occurs.
- RA-GRS / RA-GZRS: adds read access to the secondary region without waiting for a failover.
Performance tiers
- Standard: HDD-backed, general-purpose, lowest cost.
- Premium: SSD-backed, used for workloads needing low latency and high throughput, such as VM disks.
Common confusion
- Redundancy protects against hardware and datacenter failure; it is not a backup strategy for accidental deletion or corruption, which requires soft delete, versioning, or a dedicated backup solution.
Blob access tiers and lifecycle management
Blob storage supports access tiers that trade cost for retrieval latency and price, and lifecycle policies that move or delete blobs automatically as they age.
Access tiers
- Hot: optimized for frequently accessed data; highest storage cost, lowest access cost.
- Cool: for infrequently accessed data stored at least 30 days; lower storage cost, higher access cost.
- Cold: for rarely accessed data stored at least 90 days; lower storage cost than Cool, higher access cost.
- Archive: lowest storage cost, but blobs must be rehydrated (which takes hours) before they can be read.
Lifecycle management policies
- Rules are rule-based, defined in JSON, and can move blobs between tiers or delete them based on age since last modification or last access.
- Typical pattern: Hot for 30 days, then Cool, then Archive after a year, then delete after a compliance retention period.
Common confusion
- Rehydrating an Archive blob is a request, not instant — plan for a delay before the data becomes readable again.
Securing storage: SAS, access keys, and networking
Storage accounts support several distinct ways to control access, and picking the right one matters for both security and the exam.
Access methods
- Account access keys: full control over the entire storage account; should be rotated periodically and treated as highly sensitive.
- Shared Access Signature (SAS): a time-limited, scoped token granting specific permissions (read, write, list, delete) to specific resources, without exposing the account key.
- Microsoft Entra ID authentication: assigns RBAC roles like Storage Blob Data Reader directly to identities, avoiding shared secrets entirely.
SAS types
- Service SAS: scoped to one storage service (for example, only Blob).
- Account SAS: scoped across multiple services in the account.
- User delegation SAS: signed with Entra ID credentials instead of the account key, and is the recommended approach when RBAC-based access isn't practical.
Network access controls
- Firewall rules can restrict access to selected virtual networks or public IP ranges.
- Private endpoints assign the storage account a private IP inside a virtual network, removing public internet exposure entirely.