Microsoft AZ-900: Storage & Databases — Study Guide

By Laurynas Brazys · 22 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

Part of the Microsoft Azure AZ-900 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Azure provides a broad foundation for storing unstructured and structured data at global scale, with integrated durability, security, and cost controls. Understanding the right storage primitive, redundancy model, access tier, and database service unlocks reliable, performant applications from virtual machines to globally distributed web and mobile platforms.

Azure Storage services and managed disks

Azure Blob Storage is the cornerstone for unstructured data. Block blobs handle large objects with efficient streaming and parallel upload, snapshots, versioning, and tiering. Page blobs are optimized for random read/write I/O in 512‑byte pages and back virtual hard disks; they sit underneath disks and scenarios that demand consistent low‑latency IOPS. Append blobs are tailored for write‑heavy append scenarios like application logs, where new blocks are efficiently added to the end. Azure Files offers fully managed file shares accessible over SMB or NFS with NTFS ACLs, directory integration options, and Azure File Sync to cache hot data on Windows Servers. Queue Storage provides lightweight, durable application messaging to decouple components with at‑least‑once delivery semantics. Table Storage supplies a schemaless key/attribute store for vast, partitioned datasets where you control partition and row keys for scale and cost efficiency. Managed disks provide durable, persistent block storage to Azure Virtual Machines without managing storage accounts or page blobs directly. Choose from Standard HDD for cost‑optimized throughput workloads, Standard SSD for balanced performance, Premium SSD and Premium SSD v2 for low‑latency high IOPS, and Ultra Disk for the most demanding transactional workloads with configurable IOPS and throughput. Managed disks support snapshots, incremental backups, disk encryption, and availability options aligned to your VM SLAs.

• Blob – Block blob
  • Data model or IO pattern: Large object, sequential IO
  • Key capabilities: Tiering, snapshots, versioning, lifecycle policies
  • Typical use cases: Images, video, backups, big data landing zones
  • Notable limits/notes: Single blob up to ~190 TiB; not optimized for random IO
• Blob – Page blob
  • Data model or IO pattern: Random IO in 512‑byte pages
  • Key capabilities: Low‑latency reads/writes, VHD backing
  • Typical use cases: Underlying storage for disks and scenarios needing random access
  • Notable limits/notes: Page blob size up to 8 TiB; managed disks abstract this
• Blob – Append blob
  • Data model or IO pattern: Append‑only writes
  • Key capabilities: Efficient log appends, immutability options
  • Typical use cases: Telemetry and application logs
  • Notable limits/notes: Update in place not supported; block count limits apply
• Azure Files
  • Data model or IO pattern: POSIX/SMB/NFS file semantics
  • Key capabilities: SMB/NFS access, NTFS ACLs, AD DS/Azure AD DS integration, File Sync
  • Typical use cases: Lift‑and‑shift file shares, app configuration, user home directories
  • Notable limits/notes: Standard and Premium tiers; large file shares up to 100 TiB
• Queue Storage
  • Data model or IO pattern: Message queue
  • Key capabilities: At‑least‑once delivery, visibility timeouts, poison message handling
  • Typical use cases: Background processing, decoupled microservices
  • Notable limits/notes: Message size up to 64 KB (use Service Bus for larger/advanced patterns)
• Table Storage
  • Data model or IO pattern: Key/attribute NoSQL
  • Key capabilities: Massive scale, partitioning by PartitionKey, low cost
  • Typical use cases: Telemetry, catalogs, user profiles
  • Notable limits/notes: No joins or secondary indexes; Cosmos DB Table API for global needs
• Managed disks
  • Data model or IO pattern: Block storage for VMs
  • Key capabilities: Standard/Premium/Ultra SKUs, snapshots, scaling, disk encryption
  • Typical use cases: OS/data disks for VMs, DBs, line‑of‑business apps
  • Notable limits/notes: Up to 32 TiB per disk; ZRS available for select SKUs

Redundancy and durability options

