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

  Why this is correct

  The Core (SQL) API stores each IoT sensor payload as a JSON document in a multi-item container and exposes a first-class SQL query engine over that JSON structure. It supports SELECT, WHERE, JOIN, and functions directly on embedded properties such as deviceId and timestamp without needing a separate translation layer. This makes it the optimal choice when the application requires SQL-like queries over JSON time-series data, with automatic indexing and configurable partition keys for scale.

• ✗

  Azure Cosmos DB MongoDB API

  Why it's wrong here

  Although the MongoDB API does store JSON-like BSON documents and can handle IoT payloads, it expects queries written in MongoDB's Query Language (MQL) using operators like $match and $group, not SQL syntax. Adopting it would introduce a compatibility layer based on the MongoDB wire protocol, adding unnecessary complexity when the requirement explicitly calls for SQL-like access. The application would also need MongoDB-specific drivers, so it does not satisfy the stated need as cleanly.

  When this WOULD be correct

  If the question stated that the team wants to use MongoDB tools and drivers, and the data is stored in a format compatible with MongoDB (e.g., BSON), then the MongoDB API would be the correct choice.

• ✗

  Azure Cosmos DB Cassandra API

  Why it's wrong here

  The Cassandra API presents a wide-column, partitioned-row data model and uses Cassandra Query Language (CQL) rather than a JSON document model. While it can store time-series data efficiently, it does not natively ingest or query JSON documents as atomic units, and CQL lacks the JSON manipulation features needed to query arbitrary device fields. This makes it unsuitable for the application's stated requirement of storing and querying JSON sensor documents.

  When this WOULD be correct

  A company needs to migrate an existing Cassandra workload to Azure Cosmos DB with minimal code changes, requiring compatibility with Cassandra drivers and CQL for time-series data with a fixed schema.

• ✗

  Azure Cosmos DB Gremlin API

  Why it's wrong here

  The Gremlin API models data as vertices, edges, and properties in a graph, which is useful for highly connected data such as social networks or recommendation engines. IoT sensor readings are naturally append-only time-series events, not relationships, and the query pattern is filtering by device ID and timestamp, not traversing graph paths. Gremlin traversal language would be a poor fit and would require awkward remapping of JSON sensor documents into a graph schema.

  When this WOULD be correct

  A social network application needs to model complex relationships between users, such as friends, followers, and likes, and requires queries like 'find all friends of friends who liked a post'. In this scenario, the Gremlin API would be correct because it supports graph traversal 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