Courseiva

DP-900 Practice Question: Describe considerations for working with non-relational data on Azure

A company develops an IoT device registry that stores device metadata as JSON documents. Each device has a unique DeviceID, and the attributes vary per device type (e.g., sensors, actuators). The application requires low-latency reads by DeviceID and needs global distribution to support devices worldwide. The team wants to use a fully managed NoSQL database in Azure. Which API should they choose for Azure Cosmos DB?

⚠ Common exam trap

Test-takers frequently choose the MongoDB API because they associate JSON documents with MongoDB, but the SQL API is the native Cosmos DB API that provides the best performance and feature integration for JSON workloads on Azure.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

SQL API

The SQL API (formerly DocumentDB API) is the native API for Azure Cosmos DB, providing full support for querying JSON documents with a SQL-like syntax. It offers the lowest latency reads by ID (point reads) and native global distribution, making it ideal for a device registry where each device has a unique DeviceID and variable attributes. The SQL API also supports indexing all properties automatically, which is critical for the varied device types.

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 API

    Why this is correct

    The Core (SQL) API is Cosmos DB's native API, storing documents as JSON and integrating directly with the underlying index and partitioning engine. It supports rich SQL-based querying, including nested attributes and server-side JavaScript, making it ideal for a device registry with variable schema. Point reads by device ID leverage the partition key and a physical index, providing the lowest and most predictable latency. Being the native API, it also enjoys first-class support for global distribution, consistency levels, and throughput management.

  • MongoDB API

    Why it's wrong here

    The MongoDB API is tempting due to its compatibility with existing MongoDB applications and developer familiarity, enabling migration without significant code changes or the need to learn a new API. However, for new applications specifically requiring the absolute lowest-latency reads by a unique ID, the Core (SQL) API is generally more performant. The MongoDB API functions as an emulation layer, whereas Core (SQL) is Cosmos DB's native API, offering direct access to its optimised indexing and partitioning mechanisms for such specific access patterns.

  • Cassandra API

    Why it's wrong here

    The Cassandra API presents a wide-column data model where each row is identified by a partition key and you typically define columns ahead of time; it is designed for high-throughput writes and time-series data, not for storing richly nested JSON documents. While JSON text can be placed in a column, you lose native querying of nested attributes and server-side document operations. In an IoT device registry where each device may have different metadata, the fixed-column model introduces rigidity and extra mapping overhead. This API is really meant as a wire-compatible migration path for existing Cassandra workloads, not as a native JSON store.

  • Table API

    Why it's wrong here

    The Table API is a schemaless key-value and wide-entity store where each item is a set of typed property/value pairs, comparable to Azure Table Storage but backed by Cosmos DB. It lacks support for nested JSON objects or arrays, so a device registry with rich, hierarchical metadata would need to be flattened and split across multiple entities. Queries are primarily by partition key and row key, offering very limited secondary indexing and no sophisticated document queries. This fits simple key-value lookups, not the flexible JSON documents required for a device registry.

About these practice questions

One of 820 original DP-900 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This DP-900 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DP-900 exam.