Microsoft AZ-305: Data Storage Design

Microsoft AZ-305 treats storage as an architecture decision shaped by workload behavior. A strong design starts with data model, access pattern, consistency, latency, scale, durability, availability, security, governance, integration, and recovery requirements—not with a favorite Azure database or storage service.

The current Microsoft AZ-305 blueprint remains the April 17, 2026 English skills outline on October 6, 2026. This article isolates storage design so it complements the broader infrastructure, business-continuity, requirements-to-decisions, practical, and readiness pieces already in the cluster.

Describe data, growth, and consistency before choosing a service

Classify the workload as relational, document, key-value, graph, time-series, file, object, analytical, or mixed, then identify transaction and query behavior. Write expected data volume, growth, read/write ratio, query shape, concurrency, schema change frequency, and latency target for one representative workload.

Without that description, comparisons between storage services become feature lists rather than architecture.

Growth assumptions should be measurable. Expected volume, transaction rate, item size, query pattern, and tenant distribution determine whether a partition strategy will continue to work. Hot partitions and high-cardinality indexes can become the real limit long before nominal service capacity is exhausted.

Migration should be part of the decision record. If a storage assumption later fails, the architecture should have some idea of how data will be moved, dual-written, replicated, or transformed without an uncontrolled outage. The trigger for that migration—scale, cost, residency, or a new query pattern—should be known before the original choice becomes permanent by inertia.

Applications differ in how much temporary divergence they can tolerate and whether users must immediately read their own writes or coordinate across regions. For a global application, compare what happens if you prioritize stronger consistency versus lower latency and higher regional independence.

The correct tradeoff follows from business correctness requirements, not from a blanket preference for the strongest setting.

Consistency decisions should be tested with a concrete failure or concurrency case. Define what a user is allowed to observe immediately after a write, what can lag between regions, and which operations cannot tolerate divergence. That business rule makes it easier to choose a replication or database behavior without defaulting to the strongest consistency setting. It also clarifies which monitoring signals matter when replication falls behind or a regional dependency becomes unavailable.

Design scale around partitions and workload shape

Scaling depends on distribution keys, hot partitions, index strategy, connection behavior, compute/storage coupling, and whether scale is vertical, horizontal, or serverless. Take a workload with uneven tenant sizes and test whether your partitioning or sharding choice concentrates traffic on a small set of keys.

A scalable service can still perform badly when the logical data distribution fights the physical design.

Treat availability separately from backup

High availability reduces interruption from component or zone failures, while backup protects against deletion, corruption, or other states that redundancy can faithfully replicate. For one database, define acceptable downtime and data loss, then choose redundancy, replication, backup frequency, retention, and restore testing accordingly.

This separation prepares the storage decision for the broader AZ-305 business continuity and disaster recovery model.

Resilience choices should be tested against corruption as well as infrastructure failure. Synchronous replication can preserve availability while faithfully copying a bad write. Backups, point-in-time recovery, and tested restore procedures address different failure classes. A complete design states which mechanism protects against which event.

Design security around identities and data sensitivity

Authentication, managed identities, authorization, network access, encryption, key ownership, data classification, auditing, and separation of duties belong in storage design from the start. Map a sensitive dataset from application identity to data operation and show where authorization is enforced and how administrators are prevented from bypassing normal access casually.

The result should make both application access and privileged operational access auditable. The security design should state why the chosen identity, permission, and network model fits the workload and which assumption would trigger a redesign.

Security should be expressed from application identity to stored data. Document how the workload authenticates, which permission grants the required operations, whether private connectivity is needed, who owns encryption keys, and which logs reveal privileged access. A private endpoint without correct identity and authorization does not make the data secure by itself.

Account for network and private access

Data services can be reachable through public endpoints with controls, private endpoints, service endpoints, or other network patterns. The right choice depends on trust boundaries and connectivity requirements. Draw the data path from workload to service, including DNS, routing, firewall or access rules, hybrid dependencies, and monitoring. The network design is complete only when the access path, DNS behavior, and operational dependencies can be explained independently of a portal workflow.

