AZ-305 Data Storage Decision Guide: Azure SQL, Cosmos DB, Blob Storage, or Table Storage?

If an AZ-305 scenario asks you to choose a data store, do not start with the product name. Start with the data shape and access pattern. Use Azure SQL Database when the workload needs relational constraints, transactions, joins, and a managed SQL engine. Use Azure SQL Managed Instance when the key requirement is SQL Server compatibility with minimal app or database change. Use Azure Cosmos DB when the data is flexible JSON or key-value/document data and the design needs horizontal scale, global distribution, or tunable consistency. Use Azure Blob Storage for large unstructured objects such as documents, images, media, logs, and archives. Use Azure Table Storage for simple structured NoSQL entities that can be accessed efficiently by partition and row keys.

That decision boundary matters because Microsoft currently lists "Design data storage solutions" as 20-25% of AZ-305, and the English exam page says it was updated on April 17, 2026 (Microsoft AZ-305 exam page).

What AZ-305 is really testing

The exam is not asking whether you can recite every Azure database SKU. The public study guide says this skill group includes relational storage, data integration, recommendations for relational, semi-structured, and non-relational storage, plus balancing features, performance, and cost (AZ-305 study guide PDF).

Microsoft's AZ-305 data-storage learning path groups the area into non-relational storage, relational storage, and data integration (Microsoft Learn AZ-305 data storage path). That is a useful study map, but the exam pressure usually comes from mixed requirements:

• The data looks relational, but the application needs global low-latency reads.
• The workload is JSON, but the question includes reporting or transaction requirements.
• The object is "structured", but the real access pattern is simple key lookup.
• The scenario says "files", but the answer choices mix Blob Storage, Azure Files, databases, and disks.

Your job is to separate the storage model from the distracting service names.

The six-question storage filter

Use this filter before choosing a service:

1. What is the primary data model: relational rows, JSON documents, key-value entities, files/objects, or analytics facts?
2. What is the dominant access pattern: point lookup, joins, transactions, range queries, full object retrieval, streaming, or historical aggregation?
3. Does the workload need strong relational integrity, stored procedures, or SQL Server compatibility?
4. Does the workload need global distribution, low-latency local reads/writes, elastic horizontal scale, or consistency tuning?
5. Is the data lifecycle object-like: upload, serve, tier, archive, retain, or analyze later?
6. Which option meets the requirements with the least operational complexity and cost?

This aligns with Azure Architecture Center guidance: start from access patterns, map them to storage models, then evaluate consistency, latency, scale, governance, and cost (Azure Architecture Center: understand data models).

Decision cards: which Azure data store should you reach for?

Use these cards as a quick first pass, then validate against the full scenario requirements.

Azure SQL Database

Use when the scenario centers on orders, invoices, inventory, billing, ledger-like updates, joins, or multi-row transactions.

Why it fits: Azure SQL Database is a fully managed PaaS SQL engine with built-in high availability, backups, and scaling models (Azure SQL Database overview).

Watch out for: Do not choose Cosmos DB just because the app is modern if the requirements depend on relational joins and transactional integrity.

Azure SQL Managed Instance

Use when the scenario emphasizes an existing SQL Server app with instance-level features, minimal code change, or native VNet integration.

Why it fits: Microsoft positions SQL Managed Instance for SQL Server workloads that need a fully managed service without managing VMs, often with minimal app or database changes (SQL Managed Instance migration overview).

Watch out for: Do not choose Azure SQL Database if instance compatibility is the real requirement.

Azure Cosmos DB

Use when the workload has flexible JSON documents, evolving schema, global distribution, low-latency access near users, or tunable consistency.

Why it fits: Cosmos DB is designed for flexible JSON data, elastic horizontal scale, global availability, indexing, and consistency choices (Cosmos DB overview).

Watch out for: Bad partition-key design can turn a correct service choice into a poor architecture.

Azure Table Storage or Cosmos DB for Table

Use when the requirement is simple structured NoSQL data where partition key plus row key access is enough.

Why it fits: Table Storage is a schemaless key/attribute store for structured non-relational data and can be cost-effective for flexible datasets (Azure Table Storage overview).

Watch out for: Do not use it for complex joins, foreign keys, or rich query patterns.

Azure Blob Storage

Use when the scenario is about images, PDFs, videos, logs, static documents, export files, or archives.

Why it fits: Blob Storage is object storage optimized for massive amounts of unstructured data (Azure Blob Storage overview).

Watch out for: Do not use a database as a file cabinet unless metadata or query requirements justify it.

Polyglot persistence

Use when one workload combines transactions, profiles, media, analytics exports, or other materially different data shapes.

Why it fits: Azure Architecture Center notes that a single data store rarely satisfies all access patterns efficiently (Azure Architecture Center: understand data models).

Watch out for: Do not force every data type into one service just because the question mentions one application.

Worked example: design storage for a global retail app

Scenario:

A retailer is rebuilding its customer app on Azure. Requirements:

