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.

• ✓

  SQL (Core) API

  Why this is correct

  The SQL (Core) API is the correct answer for this smart city workload because it is Azure Cosmos DB's native document model, storing sensor JSON telemetry directly and providing an ANSI-SQL-like query syntax. This API supports efficient point reads via id and partition key, and it indexes all fields by default, so you can run fast range filters such as timestamp BETWEEN ... AND ... to retrieve a sensor's data over a specific time window. Given the team is already comfortable with SQL-like language, this is the most natural fit.

• ✗

  Table API

  Why it's wrong here

  The Table API is a key-value store that returns entities consisting of simple scalar properties, not JSON documents. It supports lookups primarily by PartitionKey and RowKey, and although it can perform OData-style filter expressions, it lacks SQL-like query syntax and cannot efficiently answer complex time-range queries across thousands of devices without careful key design. This makes it less suitable than the SQL API for time-series sensor analysis.

  When this WOULD be correct

  A question where the application only needs fast point reads by a single partition key (e.g., deviceId) with no requirement for range queries or SQL-like syntax, and the team prefers a simple key-value interface.

• ✗

  MongoDB API

  Why it's wrong here

  The MongoDB API in Azure Cosmos DB does work with JSON documents and provides rich query capabilities, including range operators on timestamps; however, its query syntax is native MongoDB, such as find({timestamp: {$gte: ...}}). Because the team explicitly prefers a SQL-like language, the Mongo API would force them to adapt to Mongo constructs instead of standard SQL. It is a good choice only if the application already uses the MongoDB SDK, but it is not the correct answer for this requirement.

  When this WOULD be correct

  A question where the application uses an existing MongoDB client library, requires document storage with flexible schema, and needs to support geospatial queries or aggregation pipelines that are native to MongoDB. The team prefers a NoSQL query language over SQL.

• ✗

  Cassandra API

  Why it's wrong here

  The Cassandra API is a wide-column store that uses CQL (Cassandra Query Language), which looks similar to SQL but has significant restrictions in practice. Range queries on a time column require the time component to be part of the clustering key, and every CQL query must first identify a partition key, making ad-hoc time-range queries across all sensors impractical. Additionally, CQL does not support joins, aggregation across partitions, or rich nested JSON documents, so it does not meet the stated need for SQL-like language and flexible time-series filtering.

  When this WOULD be correct

  A scenario where the application requires a distributed, highly available NoSQL database with a wide-column store, needs to handle massive write throughput, and the queries are primarily by partition key (e.g., deviceId) with eventual consistency, and the team prefers a CQL-like query language.

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