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

  SQL (Core) API is a native, schema-agnostic document API for Azure Cosmos DB that stores each player session JSON as a resource and lets you query it with standard SQL syntax, including SELECT, WHERE, and even JOINs across documents. It automatically indexes all JSON properties without requiring a predefined schema, making it ideal for the flexible, evolving session data described. Because the requirement is explicitly SQL query support over JSON documents, this API directly matches the scenario.

• ✗

  MongoDB API

  Why it's wrong here

  MongoDB API stores JSON-like documents and supports schema flexibility, but it uses MongoDB's query protocol and query language, such as db.collection.find() with operators like $gt or $lookup for joins; it does not expose native SQL syntax. Although you could store the same player session JSON, a user expecting to write SQL queries per the stated requirement would not be able to do so without significant translation or a separate connector. Therefore the SQL (Core) API is the only one of the three document-capable options that provides the exact SQL feature set needed.

  When this WOULD be correct

  A company stores player session data as JSON documents and needs to query by userId and startTime range using MongoDB-compatible syntax, and also requires the ability to use existing MongoDB drivers and tools without modification.

• ✗

  Table API

  Why it's wrong here

  Table API provides a key-value and wide-column store that uses a partitioned row key design optimized for simple point lookups and range scans, not for ad-hoc SQL querying of nested JSON structures. Its query language is limited to OData-style filters on tokenized property values, and it cannot natively parse or project nested JSON fields like session sessions or player attributes. Consequently, it fails to meet the need for SQL query capabilities over full JSON documents and would require an external processing layer.

  When this WOULD be correct

  A company needs to store structured data (e.g., user profiles) with a partition key and row key, and queries are limited to point lookups or range scans on those keys, with no need for JSON or SQL queries.

• ✗

  Gremlin (Graph) API

  Why it's wrong here

  Gremlin (Graph) API is designed for highly connected data modeled as vertices and edges, queryable only through Gremlin's graph traversal language, not SQL. To store player session JSON in this API, you would need to disassemble each document into arbitrary graph elements, losing the document's natural shape and making schema flexibility difficult. Since the session log is a set of self-contained JSON documents without complex relational traversal requirements, the graph model adds unnecessary complexity and fails the explicit SQL query requirement.

  When this WOULD be correct

  A social network application needs to model relationships between users (e.g., friends, followers) and perform graph traversals like 'find all friends of friends'. The Gremlin API would be the correct choice for such graph-based 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