Which Fabric store supports T-SQL, KQL, and Spark reads with Spark writes?
Short answer
B Use an eventhouse, whose KQL database supports semi-structured data with KQL, T-SQL, and Spark reads and Spark writes.
Question
You have semi-structured data.
You need to read the data by using T-SQL, KQL, and Apache Spark. The data will only be written by using Spark.
What should you use to store the data?
Key Takeaways
The exam tests choosing a Fabric data store by its supported read and write engines; the trap is assuming a lakehouse natively serves KQL instead of requiring an Eventhouse shortcut.
Semi-structured Fabric data that must be read through T-SQL, KQL, and Apache Spark while being written only by Spark points to an eventhouse rather than a lakehouse, warehouse, or datamart. The page explains why the Eventhouse KQL database satisfies all three read paths and Spark-based ingestion.
Common mistake: Many candidates choose a lakehouse because it handles semi-structured data and Spark writes, but a lakehouse lacks native KQL querying; KQL access requires an eventhouse KQL database and a OneLake shortcut.
Expert Analysis
Why the Answer Is Correct
An eventhouse in Microsoft Fabric stores data in KQL databases built for semi-structured and structured data, and it exposes the exact read surfaces named in the stem: native KQL, a T-SQL endpoint, and Spark access. It also accepts Spark-based writes through the Kusto Spark connector, so the "written only by Spark" constraint does not eliminate it. That combination makes the eventhouse the only listed store that satisfies all three required read engines without adding a separate service just to translate the query language. The comment that summarized Eventhouse as "Read operations: KQL, Spark and T-SQL" captures the same capability the exam is testing.
Why the Other Options Are Wrong
A lakehouse is the strongest distractor because it stores semi-structured files, accepts Spark writes, and offers T-SQL through the SQL analytics endpoint. However, KQL is not a native lakehouse query surface; reaching lakehouse data with KQL requires an eventhouse KQL database and a shortcut, which adds a second store/query layer rather than making the lakehouse itself the required store. A warehouse is optimized for structured, T-SQL-centric workloads and does not provide KQL querying or Spark-based writes as the primary write path. A datamart is a Power BI self-service semantic layer backed by T-SQL, not a semi-structured Spark/KQL store.
Community Comment Notes
Several learners chose A and argued, as juamd did, that "you can query your data in a lakehouse without moving it"; that is true operationally but it describes adding an eventhouse layer, not a lakehouse-only solution. shmmini similarly saw both A and B as plausible and asked for more precision, which is exactly the ambiguity created by shortcuts. The comments supporting B focus on the decision-guide matrix, with one noting "KQL is avaialble in eventhouse only" and another listing Eventhouse read operations as KQL, Spark, and T-SQL. On an exam, the store whose native capabilities match every stated read/write requirement is the safer answer.
Official Reference
- https://learn.microsoft.com/en-us/fabric/fundamentals/decision-guide-data-store
- https://learn.microsoft.com/en-us/fabric/get-started/decision-guide-data-store
These links open the official vendor documentation in a new tab.
Exam Strategy
Map each requirement to the native engine support listed in Fabric's data-store decision guide. If KQL is a required read path and T-SQL and Spark are also required, eliminate lakehouse, warehouse, and datamart unless the question explicitly allows shortcuts; choose eventhouse.
Frequently Asked Questions
Why isn't a lakehouse the answer if it supports Spark and T-SQL?
Can Spark write data into a Fabric eventhouse?
Discussion 86 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 30 of 86
-
fffsssggg 👍 13 Answered BEventhouse: Read operations: KQL, Spark and T-SQL Write operations: KQL, Spark https://learn.microsoft.com/en-us/fabric/get-started/decision-guide-data-store
-
shmmini 👍 10I think both A and B could be a correct answer for this. If my data is in an eventhouse, I can query it using T-SQL, KQL and PySpark If my data is in a Laekehouse, I can query it using SQL and PySpark and Create shortcuts for it in the eventhouse then query it using KQL. I guess this question needs some other precision to only one possible correct answer
-
chimuelo69 👍 4 Answered AA lakehouse in Microsoft Fabric is a versatile storage option designed for semi-structured and unstructured data, combining the flexibility of a data lake with the structure of a data warehouse. It supports Apache Spark, T-SQL, and KQL queries, making it ideal for the requirements. Why the other options are not suitable: B. Eventhouse: Eventhouse is not a valid Microsoft Fabric storage option. C. Datamart: A datamart is designed for structured data and primarily supports T-SQL, but not Spark or KQL. D. Warehouse: A warehouse is optimized for structured data and supports T-SQL, but it is not designed for semi-structured data or Spark. A lakehouse is the best choice for storing data in a format that allows Spark to write it while enabling T-SQL and KQL for querying.
-
568f95c 👍 3 Answered AA Lakehouse in Microsoft Fabric is the best choice for storing semi-structured data while allowing access using T-SQL, KQL, and Apache Spark B. Eventhouse - Designed for real-time event processing. - Does not support T-SQL or Apache Spark writes. C. Datamart - Built for self-service BI, supports T-SQL, but not Spark-based writing. - Not optimized for semi-structured data. D. Warehouse - Optimized for structured relational data (fact & dimension tables). - Does not support KQL or Spark-based writes.
-
MohanNaidu08 👍 3 Answered AYou need a storage solution that supports: Semi-structured data Read access via T-SQL, KQL, and Apache Spark Write access via Spark A lakehouse in Microsoft Fabric is designed exactly for this: Supports semi-structured and structured data (e.g., JSON, Parquet, CSV). Can be queried using: T-SQL (via SQL analytics endpoint) KQL (via Kusto query endpoint) Apache Spark (via notebooks or jobs) Optimized for big data processing and analytics. Allows Spark-based writes and multi-engine reads.
Show 25 more comments
-
juamd 👍 3 Answered AThe only restriction to the lakehouses while reading the question is about the need to use KQL, but with the use of shortcuts in a KQL database, you can query your data in a lakehouse without moving it. Just create the shortcut and point it to the data.
-
GLG 👍 3 Answered ALakehouse: data will only be written bij using Spark. You can use shortcuts to access the data from een Eventhouse for KQL queries. If real-time processing or KQL were requitements, Eventhouse would be more appropiate.
-
mmanrik 👍 3 Answered BThe eventhouse is the only one out of the four options that allows the creation of a KQL Database, therefore it is the only option that fully meets the criteria (being able to read the date via KQL, T-SQL and Spark).
-
Tuki93 👍 3 Answered AYou have semi-structured data. The data will only be written by using Spark.
-
QAZdbarhate12345678 👍 3 Answered Alakehouse is the most appropriate choice for this scenario
-
akmorsh 👍 2 Answered AExplanation by chatGPT: A Lakehouse in Microsoft Fabric is designed to store semi-structured data and supports multiple query languages including T-SQL, KQL, and Apache Spark. The question specifies that the data will be written only by Spark, and needs to be read by T-SQL, KQL, and Spark, which fits perfectly with the Lakehouse architecture. Eventhouse is designed mainly for event streaming and ingestion. Datamart is typically used for relational, structured data with a semantic model and T-SQL querying but does not natively support Spark or KQL. Warehouse is optimized for structured, relational data and T-SQL querying but does not support KQL or Spark.
-
VenkataPhaniPavanKumar 👍 2 Answered AHere’s why a lakehouse fits perfectly for your scenario: It supports semi-structured data, such as JSON or Parquet. It can be accessed using T-SQL, KQL, and Apache Spark—offering maximum flexibility across personas. You mentioned data is only written using Spark, and lakehouses are optimized for Spark-based ingestion and processing. It stores data in Delta Lake format in OneLake, making it ACID-compliant and performant across engines. Source: Perplexity.ai and Microsoft Copilot (both says Lakehouse) Quite surprised to understand the gap from microsoft learn and copilot https://learn.microsoft.com/en-us/fabric/fundamentals/decision-guide-data-store
-
Manish0427 👍 2 Answered AAlthough data is only in Unstructured format and only Apache Spark is used to write, which is fulfilled by both a Lakehouse and Eventhouse. However, provided that there is no mention of streaming data, I would prefer to use Lakehouse as a data storage. Eventhouse is primarily designed for Streaming data and KQL analytics. Writing data using Apache Spark is not the ideal usecase for Eventhouse. On the other hand, Lakehouse can store unstructured data, supports native write access via Apache Spark, can read using T-SQL (using SQL endpoint) and KQL (using shortcuts to Kusto). In real world scenario, Lakehouse is the ideal choice in such a case.
-
RG_123 👍 2 Answered AAnswer is A: We should consider the fact that it is a semi structured data and not the real time data. We use Eventhouse when we have a streaming/real time data. So for Semi-Structured data, we will store it in a lakehouse and create a short for it in eventhouse. In this way, we can read the data stored in lakehouse using KQL.https://learn.microsoft.com/en-us/fabric/fundamentals/decision-guide-data-store (Here it is clearly mentioned that if you want to store the semi structure data, use Lakehouse and for streaming data, use eventhouse)
-
Wipag 👍 2 Answered AA. a lakehouse Designed to handle structured, semi-structured, and unstructured data. Stored in Delta Lake format, making it accessible from: Spark (native) T-SQL via the SQL analytics endpoint KQL via OneLake integration Supports multi-engine access. Ideal for big data + analytics scenarios, especially with semi-structured data like JSON, Parquet, etc. Spark is commonly used to write to lakehouses.
-
PBridge 👍 2 Answered AA lakehouse in Microsoft Fabric supports semi-structured data formats (e.g., JSON, Parquet). It enables access using: T-SQL via SQL endpoint KQL via shortcuts or integration with real-time data Apache Spark for data engineering tasks Since the data will only be written by Spark, and needs to be read using multiple languages, the lakehouse is the most flexible and performant storage choice.
-
zulajariwala 👍 2 Answered AA Lakehouse in Microsoft Fabric supports Spark for writing and allows you to read the same data using T-SQL, KQL, and Spark. It is designed for semi-structured data (JSON, Parquet, etc.). Eventhouse is mainly for streaming/KQL scenarios. Warehouse and Datamart are primarily structured, SQL-focused storage and not intended for Spark-written semi-structured data.
-
realthiagoluna 👍 2 Answered ATo read data using T-SQL, KQL, and Apache Spark, while ensuring the data is only written by Apache Spark, the appropriate storage solution is a lakehouse. An eventhouse, which is typically used for real-time streaming data, does not fully support this specific combination of read/write operations and data type flexibility.
-
Thatoyaka 👍 2 Answered AEventhouse in Microsoft Fabric is not designed to be written to directly from Apache Spark. It is optimized for ingesting real-time and high-velocity telemetry data, typically using Kusto Ingest mechanisms or built-in connectors (like Azure Event Hubs, IoT Hub, etc.).
-
jjveliz 👍 2 Answered Alakehouse is the ideal storage solution for this scenario because it is specifically designed to handle semi-structured data and supports read operations using T-SQL, KQL, and Apache Spark, while also allowing write operations exclusively with Spark.
-
279312 👍 2 Answered ALakehouse is correct considering - Due to additional point in the question - The data will only be written by using Spark. If we consider other points, others are possible in eventhouse too
-
LuisPBI25 👍 2 Answered BLakehouse read operations available are only T-SQL and Spark. However, Eventhouse read operations permitted are T-SQL,Spark and also KQL as it is required in the question.
-
Maggiee 👍 2 Answered ALakehouse in Microsoft Fabric supports: Semi-structured data Reading data using: T-SQL KQL Apache Spark Writing data using Spark Delta Lake storage format
-
ayushc 👍 2 Answered ABy default you cannot query a lakehouse with kql but if you integrate it with Real time analytics you are able to query the lakehouse with kql
-
DataConsultant 👍 2 Answered AA Lakehouse in Microsoft Fabric is the best choice for storing semi-structured data while allowing access using T-SQL, KQL, and Apache Spark
-
Bs2009 👍 2 Answered Acorrect answer is A because data is written "The data will only be written by using Spark" so in event house primary write engine is KQL .
-
Thatoyaka 👍 2 Answered AA Lakehouse provides the flexibility to write with Spark and query with T-SQL, KQL, and Spark, making it the best fit for your scenario.
-
CMDev 👍 2 Answered BCheck this link and choose an answer, it must be B. https://learn.microsoft.com/en-us/fabric/fundamentals/decision-guide-data-store
-
SannaLH 👍 2 Answered BLike 38578c4 link says: Eventhouse support read with: KQL, T-SQL, Spark & write with: KQL, Spark, connector ecosystem
-
ogbenisho 👍 2 Answered BObviously, the answer is B - T-SQL, KQL and Spark can be used on Eventhouse - T-SQL & Spark can be used on Lakehouse
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.