Redundancy models define where and how many synchronous and asynchronous replicas Azure maintains for your data. Locally redundant storage (LRS) keeps three copies within a single datacenter in one region, protecting against drive and rack failures at the lowest cost. Zone‑redundant storage (ZRS) spreads three synchronous copies across separate availability zones in a region, providing resilience to a zonal outage without application failover. Geo‑redundant storage (GRS) extends LRS by asynchronously replicating your data to the paired region, yielding six total copies across two regions; after Microsoft initiates account failover, the secondary becomes the new primary. Read‑access geo‑redundant storage (RA‑GRS) adds a live, read‑only secondary endpoint so applications can read from the secondary region even before failover, enabling global read distribution and analytics offloading. Geo‑zone‑redundant storage (GZRS) combines ZRS in the primary region with asynchronous replication to LRS in the paired region, protecting against both zonal and regional failures; a read‑access variant (RA‑GZRS) provides read endpoints on the secondary. Selection is driven by recovery objectives, latency expectations, and budget. Within a region, ZRS protects against zone failures while keeping write latency low. Across regions, GRS/RA‑GRS and GZRS are preferred for disaster recovery and cross‑regional read scenarios. Data consistency to the secondary region is asynchronous by design in geo options, so applications should tolerate eventual consistency until a failover completes.

• LRS
  • Replication layout: 3 copies in a single datacenter (region)
  • Read access to secondary: No
  • Regional/zone tolerance: Protects against local hardware/rack failures
  • Common workloads: Dev/test, low‑cost storage, noncritical data
• ZRS
  • Replication layout: 3 copies synchronously across 3 availability zones (region)
  • Read access to secondary: No
  • Regional/zone tolerance: Survives zonal outages without app‑level failover
  • Common workloads: Production web/app content needing high regional availability
• GRS
  • Replication layout: LRS in primary + async LRS in paired region (total ~6 copies)
  • Read access to secondary: No
  • Regional/zone tolerance: Regional DR via account failover; no zonal protection in primary
  • Common workloads: Backup/archival with regional DR posture
• RA‑GRS
  • Replication layout: GRS + read endpoint on secondary region
  • Read access to secondary: Yes
  • Regional/zone tolerance: Same as GRS; enables global read distribution
  • Common workloads: Global content reads, analytics/reporting off secondary
• GZRS
  • Replication layout: ZRS in primary + async LRS in paired region
  • Read access to secondary: No (use RA‑GZRS)
  • Regional/zone tolerance: Protects against zonal failures and regional disasters
  • Common workloads: Mission‑critical apps requiring zone + geo resilience

Access tiers and lifecycle management

Blob access tiers align storage cost with access patterns. The Hot tier is optimized for frequent access with the lowest read and write transaction costs at a higher per‑GB storage price. The Cool tier lowers the per‑GB storage price and increases transaction and early deletion costs, making it suitable for datasets accessed infrequently, such as monthly reports or short‑term backups. The Archive tier offers the lowest storage cost but requires rehydration before access, with the highest access and early deletion fees; it is designed for long‑term retention and compliance scenarios. Lifecycle management policies automate tiering and retention at the container or account level. Rules can transition blobs between Hot, Cool, and Archive based on last modified time, last access time, or blob index tags; and delete versions, snapshots, or base blobs after a defined age. Policies help compress total cost of ownership by moving cold data out of Hot storage and retiring obsolete data without manual intervention. Lifecycle management is available for general‑purpose v2 and Blob storage accounts and operates on block and append blobs; it is not applicable to premium block blob storage. Archive rehydration supports standard and high‑priority options, trading cost for speed. Plan for retrieval windows measured in hours for standard rehydration and minutes to hours for high‑priority on smaller objects. For compliance, pair Archive with immutability policies (time‑based retention or legal hold) to enforce write‑once, read‑many (WORM) guarantees at the container or blob level.

• Hot
  • Storage cost: Highest
  • Access/transaction cost: Lowest
  • Minimum retention: None
  • Retrieval latency: Milliseconds (online)
  • Typical data: Active content, frequently read/write data
• Cool
  • Storage cost: Lower than Hot
  • Access/transaction cost: Higher than Hot; early deletion fee applies
  • Minimum retention: 30 days
  • Retrieval latency: Milliseconds (online)
  • Typical data: Infrequently accessed data, short‑term backups
