Microsoft AZ-305: Choosing the Right Azure Storage

Storage questions in Microsoft AZ-305 are architecture questions before they are service-name questions. A design has to match data shape, transaction behavior, latency, durability, sovereignty, recovery, security, and cost. The exam rewards candidates who can explain why a storage pattern fits the workload instead of selecting a familiar product by habit.

Microsoft’s April 17, 2026 blueprint places data-storage design at 20–25% of the exam. That weighting includes relational and non-relational data, data integration, storage accounts, redundancy, access patterns, and protection. A reliable method is to turn every scenario into constraints first, then eliminate storage options that cannot satisfy them.

Start with the data, not the product

Identify whether the workload stores structured transactions, documents, key-value records, large objects, shared files, analytical data, or block storage for virtual machines. Also identify the access pattern. A low-latency transactional system behaves differently from a data lake that is written in batches and scanned by analytics engines.

Architecture candidates should be comfortable separating operational and analytical needs. The distinction behind data warehouses and data lakes is useful because the same business dataset can require different storage forms as it moves from ingestion to curated reporting. Choosing one store for every stage usually creates unnecessary compromises.

Choose relational storage when consistency and transactions dominate

Relational systems remain a strong fit when the application needs multi-row transactions, well-defined schemas, joins, constraints, and predictable query semantics. The architect then decides how much platform management the organization wants, how much compatibility the application requires, and whether the database must scale within a region or across regions.

High availability and disaster recovery are separate considerations from the database engine itself. A managed relational platform can simplify patching and backups, but the design still needs to specify zone resilience, replicas, failover behavior, connection handling, and what happens when a region is unavailable.

Use non-relational patterns for the right access model

Document, key-value, graph, and wide-column designs are useful when the application needs flexible schema, massive horizontal scale, or predictable access by key. The best AZ-305 answer matches the data model to the actual query pattern. A globally distributed application may value local reads and tunable consistency more than complex joins.

Do not treat NoSQL as a synonym for faster. Poor partitioning can create hot keys, uneven throughput, or expensive scans. A sound design selects a partition key that spreads load, aligns with common queries, and avoids forcing cross-partition operations for the hottest paths.

Match object, file, and block storage to workload semantics

Object storage is a natural fit for unstructured content, backups, logs, media, and data-lake layers. Shared file services are useful when applications expect file-system semantics or need SMB/NFS-style access. Block storage belongs close to compute where operating systems and database engines expect disks rather than objects.

Block, file, and object storage expose different application contracts. A storage-area network helps illustrate why Azure-managed disks behave differently from shared file services even when the physical infrastructure is abstracted.

Design redundancy from the failure model

Redundancy options should be chosen according to the failures the business is willing to tolerate. Local redundancy protects against component failure inside a datacenter. Zone-aware designs survive a zone outage. Geo-redundant approaches address regional loss but introduce replication lag, failover procedures, and additional cost.

Read-access requirements matter as well. A replica that exists only for disaster recovery is different from a secondary region that applications can read during normal operations. The architecture should state whether failover is automatic or operator-controlled and how DNS, application configuration, and data consistency behave after a switch.

Protect data with identity, encryption, and network controls

Encryption at rest is only one part of storage security. The design should address who can authenticate, what roles they receive, whether shared keys are allowed, how secrets are rotated, and whether traffic can reach the service from the public internet. Managed identity and granular authorization reduce the need to distribute storage credentials.

Private endpoints, service firewalls, and network segmentation can reduce exposure, while role-based access control limits what authenticated identities can do. The strongest answer combines identity and network boundaries instead of assuming either one can replace the other.

Treat backup, versioning, and retention as different controls

A backup creates a recovery copy. Versioning protects against accidental overwrite or deletion. Immutability can protect data from alteration. Retention policies enforce how long content must remain. These controls solve overlapping but distinct problems, and regulated workloads may require several of them at once.

Recovery design should also test the restore path. A backup policy that has never been restored under realistic load is an assumption rather than a proven control. Architects should estimate restore duration, dependency order, key availability, network throughput, and application validation after recovery.

Balance performance against cost deliberately

