You read an AZ-305 storage scenario, and two of the options both look reasonable. That happens when the data is JSON. Azure SQL Database and Azure Cosmos DB both store it, so the format alone does not decide. The access pattern does. Joins and multi-row transactions point to Azure SQL Database, or to Azure SQL Managed Instance when the scenario needs instance-level features. Flexible documents read close to users, with elastic scale or global distribution, point to Cosmos DB. Files, media, and archives point to Blob Storage. Simple metadata addressed by a key pair points to Table Storage.
Design data storage solutions is 20-25% of AZ-305, one of four domains, and the English exam version was updated April 17, 2026 (AZ-305 exam page). The study guide shows what those questions will ask, which is where the decision rule comes from.
What the exam actually measures in storage
The study guide, skills measured as of April 17, 2026, lists three skills under the data-storage domain (Microsoft AZ-305 study guide):
- Design data storage solutions for relational data. That covers recommending a solution for storing relational data, a database service tier and compute tier, database scalability, and data protection.
- Design data storage solutions for semi-structured and unstructured data. That covers recommending a solution for storing semi-structured data, one for storing unstructured data, a solution that balances features, performance, and cost, and a data solution for protection and durability.
- Design data integration. That covers recommending a solution for data integration and a solution for data analysis.
So each question asks you to recommend a solution that balances features, performance, and costs for a stated workload.
The pressure comes from mixed requirements:
- Relational data that must also be read at low latency from several regions.
- JSON that the scenario still wants joined, constrained, or reported on.
- "Structured" metadata whose real access pattern is a key lookup.
- A question that says "files" while the answer choices mix Blob Storage, Azure Files, and databases.
The method is the same for all four. Separate the data model from the service names, then follow the access pattern.
Which store fits which workload
Relational workloads: Azure SQL Database or Managed Instance
Both run the SQL Server engine. Microsoft's feature comparison says the two share a common code base with the latest stable version of SQL Server (features comparison). So the decision is which deployment the scenario's constraints force.
Choose Azure SQL Database for new cloud workloads. It is a fully managed PaaS engine that handles upgrading, patching, backups, and monitoring, with built-in high availability (Azure SQL Database overview). The cues are orders, invoices, inventory, billing, ledger updates, joins, constraints, and operational reporting.
Choose Managed Instance when the question names an instance-level feature. Three of them, all from the features comparison, decide these questions:
- SQL Server Agent jobs. Managed Instance has SQL Server Agent. Azure SQL Database does not; its substitute is Elastic jobs.
- Cross-database queries and cross-database transactions. Managed Instance supports them, within the instance. Azure SQL Database does not.
- CLR assemblies and server configuration settings. Managed Instance supports them. Azure SQL Database does not.
Migration questions follow the same rule. Microsoft positions Managed Instance for SQL Server workloads that need a fully managed service without managing virtual machines, moving on-premises applications with minimal application or database changes, with complete instance isolation and native virtual network support (Managed Instance migration overview). If the question names Agent, cross-database queries, or instance-level dependencies, the answer is Managed Instance. If it names none of them, Azure SQL Database is the default for new workloads.
Flexible documents and global scale: Cosmos DB
Choose Cosmos DB when the data is flexible JSON or key-value and the scenario wants at least one of these. Low-latency reads or writes near users in multiple regions. Elastic horizontal scale. Tunable consistency. Microsoft describes turnkey global distribution with multi-region writes at a 99.999% SLA and automatic failover, and the service ships with APIs for NoSQL, MongoDB, Cassandra, Gremlin, and Table (Cosmos DB overview).
The boundary that decides these questions is transaction scope. Cosmos DB supports ACID transactions with snapshot isolation for operations within the same logical partition key (transactional batch). A logical partition also defines the scope of database transactions (partitioning overview). If the scenario needs one transaction that spans order and inventory rows in different partitions, Cosmos DB is the wrong engine. That is what Azure SQL Database is for.
The other cue is schema evolution. Items that change shape as the application grows, with no fixed table structure, point to Cosmos DB. The failure mode is a bad partition key. Choosing the partition key is a decision that affects performance, and each logical partition can hold up to 20 GB (partitioning overview).
Files and media: Blob Storage
Choose Blob Storage when the workload is unstructured objects: images, PDFs, video, audio, logs, archives, export files. Microsoft lists serving images or documents directly to a browser, storing files for distributed access, and streaming video and audio as its design targets (Blob Storage overview).
If the app queries the contents row by row, joins them, or transacts on them, a database is required. That holds even when Blob Storage is cheaper.
Simple key-pair metadata: Table Storage
Choose Table Storage when the access pattern is a lookup by partition key and row key and nothing more. Device metadata, telemetry, address books, user data for web apps. It is a schemaless key/attribute store inside an Azure Storage account, and Microsoft notes it is typically lower cost than traditional SQL for similar volumes of data (Table Storage overview).
Know the limits the questions test. An entity is up to 1 MB and holds up to 252 properties. There are no joins, foreign keys, or stored procedures. Entities that share a partition key can be inserted and updated in atomic operations, and that is the only transaction support the documentation describes.
The comparison at a glance
| Store | Data model | Transaction scope | Scale story | Scenario cue | Verdict |
|---|---|---|---|---|---|
| Azure SQL Database | Relational rows | Multi-row ACID within a database | vCore or DTU tiers, elastic pools | Joins, constraints, reporting, new app | Default for relational workloads |
| SQL Managed Instance | Relational rows | Multi-row, cross-database within the instance | Instance-level vCore | SQL Server Agent, cross-database queries, minimal-change migration | When the question names an instance-level feature |
| Cosmos DB | Documents, key-value | One logical partition key | Global distribution, elastic scale-out | Global low latency, evolving schema, multi-region writes | When scale and distribution decide |
| Blob Storage | Unstructured objects | None; object lifecycle | Massive object storage | Files, media, archives, served to a browser | Objects only |
| Table Storage | Key/attribute entities | Atomic operations within a partition key | Web-scale NoSQL, 1 MB entities | Lookups by key pair, metadata | When key lookup is the whole query model |
Cases that change the answer
JSON data with two plausible answers
The format alone does not pick the engine, because Azure SQL Database is multi-model as well. The features comparison lists JSON data and OPENJSON among the capabilities both SQL engines share. The deciding constraints are the ones the study guide asks you to balance:
- If the scenario needs multi-row transactions, joins across entities, or reporting, choose the SQL engine. Cosmos DB's transactions stop at one partition key.
- If the scenario needs global low-latency access, elastic scale, or a schema that keeps changing, choose Cosmos DB.
If a question needs both multi-row SQL control and global document scale, split the data across the two stores and justify each half.
Azure SQL Database or Managed Instance
The split between the two SQL deployments comes down to instance-level features. If the question describes a new cloud application with joins and reporting and no instance-level dependency, the answer is Azure SQL Database. Managed Instance is the answer only when the question names features the features comparison gives it and not Azure SQL Database. SQL Server Agent, cross-database queries, and cross-database transactions are that list, along with the minimal-change migration of an existing estate.
Table Storage that outgrows its limits
Check the query model first. Table Storage answers a lookup by partition key and row key, even when the data is "structured". If the scenario adds global distribution, a secondary index, or a query that cannot be expressed as a key lookup, the answer moves to Cosmos DB for Table, which serves the Table API on the Cosmos DB platform.
Mixed workloads need more than one store
When a scenario names one application but the data has several access patterns, the answer is more than one store. The Azure Architecture Center guidance is that a single data store rarely satisfies all access patterns efficiently, and most production systems adopt polyglot persistence (understand data store models). Split the scenario by data shape before you pick anything.
A mixed scenario, decided
A logistics startup rebuilds its platform on Azure. Three workloads:
- Shipment status events, mostly key lookups by tracking number, with new sensor fields added each quarter and reads from customers in multiple regions.
- Driver photos and proof-of-delivery documents, served to a browser and archived after 90 days.
- A pricing engine that joins a rate table with shipment contracts to compute charges, with audit constraints on every update.
The decisions, from the access patterns:
- Shipment events are flexible documents read close to users, with a schema that keeps changing. Cosmos DB, partitioned by tracking number. Each tracking number stays inside one logical partition, which is also the transaction boundary.
- Photos and documents are objects served to a browser and archived later. Blob Storage.
- Pricing is relational. Joins across rate and contract rows, constraints on updates, audit queries. Azure SQL Database, because no instance-level feature is required.
For the answer, match each access pattern to its store and say why.
Start with the free assessment, then follow the Pass Plan
When you take the assessment, note which storage skills your gaps fall under: data model, access pattern, transaction scope, scale or distribution, migration compatibility, or cost. As you work through storage practice questions, CramHQ picks up the gaps that show in your answers: the JSON scenario where you chose the wrong store, the transaction scope you misread, the key lookup you routed through a database. It lines them up in order of the exam points each one costs, so the gap worth the most exam points sits first on your Pass Plan, your ranked list of repair tasks.
Microsoft updates its exams periodically, so recheck the study guide before you book. Take the free AZ-305 assessment. It requires no credit card. You get a Readiness Report, your top gaps, and a targeted repair preview. The full AZ-305 path is US$34.99 for 12 months of access, and your first repair is free.