Private connectivity is valuable only when name resolution and operational access are designed with it. The review should identify the owner, the evidence that confirms the private path works, and the operational tradeoff introduced by that design.

Storage design should also account for lifecycle and retention. Some data needs frequent access for a short period and cheap retention afterward; other data must remain immediately queryable for years. Tiering, archival, retention, deletion, and legal-hold requirements can change the cost and operational model even when the underlying data format does not change.

Network design can alter both security and supportability. Private endpoints reduce public exposure but introduce DNS, routing, and operational-access dependencies. If administrators or applications cannot resolve or reach the private endpoint consistently, a theoretically safer design can become harder to operate. The decision should include both the trust boundary and the support path.

Plan integration and movement

Storage rarely exists alone. Data may need ingestion, transformation, replication, analytics, event publication, export, archival, or integration with other services. Identify whether movement is batch, streaming, event-driven, transactional, or analytical, and make ownership of retries, ordering, duplication, and failure explicit. Integration choices should remain tied to the user, business, or security outcome the data movement is meant to support.

Storage decisions also affect how downstream systems consume change. Azure messaging and event-driven architecture is appropriate when applications need buffering, fan-out, asynchronous processing, or looser coupling around stored data. The design should state who owns retries, ordering, duplicate handling, and failure recovery rather than adding an event service by default.

Design observability for data behavior

For storage operations, Azure Monitor and Log Analytics observability should expose the behavior that matters to the storage decision: latency, throttling, capacity, availability, query failures, replication health, and user impact. Collecting every available metric is less useful than defining which signal would cause an operator to scale, tune, fail over, or investigate.

A useful storage dashboard explains whether the problem is demand, data distribution, query design, service capacity, or a dependency. The observability design should distinguish a merely possible storage option from the one that can be operated and diagnosed against the actual requirement.

Storage cost should be evaluated after the workload requirements are clear. Capacity, transactions, provisioned throughput, replicas, backup retention, data transfer, and operational labor can all dominate at different scales. A cheaper service that requires extensive manual operations or an early migration may cost more over the life of the workload than a more capable option chosen for clear reasons.

Write the storage decision as a tradeoff

Document the data characteristics, selected service or pattern, strongest alternative, rejected requirement, expected scaling behavior, security model, availability, backup/recovery, and review triggers. Relate the decision back to Microsoft Certified: Azure Solutions Architect Expert expectations: another architect should understand why the storage choice fits the business requirement and when it should be revisited.

The decision record is more valuable than a feature table because it preserves the requirement, tradeoff, and review trigger behind the storage choice.

One strong storage exercise is to take the same application through three growth stages. At first it is a regional transactional workload; later it becomes globally distributed; finally its data is reused for analytics and event-driven downstream processing. At each stage, decide which original storage assumptions still hold and which should be revisited. This teaches architectural evolution instead of encouraging a one-time service choice that is never questioned again.

Keep cost visible but subordinate to workload correctness. Storage cost can come from capacity, transactions, provisioned throughput, replicas, backup retention, network movement, and operational labor. Compare cost only after the service meets the consistency, security, scale, and recovery needs. Otherwise a cheaper design can simply shift expense into outages, manual operations, or a later migration.

Before closing the storage decision, state how the design will be migrated if one of its assumptions fails. A growth threshold, new residency rule, changed consistency need, or new analytical workload may force a different service or topology. Knowing the trigger and migration boundary in advance keeps the original choice from becoming permanent by inertia.

Data residency can change the storage design even when the access pattern stays the same. If data must remain in a specific geography, replication choices, backup location, analytics movement, and operational access may all be constrained. Make the residency rule explicit so global replication is not selected merely because it improves availability. State the migration trigger explicitly.