• Archive
  • Storage cost: Lowest
  • Access/transaction cost: Highest; early deletion fee applies
  • Minimum retention: 180 days
  • Retrieval latency: Hours (rehydration required)
  • Typical data: Long‑term retention, compliance archives, rarely accessed backups

Security, encryption, and access control

Encryption at rest is enabled by default via Storage Service Encryption (SSE). By default, Microsoft‑managed keys protect data transparently. For stricter control and separation of duties, customer‑managed keys (CMK) can be configured per storage account using keys in Azure Key Vault or a Managed HSM, supporting key rotation and revocation workflows. For sensitive workloads, double encryption and confidential computing options further reduce data exposure risks. In transit, enforce HTTPS with TLS for all data‑plane operations. Access control spans identity‑based authorization and scoped tokens. Azure RBAC integrates with Microsoft Entra ID to grant least‑privilege data‑plane access such as Storage Blob Data Reader/Contributor roles to users, groups, and managed identities. RBAC eliminates shared secrets and supports conditional access, Privileged Identity Management, and auditing. Shared Access Signatures (SAS) delegate time‑bound, permission‑scoped access to clients that may not have an identity; SAS can be signed with account keys or with user delegation using Microsoft Entra credentials to avoid exposing account keys. Combine RBAC for service‑to‑service and administrative access with SAS for temporary client access flows. Protect account keys and rotate them regularly; prefer user delegation SAS when possible. Network isolation with Private Endpoints or service endpoints, firewall rules, and immutable storage policies round out a defense‑in‑depth posture for storage accounts.

• Azure RBAC (Microsoft Entra ID)
  • Scope: Identity‑based roles on storage data plane and management plane
  • Best for: Admins, services, and apps with managed identities
  • Key properties: Least privilege, conditional access, auditability, no shared secrets
  • Risk considerations: Requires identity integration; revoke via role changes
• Shared Access Signature (SAS)
  • Scope: Time‑bound, permission‑scoped tokens on specific resources
  • Best for: Delegating limited access to clients/partners
  • Key properties: Granular permissions, IP/time constraints; user‑delegation SAS avoids account keys
  • Risk considerations: Token leakage grants access until expiry; protect distribution and set short lifetimes

Relational PaaS and globally distributed NoSQL

Azure SQL Database delivers a managed relational engine with automatic patching, built‑in high availability, backups, and scaling. Deploy single databases or elastic pools to consolidate variable workloads. The service maintains multiple replicas within a region and supports zone redundancy; Transparent Data Encryption (TDE) is on by default. Automated backups enable point‑in‑time restore typically for 7–35 days with optional long‑term retention up to years in Azure storage. For multi‑region resilience and low‑latency reads, use active geo‑replication (up to four readable secondaries) or Auto‑failover groups for coordinated DR at scale. Azure SQL Managed Instance offers near 100% SQL Server engine compatibility for instance‑level features like SQL Agent, cross‑database queries, Service Broker, and CLR, enabling straightforward modernization from on‑premises without refactoring. It shares the same managed HA architecture, online patching, automated backups, TDE by default, and supports auto‑failover groups between regions. Network isolation with private endpoints and per‑database or per‑instance compute/storage scaling provide predictable performance envelopes. Azure Cosmos DB provides a fully managed, multi‑model NoSQL database with turnkey global distribution and multi‑region writes. It guarantees single‑digit millisecond latencies at the 99th percentile within a region and offers five tunable consistency levels to balance performance and correctness across regions. Provision throughput in RU/s or use autoscale, add or remove regions without downtime, and configure automatic failover. APIs include Core (SQL), MongoDB, Cassandra, Gremlin, and Table, simplifying migration and integration across diverse application stacks.

