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.

• ✗

  A. Azure Cosmos DB for MongoDB API

  Why it's wrong here

  While the MongoDB API also stores JSON-like BSON documents and supports rich queries, its query language is MongoDB-specific, such as db.posts.find({userId: id, timestamp: {$gt: time}}), not the ANSI-inspired SQL syntax the team prefers. The aggregation pipeline and MongoDB operators differ fundamentally from the SQL dialect used by the NoSQL API, so adopting it would not meet the stated preference. It is therefore a valid document store but a worse fit for this specific requirement.

  When this WOULD be correct

  If the development team needed to use MongoDB tools, drivers, and query syntax (e.g., db.posts.find({userId: '123'})), and the application already used MongoDB, then Azure Cosmos DB for MongoDB API would be the correct choice.

• ✓

  B. Azure Cosmos DB for NoSQL API (Core SQL API)

  Why this is correct

  Azure Cosmos DB NoSQL API stores documents natively as JSON, and its SQL-like query syntax (SELECT * FROM c WHERE c.userId = @id AND c.timestamp > @time) is directly optimized for these documents. The API auto-indexes every property, enabling efficient range scans on timestamp and equality filters on userId without manual index tuning. This makes it the most natural fit for a social media post store requiring flexible schemas and rich queries.

• ✗

  C. Azure Cosmos DB for Table API

  Why it's wrong here

  The Table API is a key-value store that treats each entity as a row with only primitive properties (string, binary, bool, etc.), so nested JSON fields like post metadata are not first-class citizens. Queries are limited to partition key and row key lookups, plus loosely filtered scans on a few indexed properties; they cannot perform range queries on a timestamp within a nested document. Consequently, it would force denormalization and lose the document querying capabilities this workload needs.

  When this WOULD be correct

  A question asking for an API to store and query large volumes of structured, non-relational data (e.g., sensor readings) with fast point lookups by partition key and row key, and where SQL-like queries are not required. The Table API would be correct for simple key-value access with O(1) latency.

• ✗

  D. Azure Cosmos DB for Apache Cassandra API

  Why it's wrong here

  The Cassandra API implements CQL (Cassandra Query Language), which resembles SQL but is built around partitioning and wide-column tables, not hierarchical JSON. Each JSON post would have to be flattened into multiple columns, and querying on userId and timestamp would require careful primary key design involving partition keys and clustering columns. This introduces significant schema complexity and likely sacrifices the ability to query arbitrary nested fields, making it inappropriate for flexible document posts.

  When this WOULD be correct

  An application requires a distributed, high-write-throughput database for time-series data with a schema that can be modeled as wide-column rows, and the team prefers using CQL for queries.

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