Data lands as Delta tables in a "Lakehouse". An analytics engineer needs to create persistent T-SQL stored procedures and views that run INSERT and UPDATE statements to build curated transformed tables. The "SQL analytics endpoint" of the Lakehouse exposes the tables but rejects the data-modification statements. Where should the engineer build these writable transformation objects?
- AContinue in the "Lakehouse" "SQL analytics endpoint" and grant the engineer higher T-SQL permissions so the INSERT and UPDATE statements are allowed to run.
- BCreate the procedures in the workspace default "semantic model", which can carry the T-SQL data-modification logic that the "SQL analytics endpoint" refuses to run.
- CCreate the stored procedures and views in a Fabric "Warehouse", which supports full read-write T-SQL and can run the INSERT and UPDATE logic against its own tables. Correct
- DMove the transformation into an "Eventhouse" and write the INSERT and UPDATE statements there, since it accepts the same T-SQL surface as a Fabric "Warehouse".
Why A is wrong: The endpoint is read-only over Lakehouse tables by design, so no permission grant enables INSERT or UPDATE there, which makes this the wrong place for writable objects.
Why B is wrong: A semantic model is a reporting layer with DAX, not a T-SQL execution surface, so it cannot host stored procedures that run INSERT and UPDATE statements.
Why C is correct: A Fabric Warehouse provides full read-write T-SQL, so it can host stored procedures and views that execute INSERT and UPDATE to build curated tables, unlike the read-only endpoint.
Why D is wrong: An Eventhouse is a KQL store for real-time telemetry and does not offer the read-write T-SQL DML surface, so it cannot replace a Warehouse for these objects.