The archives network's finance office keeps ticketing revenue and membership-fee data that must support multi-table transactions, foreign-key style relationships between branches and transactions, and heavy T-SQL reporting for the annual audit. Which Fabric data store should host this data?
Select an answer to reveal the explanation.
Short Explanation
Think of the finance office's needs like a proper ledger book, not loose sticky notes: entries need to line up across pages and balance every time someone checks. A Warehouse gives you that ledger — full T-SQL, transactions, and relationships that hold together under audit.
Full Explanation
A Warehouse is Fabric's relational store, offering complete T-SQL DML and DDL support along with multi-table transactional guarantees, which is exactly what an audit-grade ticketing and membership-fee system needs when transactions must stay consistent across related tables. Its SQL surface is also the most natural fit for the kind of reporting an annual audit demands. An Eventhouse can run aggregations through KQL, but it's designed around append-heavy, timestamped telemetry rather than transactional financial records with relational integrity requirements, and it doesn't offer the same DML/DDL depth. Restricting a Lakehouse to Spark-only access throws away the very thing the finance office needs — a SQL-first, transactionally consistent surface — in favor of a compute engine better suited to large-scale, schema-flexible transformation work. A shortcut into the vendor's external database avoids building a governed Fabric-native store entirely, leaving the archives network dependent on an external system's availability and access model for audit-critical data. Before finalizing, verify the Warehouse's stored procedures and constraints actually enforce the referential rules the audit expects, rather than assuming schema alone provides them.