Difficulty: Medium | Concepts: Lakehouse, Medallion Architecture, Delta Lake, Shortcuts, Schema-on-Read

"Design a Lakehouse architecture for our sales data" is one of the most common Fabric Lakehouse interview questions — it's open-ended on purpose, to see if you reach for the industry-standard Bronze / Silver / Gold (Medallion) pattern rather than just dumping everything into one folder.

Scenario

You're onboarding a new source: daily sales exports from an on-prem SQL Server, plus a REST API for product returns. Leadership wants a single Lakehouse that supports both ad-hoc analyst queries and a Power BI semantic model, with clear data quality boundaries.

Medallion Layer Design

Layer	Purpose	Format
Bronze	Raw, unaltered copy of source data, exactly as ingested	Files (CSV/JSON/Parquet) or raw Delta
Silver	Cleaned, deduplicated, conformed types, joined reference data	Delta tables
Gold	Business-level aggregates, star schema, ready for reporting	Delta tables

Design Walkthrough

Bronze: Pipeline lands SQL Server exports and API responses untouched into Files/bronze/<source>/<date> — this preserves an audit trail and lets you replay history if a downstream bug is found.
Silver: A Notebook or Dataflow Gen2 reads bronze, applies schema enforcement, deduplication, and type casting, then writes to Delta tables like sales_silver and returns_silver.
Gold: A second Notebook (or dbt-style SQL) joins silver tables into a star schema — fact tables (fact_sales) and dimension tables (dim_product, dim_date, dim_customer) — optimized for the Power BI Direct Lake semantic model.
Use Lakehouse Shortcuts instead of copying data when the same silver table needs to be accessed from another workspace's Lakehouse — this avoids duplicating storage and keeps a single source of truth.

Visual Representation

SQL Server export ---\ > Bronze (raw, Files) REST API returns ---/ | v Silver (clean Delta tables: sales_silver, returns_silver) | v Gold (fact_sales, dim_product, dim_date) | v Power BI Direct Lake semantic model

Common Mistake to Avoid

A common red flag in interviews is proposing to overwrite bronze data on every load. Bronze should be append-only / immutable so you always have a historical audit trail — transformations and corrections belong in silver and gold, never by mutating the raw landing zone.

Conclusion

Interviewers aren't testing whether you can name "Bronze, Silver, Gold" — they're testing whether you understand why each layer exists: bronze for auditability, silver for reliability, gold for business consumption. Being able to justify shortcuts vs. copies, and immutability at the bronze layer, is what separates a strong answer from a memorized one.