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 with MongoDB API

  Why it's wrong here

  Azure Cosmos DB with MongoDB API stores data as BSON documents and supports MongoDB's aggregation pipeline for complex transformations. It is designed for document-oriented workloads, not graph relationships, and it has no native support for graph concepts such as vertices, edges, or traversal operations. To compute 'friends of friends', an application would need to issue repeated queries for each hop and manually assemble the results, which is inefficient and error-prone compared to Gremlin API's single traversal query.

  When this WOULD be correct

  A question requiring a document database with flexible schema, high availability, and MongoDB compatibility (e.g., storing user profiles with complex nested data) would make Azure Cosmos DB with MongoDB API the correct answer.

• ✓

  Azure Cosmos DB with Gremlin API

  Why this is correct

  Azure Cosmos DB with Gremlin API is the correct choice because it provides a native graph database engine built on the property graph model. Data is stored as vertices (nodes) and edges (relationships), and queries are expressed in Gremlin, a declarative graph traversal language. This allows the database to perform efficient, index-backed traversals like finding friends-of-friends in a single operation, without expensive recursive joins or multiple round trips, which is exactly what a social networking graph requires.

• ✗

  Azure Table Storage

  Why it's wrong here

  Azure Table Storage is a schemaless key-value/wide-column store that organizes data into partitioned entities accessed by partition key and row key. It has no concept of relationships or edges between entities, so modeling 'friends of friends' would force an application to perform multiple manual lookups and then join the results in client-side code. Because it lacks built-in graph traversal or indexing on arbitrary relationship attributes, it is impractical for real-time relationship queries and would degrade quickly as the social graph grows.

  When this WOULD be correct

  A question requiring a cost-effective, schema-less NoSQL store for storing large amounts of structured, non-relational data (e.g., device logs, metadata) with simple key-based lookups and no complex querying needs would make Azure Table Storage correct.

• ✗

  Azure Cosmos DB with SQL API

  Why it's wrong here

  Azure Cosmos DB with SQL API stores documents as JSON and supports SQL-like queries with joins, subqueries, and user-defined functions. While it can represent relationships by embedding or storing entity IDs as fields, it does so by executing on-the-fly joins or multiple queries for each hop in a graph path. Unlike a dedicated graph API, there are no native edge indexes or traversal operators, so multi-level traversals like 'friends of friends of friends' become exponentially slower and require increasingly complex queries, making it suboptimal for this use case.

  When this WOULD be correct

  A question requiring storing and querying JSON documents with SQL-like queries, such as an e-commerce product catalog where items are retrieved by category or price range, and no graph relationships need to be traversed.

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