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 SQL Database

  Why it's wrong here

  Azure SQL Database enforces a fixed relational schema, which cannot accommodate the variable set of measurements per device type without costly schema redesign or nullable columns, and its single-region architecture does not natively support the globally distributed, low-latency writes required by thousands of IoT devices. It is tempting because it offers strong consistency and familiar SQL queries, making it the correct choice for transactional workloads with a stable schema, such as an order-processing system that demands ACID guarantees.

• ✓

  Azure Cosmos DB with the NoSQL API

  Why this is correct

  Azure Cosmos DB with the NoSQL API is the right fit because it stores JSON documents natively, allowing each sensor record to have a flexible set of attributes without schema migrations. Its multi-region writes and configurable consistency levels (e.g., session or eventual) provide sub-10-ms latencies at scale, which is essential for thousands of concurrent IoT devices writing variable telemetry. The global distribution also ensures data is available close to each factory or region, and the change feed can stream to downstream analytics, making it a purpose-built choice for high-velocity, schema-less sensor data.

• ✗

  Azure Cache for Redis

  Why it's wrong here

  Azure Cache for Redis is fundamentally an in-memory key-value cache, not a durable database. While it offers extremely low latency (microseconds), it keeps data in RAM by default, so it cannot reliably store the full history of sensor data without data loss on restarts or evictions unless you enable Redis on disk or AOF persistence, which is not designed for large-scale durability. It also lacks native global distribution for writes across multiple regions, and its data modeling (keys, hashes, or streams) does not handle flexible JSON documents as naturally as a document database. Its appropriate role here would be as a hot-cache layer in front of Cosmos DB, not as the primary store.

• ✗

  Azure Database for PostgreSQL

  Why it's wrong here

  Azure Database for PostgreSQL is a relational database that enforces a fixed schema, typically requiring a predefined table for measurements. To handle variable sensor measurements you would have to use a JSONB column, write sparse columns for every possible metric, or split into many tables with joins — all of which add complexity and hurt write performance. It also lacks native multi-master global distribution, so the single-region deployment cannot provide low-latency writes for devices spread across the globe, and a failover to another region would involve downtime or complicated replication. While it is excellent for transactional, relational data with strong consistency, it is not optimized for the high-ingest-rate, schema-flexible, globally distributed requirements of IoT telemetry.

Go deeper

Related to this question