• Store orders, refunds, and inventory reservations with transactional consistency.
• Store customer preferences and shopping-session context that vary by region and change schema often.
• Serve product images and return labels to users.
• Store device heartbeat metadata from stores, queried mostly by StoreId and DeviceId.
• Keep architecture manageable for a team that already runs SQL Server workloads.

Step 1: Identify the data models.

• Orders and inventory reservations are relational OLTP data.
• Customer preferences and session context are semi-structured JSON-like documents.
• Product images and labels are unstructured objects.
• Device heartbeat metadata is structured NoSQL key lookup data.

Step 2: Match each model to the access pattern.

• Orders need transactions, constraints, and operational reporting. Use Azure SQL Database unless the scenario emphasizes SQL Server instance compatibility.
• If the retailer is migrating an existing SQL Server estate with instance-level dependencies, use Azure SQL Managed Instance instead.
• Preferences and session context need flexible schema and low-latency access near users. Use Azure Cosmos DB, then design the partition key around the query and write pattern, such as tenant, customer, or region plus customer depending on the workload.
• Product images and labels are objects. Use Azure Blob Storage.
• Device heartbeat metadata can fit Azure Table Storage if partition and row key access satisfies the requirement. If the scenario adds global distribution, secondary indexes, higher availability, or richer query needs, evaluate Azure Cosmos DB for Table.

Step 3: Reject attractive but wrong simplifications.

• "Use Cosmos DB for everything" is too broad. It ignores relational order integrity and reporting needs.
• "Use Azure SQL for everything" is too broad. It turns objects and flexible documents into database baggage.
• "Use Blob Storage for all cheap storage" is too broad. Blob Storage is excellent for objects, not transactional order processing.
• "Use Table Storage because the data is structured" is incomplete. Table Storage is a key/attribute NoSQL store, not a relational database.

Step 4: Produce the exam-ready answer.

Use Azure SQL Database or SQL Managed Instance for orders and inventory, Azure Cosmos DB for flexible globally accessed customer state, Azure Blob Storage for product images and labels, and Azure Table Storage or Cosmos DB for Table for simple device metadata depending on scale and query requirements.

That answer is stronger than a memorized service list because it explains the tradeoff behind each selection.

Diagnostic walkthrough: what your wrong answer reveals

When you miss AZ-305 storage questions, the mistake usually falls into one of these patterns:

Wrong turn: you choose Cosmos DB whenever you see JSON

What it means: You are over-weighting data format and under-weighting access pattern.

How to remediate: Practice separating "can store JSON" from "should be the system of record."

Wrong turn: you choose SQL whenever the data is structured

What it means: You are treating "structured" as "relational."

How to remediate: Review key-value and document models, then map queries to partition keys.

Wrong turn: you choose Blob Storage because it is cheapest

What it means: You are optimizing cost before function.

How to remediate: Ask whether the app needs transactions, indexed queries, or object retrieval.

Wrong turn: you choose SQL Managed Instance for every SQL workload

What it means: You are over-weighting compatibility.

How to remediate: Use Managed Instance when instance-level compatibility or minimal migration change is required; use Azure SQL Database for cloud-native managed database needs.

Wrong turn: you choose one store for every part of a mixed app

What it means: You are missing polyglot persistence.

How to remediate: Split the scenario by data lifecycle and access pattern before selecting services.

This is where a diagnostic approach beats passive reading. A wrong answer is not just "missed storage." It tells you which decision lens failed: data model, query pattern, consistency, scale, migration compatibility, or cost.

How to study this without memorizing every SKU

Use Microsoft Learn for the official scope, but turn each module into decision drills:

• For relational data, compare Azure SQL Database, SQL Managed Instance, and SQL Server on Azure VMs.
• For non-relational data, compare Cosmos DB, Table Storage, Blob Storage, and Data Lake Storage Gen2.
• For mixed scenarios, write down why one service is not enough.
• For each missed practice question, label the failed lens: model, access pattern, migration, scale, consistency, or lifecycle.

After you can explain those labels, the product names become easier.

Where CramHQ fits

CramHQ is not a Microsoft product and does not guarantee a pass. For this storage topic, its diagnostic workflow can help identify whether your misses come from the wrong data model, the wrong access pattern, or the wrong tradeoff. From there, CramHQ can guide targeted practice, remediation, and readiness work across the broader AZ-305 learning path.

When you are ready, take the AZ-305 diagnostic at /quiz/assessment. Use the results to build a short remediation loop: fix one decision boundary, answer a few related questions, then check whether the same mistake disappears.

Quick recap

• Use Azure SQL Database for managed relational OLTP when cloud-native SQL fits.
• Use Azure SQL Managed Instance when SQL Server compatibility and migration constraints dominate.
• Use Cosmos DB for flexible document/key-value workloads that need horizontal scale, global distribution, low latency, or consistency tuning.
• Use Blob Storage for unstructured objects and file-like lifecycle requirements.
• Use Table Storage for simple structured NoSQL key/attribute access when it satisfies the query model.
• For AZ-305, explain the decision boundary. The "why" is usually what separates a good architecture answer from a service-name guess.