Courseiva

DP-900 Practice Question: Describe considerations for working with non-relational data on Azure

A social media application stores user sessions as JSON documents. Each session document has fields like sessionId, userId, startTime, endTime, and a list of pageviews. The application needs to quickly retrieve a session by its sessionId and also run queries like 'find all sessions for a user in the last 24 hours' using SQL-like syntax. The data has no fixed schema; different sessions may include additional optional fields like 'deviceType' or 'promotionCode'. Which Azure data store should the company use?

⚠ Common exam trap

Many candidates confuse Azure Table Storage's key-value simplicity with JSON document support, but Table Storage does not provide SQL-like querying or native JSON handling, making Cosmos DB the only option that combines flexible schema, SQL syntax, and fast point reads.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Azure Cosmos DB with SQL API

Azure Cosmos DB with SQL API is the correct choice because it natively supports storing JSON documents with flexible schemas, allows fast point reads by sessionId using a unique identifier, and enables SQL-like queries (e.g., filtering by userId and startTime) with automatic indexing. Its schema-agnostic design handles optional fields like deviceType or promotionCode without requiring schema changes, and it provides low-latency reads essential for real-time session retrieval.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Azure Cosmos DB with SQL API

    Why this is correct

    Azure Cosmos DB with SQL API natively stores JSON documents as its core data model, making it schema-agnostic so user sessions with varying fields can be ingested without any upfront schema design. It automatically indexes every JSON property by default, and its SQL-like query language can directly filter, project, and traverse nested objects—for example, WHERE sessionId = @id. Combined with single-digit-millisecond latency for point reads and horizontal partitioning, it is specifically engineered to serve flexible, queryable session data at global scale.

  • Azure Table Storage

    Why it's wrong here

    Azure Table Storage is a NoSQL key-value store that stores entities as flat collections of named properties, limited to simple scalar types with at most 255 properties per entity. It cannot natively represent nested JSON objects, so a session document containing structures like user profile or device metadata would need to be serialized into a flat string or split across multiple entities. Queries are restricted to partition key/row key lookups and simple equality/range filters on indexed properties, which means this service does not support SQL-like queries on nested document fields and is fundamentally mismatched for this use case.

    When this WOULD be correct

    A company needs to store large amounts of structured, non-relational data (e.g., device telemetry) with simple key-based lookups and no need for complex queries or indexing. The data has a fixed schema and queries are limited to partition key + row key patterns.

  • Azure SQL Database

    Why it's wrong here

    Azure SQL Database is a relational database engine that requires a predefined, fixed schema; to store JSON sessions you would have to place the entire document in an NVARCHAR column and then use OPENJSON or JSON_VALUE functions to parse it at query time. Because session payloads vary, you'd either add new columns for every possible property—which becomes an ALTER TABLE nightmare—or rely on runtime JSON parsing, both of which are inefficient and sacrifice the relational model's benefits. Unlike a document database, Azure SQL Database does not automatically index every JSON property, nor does it offer native document-style partitioning and low-latency point reads optimized for schema-agnostic data.

    When this WOULD be correct

    A company needs to store structured relational data with a fixed schema, such as customer orders with predefined columns, and requires complex joins, ACID transactions, and SQL queries. The data does not have varying fields, and schema changes are infrequent and managed through migrations.

  • Azure Blob Storage

    Why it's wrong here

    Azure Blob Storage is designed for storing massive amounts of unstructured binary data such as images, videos, log files, or backups, with a URL-based access model. While you could upload each session as a discrete JSON file blob, the service provides no query engine to search inside the JSON content—you'd need to download each blob and parse it client-side, which is slow and unscalable for per-session lookups. Because it lacks built-in indexing, SQL-like querying, and point-read semantics on document properties, Blob Storage is completely unsuitable for application-facing session retrieval and querying.

    When this WOULD be correct

    A company needs to store and serve large media files (e.g., images, videos) for a social media application, with no need for querying individual fields within the files. The primary requirement is cost-effective, scalable storage with high throughput for blob data.

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The DP-900 exam frequently reuses these exact scenarios with slightly different constraints.

Azure Cosmos DB with SQL APICorrect answer

Why this is correct

Azure Cosmos DB with SQL API natively stores JSON documents as its core data model, making it schema-agnostic so user sessions with varying fields can be ingested without any upfront schema design. It automatically indexes every JSON property by default, and its SQL-like query language can directly filter, project, and traverse nested objects—for example, WHERE sessionId = @id. Combined with single-digit-millisecond latency for point reads and horizontal partitioning, it is specifically engineered to serve flexible, queryable session data at global scale.

Azure Table StorageWrong answer — click to see why

Why this is wrong here

Azure Table Storage does not support SQL-like query syntax or JSON documents natively; it uses OData and requires a fixed schema for partition and row keys, making it unsuitable for schema-less JSON sessions and complex queries like 'find all sessions for a user in the last 24 hours'.

★ When this WOULD be the correct answer

A company needs to store large amounts of structured, non-relational data (e.g., device telemetry) with simple key-based lookups and no need for complex queries or indexing. The data has a fixed schema and queries are limited to partition key + row key patterns.

Why candidates choose this

Candidates may confuse Azure Table Storage with a NoSQL option that can handle JSON, but they overlook its lack of native JSON support, SQL querying, and flexible schema capabilities.

Azure SQL DatabaseWrong answer — click to see why

Why this is wrong here

Azure SQL Database enforces a fixed schema, but the question states that session documents have no fixed schema and may include additional optional fields. It also requires SQL-like queries on JSON documents, which Azure SQL Database supports, but the lack of schema flexibility makes it unsuitable for this use case.

★ When this WOULD be the correct answer

A company needs to store structured relational data with a fixed schema, such as customer orders with predefined columns, and requires complex joins, ACID transactions, and SQL queries. The data does not have varying fields, and schema changes are infrequent and managed through migrations.

Why candidates choose this

Candidates may think that because the question mentions SQL-like syntax and JSON support, Azure SQL Database is a good fit, overlooking the requirement for a flexible schema that can handle optional fields without schema changes.

Azure Blob StorageWrong answer — click to see why

Why this is wrong here

Azure Blob Storage is optimized for unstructured binary or text data, not for querying JSON documents with SQL-like syntax or indexing on fields like sessionId and userId. It lacks native support for complex queries and schema flexibility required for this use case.

★ When this WOULD be the correct answer

A company needs to store and serve large media files (e.g., images, videos) for a social media application, with no need for querying individual fields within the files. The primary requirement is cost-effective, scalable storage with high throughput for blob data.

Why candidates choose this

Candidates may think Blob Storage can handle JSON documents because it supports storing text files, and they might overlook the need for querying capabilities and indexing that are not available in Blob Storage.

Analysis generated from the official DP-900blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”

About these practice questions

Courseiva writes every DP-900 question from scratch — 820 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This DP-900 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DP-900 exam.