Streaming IoT Data into Fabric Lakehouse for NRT Dashboards
Short answer
B Azure Event Hubs streams IoT sensor telemetry into Fabric Real-Time Hub for NRT dashboards, KQL anomaly detection, and Delta storage in Lakehouse1.
Question
You need to collect IoT sensor data from connected devices in near-real-time (NRT). The solution must meet the following requirements:
• Generate NRT dashboards and perform anomaly detection.
• Store the streaming data for downstream batch processing into Lakehouse1.
The solution must minimize development effort.
What should you use?
Key Takeaways
The question tests choosing a native, low-code streaming ingestion path into Fabric, and the trap is picking a service that does anomaly detection but lives outside Fabric and adds deployment overhead, or defaulting to Dataflow Gen2.
This DP-700 scenario asks how to ingest IoT sensor telemetry in near-real-time, power NRT dashboards with anomaly detection, and land the data in Lakehouse1 for batch processing while minimizing development effort. The page establishes that Azure Event Hubs fed through Fabric's Real-Time Hub is the lowest-effort native path, while Dataflow Gen2 remains a batch-only tool.
Common mistake: Many learners choose Azure Stream Analytics (A) because it ships built-in anomaly detection functions, but ASA is a separate Azure service that must be provisioned, queried, and wired to outputs — increasing development effort instead of minimizing it; Dataflow Gen2 (D) is also wrongly reused even though it is a batch ingestion tool.
Expert Analysis
Why the Answer Is Correct
Azure Event Hubs (B) is the recommended ingestion front end for IoT telemetry because it is exposed as a first-class source in Fabric's Real-Time Hub, so an eventstream can be configured with drag-and-drop rather than custom code. From that eventstream you fan out to a KQL eventhouse, where near-real-time dashboards and functions such as series_decompose_anomalies deliver the required anomaly detection. A second eventstream destination writes the same stream into a Delta table in Lakehouse1, satisfying the downstream batch-processing requirement with zero-code destinations. Because everything is configured inside the existing Fabric workspace, this meets the "minimize development effort" constraint better than any option that requires deploying and maintaining an external service or writing code.
Official Reference
- https://learn.microsoft.com/en-us/fabric/real-time-hub/
- https://learn.microsoft.com/en-us/azure/stream-analytics/
These links open the official vendor documentation in a new tab.
Exam Strategy
When a question says "minimize development effort" in Fabric, favor a native, no-code/low-code workspace feature over deploying an external Azure service or writing Spark code. Always re-read the stated workload type — if the requirement is near-real-time, eliminate batch tools like Dataflow Gen2 before comparing the remaining options.
Frequently Asked Questions
Why isn't Azure Stream Analytics the answer if it has built-in anomaly detection?
Can Dataflow Gen2 handle the near-real-time IoT requirement?
Discussion 2 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 2
-
babi00 👍 2 Answered AaAZURE stream analytic have built in functions for anomaly detection and native connectors to deliver streaming data to downstreams , event hubs is a message broker it cannot perform anomaly detection or drive dashboards on its own without a downstream processing service (like ASA or Spark).
-
AZJunkie 👍 1 Answered B✅ B Ingest streaming IoT sensor telemetry with minimal configuration effort.Power near-real-time (NRT) dashboards and run KQL-based time-series functions (like series_decompose_anomalies()) for anomaly detection. Route the streaming data directly into Delta Lake tables in Lakehouse1 for downstream batch processing with zero-code destinations. ❌ A. Operates outside Microsoft Fabric as a standalone Azure service, adding management overhead and operational complexity. ❌C. Requires writing, maintaining, and managing custom PySpark/Scala code ❌D. It cannot process high-velocity, low-latency streaming IoT data for near-real-time dashboards.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.