Performance choices include storage tier, IOPS, throughput, caching, partitioning, replication, and proximity to compute. The cheapest tier is not automatically cost-effective if retrieval charges, transaction volume, or latency force the application to compensate elsewhere. Conversely, premium storage can be wasteful for infrequently accessed data.

Lifecycle policies can move older objects to cooler tiers, while reserved capacity or service-specific commitments may reduce predictable spending. The design should separate steady-state cost from exceptional costs such as rehydration, cross-region replication, egress, and large-scale restore operations.

Solve AZ-305 storage scenarios with a constraint matrix

Write down the non-negotiable requirements: consistency, schema, query pattern, scale, recovery objective, residency, protocol, latency, and budget. Then compare candidates against those constraints. This prevents one attractive feature from dominating the decision and makes trade-offs visible.

Finally, keep the storage choice connected to the rest of the solution. Networking, identity, monitoring, and compute all affect the design. Candidates who already understand administration from Microsoft AZ-104 should consciously shift from “how do I configure it?” to “which architecture best satisfies the business requirement, and what operational consequences follow?”

Storage architecture also has to account for data temperature over time. The access profile of a dataset can change from hot operational traffic to occasional reference and finally to long-term retention. Designing lifecycle movement at the beginning avoids keeping years of inactive content on an expensive tier simply because the original application never revisited its storage policy. The architect should also check whether moving data changes retrieval latency or introduces charges that conflict with reporting or audit requirements.

Multi-region data design becomes more complicated when the application writes in more than one location. Replication topology, conflict handling, consistency, and user affinity need to be explicit. A database that offers global distribution does not remove the need to decide what happens when two regions update related records during a network partition. The exam may frame this as a business requirement for global responsiveness, but the architecture answer still depends on the acceptable consistency model.

Storage networking can create hidden operational dependencies. A private endpoint can improve isolation while also making DNS resolution and cross-network access more important. If administrators, integration services, backup tools, or deployment pipelines live in different networks, every legitimate client path must be tested. A design that secures production traffic but accidentally blocks recovery automation is incomplete.

Data ownership should influence account and resource boundaries. Separating workloads by environment or business owner can simplify access reviews, cost allocation, and lifecycle management. Over-consolidating unrelated datasets into one storage account or database may look efficient initially but can make policy, quota, and blast-radius decisions harder later. Conversely, extreme fragmentation can create management overhead and inconsistent standards.

Analytical workloads deserve attention to format and query behavior. Columnar formats, partitioning, and separation of raw and curated layers can reduce scan cost and improve performance. The architect should avoid treating an object store as automatically analytics-ready; organization of data matters just as much as the underlying durability. Poor partitioning can turn inexpensive storage into an expensive query platform.

Encryption design should distinguish platform-managed keys from customer-managed keys. Customer-managed keys can satisfy control or compliance requirements, but they add dependencies on key availability, permissions, rotation, and recovery. If the organization cannot operate the key lifecycle reliably, extra control can create extra outage risk. The architecture should therefore match key ownership to an explicit requirement rather than selecting the most restrictive option by default.

Finally, storage decisions should be validated with realistic workload tests. Benchmark representative object sizes, transaction rates, concurrency, failure recovery, and network paths. A paper design may satisfy every feature requirement while still missing a throughput bottleneck or an unexpectedly expensive access pattern. Evidence from testing turns a storage recommendation into an architecture the operations team can trust.

Storage selection must also account for access patterns and failure recovery. A VM boot volume has a different contract from a shared team file store or an archive of immutable objects. Decide whether clients need SMB-style shared file semantics, POSIX-like access, block operations, or object APIs; then evaluate redundancy, identity-based access, backup and restore, lifecycle management, and cost. Encryption does not remove the need to plan for accidental deletion or regional disruption.

A useful storage scenario technique is to separate the primary data path from secondary obligations. The primary path answers how the application reads and writes; secondary obligations include analytics, archive, legal hold, backup, and disaster recovery. One storage service may satisfy several of these, but forcing every requirement into one platform can create awkward access patterns. Architects can often improve both cost and clarity by using a transactional store for operational work and a separate analytical or archival layer fed through controlled pipelines.