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

  Azure Cosmos DB SQL (Core) API is the native document model that stores JSON documents exactly as provided, preserving nested structures and supporting flexible schema evolution. It exposes a SQL-like query language that allows filtering, projection, and joins on any field within the JSON, making it ideal for both point lookups by key and ad-hoc analytical queries. This API directly satisfies the stated requirements of fast key-based access and SQL-style querying over arbitrary fields.

• ✗

  MongoDB API

  Why it's wrong here

  The MongoDB API in Azure Cosmos DB does store JSON-like documents and provides a flexible schema, so it might appear relevant at first glance. However, it uses MongoDB's query syntax based on JSON operators like $match and $lookup, not T-SQL or standard SQL, and the requirement explicitly calls for SQL-like queries. This API is the right choice only if the company were migrating existing MongoDB workloads, but for a new implementation with a SQL requirement, the SQL (Core) API is the better fit.

  When this WOULD be correct

  If the question specified that the application requires MongoDB-compatible drivers, uses MongoDB-specific features like aggregation pipelines, or needs to migrate an existing MongoDB workload to Azure Cosmos DB, then the MongoDB API would be correct.

• ✗

  Cassandra API

  Why it's wrong here

  The Cassandra API implements the Apache Cassandra wide-column data model, where data is organized into tables with rows and columns but not as nested JSON documents. It uses CQL (Cassandra Query Language), which is similar to SQL but does not support full JSON document manipulation and offers limited query flexibility beyond primary-key and indexed columns. This API is designed for high-throughput writes and key-based reads, not for querying arbitrary JSON fields, making it unsuitable for this requirement.

  When this WOULD be correct

  A company needs a globally distributed, low-latency, high-throughput database for time-series data (e.g., IoT sensor readings) with a fixed schema, requiring strong consistency and the ability to query by partition key and clustering columns using CQL.

• ✗

  Table API

  Why it's wrong here

  The Table API in Azure Cosmos DB is a key-value store that requires a fixed, flat schema composed of property-value pairs, without support for nested JSON documents. Queries are limited to equality and range operations on the partition key and row key, and it does not provide a SQL-like query syntax for arbitrary field evaluation. Therefore, it cannot handle the flexible JSON profiles with nested content or the ad-hoc query needs described in the scenario.

  When this WOULD be correct

  A company needs to store structured, non-relational data (e.g., customer records with a fixed set of properties) and requires fast point lookups by partition key and row key, with no need for complex queries or nested JSON. The Table API would be correct for such a scenario.

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