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

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 for NoSQL (SQL API)

  Why this is correct

  The SQL API is the native JSON document API for Azure Cosmos DB. It stores each user profile as a self-contained JSON document and automatically indexes every property without requiring a predefined schema. Developers can query these documents using a familiar SQL-like syntax (SELECT, WHERE, JOIN, GROUP BY) over any field, including nested properties like followersCount, and perform point reads using the partition key and document ID for optimal latency.

• ✗

  Azure Cosmos DB for MongoDB

  Why it's wrong here

  While MongoDB is designed for document storage using the BSON format, it uses a proprietary query language instead of the SQL syntax requested by the development team. This API would be the correct choice if the application required seamless migration from existing MongoDB clusters or specific aggregation frameworks used in those environments. It lacks the native SQL-based querying mechanism required to satisfy this specific developer preference.

• ✗

  Azure Cosmos DB for Table

  Why it's wrong here

  The Table API is a schema-less key-value store designed for tabular data, not hierarchical JSON. It supports queries only on the PartitionKey and RowKey fields; querying or filtering on a property like followersCount would require a table scan and is not supported as a first-class indexed predicate. JSON documents would need to be flattened into key-value pairs, losing the ability to run rich, schema-agnostic SQL queries over the original document structure.

  When this WOULD be correct

  A question where an application stores structured, non-relational data (e.g., sensor readings or user preferences) in a table format, requires fast point reads by a partition key, and uses OData-like queries instead of SQL. The team prefers a simple key-value API with table storage semantics.

• ✗

  Azure Cosmos DB for Apache Cassandra

  Why it's wrong here

  Apache Cassandra's API in Cosmos DB exposes a wide-column model governed by CQL, a query language tailored around partition keys and clustering columns, not SQL. While it can store JSON as a text blob, it lacks the native index on every subproperty that the SQL API provides, so filtering on followersCount would force a full scan or require careful denormalization and materialized views. The development team would have to redesign their schema and query logic from JSON documents to CQL table structures, defeating the purpose of using a JSON-native store.

  When this WOULD be correct

  A question where the application requires high-throughput writes and reads with a schema that is columnar (e.g., time-series data), and the team is familiar with Cassandra's CQL. For example: 'A telemetry system stores device readings with columns like deviceId, timestamp, and value. The team knows CQL and needs a globally distributed, low-latency database.'

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.

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?”

Go deeper

Related to this question