• Azure SQL Database
  • Model: Relational PaaS (single DB/elastic pool)
  • Compatibility: Latest SQL features; app‑level compatibility
  • HA/DR: Built‑in replicas, zone redundancy; active geo‑replication; Auto‑failover groups
  • Backups/TDE: Automatic PITR 7–35 days; LTR up to years; TDE on by default
  • Geo options: Readable secondaries across regions; coordinated failover groups
  • Best suited for: SaaS/multi‑tenant apps, new cloud‑native relational workloads
• Azure SQL Managed Instance
  • Model: Relational PaaS (instance)
  • Compatibility: High SQL Server feature parity incl. SQL Agent, cross‑DB
  • HA/DR: Built‑in HA; zone redundancy; Auto‑failover groups
  • Backups/TDE: Automatic PITR 7–35 days; LTR; TDE on by default; native restore support
  • Geo options: Multi‑region with failover groups and readable secondaries
  • Best suited for: Lift‑and‑shift of on‑prem SQL with minimal changes
• Azure Cosmos DB
  • Model: NoSQL, multi‑model (Core, MongoDB, Cassandra, Gremlin, Table)
  • Compatibility: API‑level compatibility for popular NoSQL stacks
  • HA/DR: Multi‑region, multi‑master writes; 99.99% SLAs
  • Backups/TDE: Automated and continuous backup options; encryption at rest
  • Geo options: Add/remove regions live; tunable consistency; automatic failover
  • Best suited for: Global, low‑latency apps, IoT, catalogs, personalization

Practical Problem: Tailwind Traders: Bicoastal resiliency with secure, cost‑optimized data tiers

Scenario: Tailwind Traders runs ecommerce operations with primary workloads in East US and a disaster recovery presence in West US. Product images and logs are stored in object storage, while orders and inventory run on a managed relational database. During regional incidents, the business requires read access to product media from the secondary region to keep the catalog browsable. Data governance demands encryption with customer‑managed keys and time‑based retention of audit logs.

Challenge: Design storage and database services that provide cross‑region read access for media, automated lifecycle and retention for logs, strong encryption and least‑privilege access, and a managed relational backend with built‑in high availability and disaster recovery.

Recommended Approach:

1. 1. Create a general‑purpose v2 storage account in East US with RA‑GRS (or RA‑GZRS if zone resilience is also required) for product media containers.
2. 2. Enable HTTPS‑only, configure a private endpoint to the VNet, and integrate customer‑managed keys from Azure Key Vault for the storage account.
3. 3. Define lifecycle policies: move media not accessed for 30 days to Cool, and to Archive after 180 days; delete archived media after 5 years.
4. 4. For append‑only application logs, use an append‑blob container with immutable (time‑based) retention policies and a separate lifecycle rule to transition older logs to Archive.
5. 5. Grant application access using Azure RBAC (Storage Blob Data Contributor) to managed identities; issue short‑lived user‑delegation SAS for partner uploads to a staging container.
6. 6. Provision Azure SQL Database (Business Critical or General Purpose with zone redundancy) for orders and inventory; configure Auto‑failover groups to replicate to West US.
7. 7. Validate automatic backups (PITR 7–35 days) and enable long‑term retention for compliance databases as required.
8. 8. Implement Transparent Data Encryption (enabled by default) and, if required, bring your own key for the SQL server resource.
9. 9. Update the ecommerce app to read product media via the secondary RA endpoint when the primary region is degraded; continue transactional writes to primary SQL until failover.
10. 10. Conduct failover drills for both storage (account failover) and SQL (Auto‑failover group) and document RTO/RPO against business targets.

Azure Rationale: RA‑GRS provides three synchronous replicas in the primary region plus asynchronous replication to the paired region and exposes a read‑only secondary endpoint, meeting the requirement to serve catalog reads during a regional disruption. Lifecycle policies align storage costs to access patterns by tiering infrequently accessed media to Cool and Archive and enforcing time‑based retention for logs with immutability. Customer‑managed keys and private endpoints strengthen security and compliance, while Azure RBAC and user‑delegation SAS enforce least privilege and safe delegation. Azure SQL Database offers built‑in HA, TDE, and automated backups; Auto‑failover groups deliver controlled, tested cross‑region failover for transactional workloads to maintain service continuity.

← Networking · All domains · Identity →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Microsoft →