AZ-305 Design data storage solutions Practice Question
A company needs to store sensor data from IoT devices. Each device sends a message every second. The data is time-series and will be queried for real-time dashboards and historical analysis. The solution must support high ingestion rates and low-latency queries on recent data. Which Azure service should they use?
⚠ Common exam trap
A common mix-up: candidates choose Azure Cosmos DB (Option B) because they associate it with 'low latency' and 'IoT', but they overlook that Cosmos DB is not purpose-built for time-series data and lacks the ingestion throughput and query optimizations that Azure Data Explorer provides for this specific workload.
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
✓
Azure Event Hubs and Azure Data Explorer
Azure Event Hubs is designed for high-throughput data ingestion from millions of IoT devices, capable of handling millions of events per second. Azure Data Explorer (ADX) is optimized for time-series data, providing sub-second query latency on recent data and efficient historical analysis. Together, they form a serverless pipeline that ingests sensor data via Event Hubs and stores it in ADX for real-time dashboards and long-term analytics.
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 Blob Storage with Azure Data Lake Storage Gen2
Why it's wrong here
Azure Blob Storage with Data Lake Storage Gen2 is optimized for massive, unstructured data lake workloads, not for low-latency, high-frequency time-series queries. While ADLS Gen2 adds a hierarchical namespace and POSIX permissions, it remains an object storage service that provides no native query surface. Real-time dashboards would require an additional query engine like Azure Synapse or Databricks on top, introducing considerable lag and complexity. For IoT sensor messages that need immediate analytical insights, object storage alone is a poor fit.
- ✗
Azure Cosmos DB with SQL API
Why it's wrong here
Azure Cosmos DB with the SQL API is a globally distributed, multi-model NoSQL database that excels at low-latency point reads and writes for transactional applications. However, it is not built for high-throughput time-series ingestion: each write consumes request units (RU/s), making it cost-prohibitive when millions of sensor messages arrive continuously. Analytical patterns like time-range aggregations and downsampling require expensive cross-partition queries that don't scale economically. Additionally, Cosmos DB lacks time-series-specific features such as automatic retention, data sampling, and efficient columnar compression for IoT telemetry.
- ✓
Azure Event Hubs and Azure Data Explorer
Why this is correct
Azure Event Hubs and Azure Data Explorer form the native Azure pattern for IoT sensor data because Event Hubs offers high-throughput, low-latency event streaming with partitioning and auto-inflate, easily handling millions of sensor messages per second. Azure Data Explorer (ADX) is a purpose-built analytics engine for time-series and log data, using columnar storage and an optimized ingestion pipeline that can directly consume streams from Event Hubs. ADX's KQL query language delivers real-time aggregations over large temporal windows in sub-second latency, making it ideal for live dashboards. This combination decouples ingestion from analytics while providing end-to-end scalability and low operational overhead.
- ✗
Azure Table Storage
Why it's wrong here
Azure Table Storage is a NoSQL key-value store that provides simple, fast lookups by partition key and row key, but it severely lacks analytical capability. There is no support for complex aggregations, time-range queries, or joins, making it impossible to serve real-time dashboards from sensor data without scanning all records. Query performance degrades sharply for anything beyond point lookups, and the service is not designed for time-series workloads that require retention policies or downsampling. While it is cheap for storing static structured data, it is fundamentally the wrong choice for interleaved ingest-and-analyze IoT streaming.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
This AZ-305 question is part of Courseiva's 204-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-305 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 AZ-305 exam.