250+ Microsoft Fabric Interview Questions & Answers (2026)

A: OneLake is a single, tenant-wide data lake built into every Fabric capacity and automatically provisioned with every tenant. Every workload — Lakehouse, Warehouse, Power BI, Real-Time Intelligence — stores data in Delta Parquet format inside OneLake by default, so data created by one workload is immediately readable by another without copying it. It’s commonly described as “OneDrive for data”: one location, one copy, accessible from every engine.

A: Use a shortcut when you need to reference data that already exists elsewhere — a different Fabric workspace, ADLS Gen2, S3, or Dataverse — without duplicating storage or maintaining a sync schedule. A shortcut is a virtual reference; queries against it read the source data directly. Use a pipeline instead when the data needs to be transformed, land in a different format, or be governed and versioned independently of the source.

A: The most common cause is data skew — one partition holding disproportionately more rows than the others, so a single executor runs out of memory while the rest sit idle. Diagnose it in the Spark UI by checking task duration and shuffle-read size across partitions; a small number of tasks taking dramatically longer than the rest is the signature. The fix is usually repartitioning on a higher-cardinality key or salting a skewed join key before the join executes.

A: A Starter Pool is a pre-warmed Spark cluster Fabric provisions automatically, optimized for fast session startup with a fixed node configuration. A Custom Pool lets you define node size, autoscale limits, and Spark configuration explicitly — needed when a job has non-default library requirements or needs executor memory tuned beyond the Starter Pool profile.

A: No. The SQL analytics endpoint on a Lakehouse is read-only — it’s generated automatically from the Delta tables for T-SQL querying and reporting, but you cannot INSERT, UPDATE, DELETE, or run stored procedures against it. Full read-write T-SQL, including DDL, DML, and stored procedures, requires a Fabric Warehouse item instead of a Lakehouse.

A: COPY INTO is a high-throughput T-SQL command for bulk-loading data into a Warehouse table directly from files in a Lakehouse, ADLS Gen2, or Azure Blob Storage. It’s significantly faster than row-by-row INSERT statements for large files and is the standard pattern for landing raw files into a Warehouse without staging through a pipeline first.

A: Use a Pipeline when the task is primarily orchestration — moving data as-is with Copy Activity, chaining steps, triggering notebooks, or scheduling. Use Dataflow Gen2 when the task needs low-code, Power Query-style transformation before the data lands. A common production pattern uses a Pipeline to orchestrate the overall flow and calls a Dataflow Gen2 as one step inside it for the transformation-heavy portion.

A: Fast Copy is an alternate execution path that bypasses the standard Power Query mashup engine for simple, large-volume copy operations, routing the data through Fabric’s scalable copy infrastructure instead. It activates automatically when a query qualifies — a straightforward source-to-destination copy without complex transformations — and can be dramatically faster than the default engine for large files.

A: Direct Ingestion routes events straight from the source to a destination with minimal added latency and no transformation. Event Processing routes events through a visual, node-based editor first, where you can filter, aggregate, or reshape the stream before it reaches its destination. Choose Direct Ingestion for the fastest raw path to storage; choose Event Processing when the destination needs a cleaned or aggregated shape instead of the raw stream.

A: The hot cache keeps a recent, configurable window of data on fast local storage for near-instant query response, while the full dataset remains queryable but at lower performance once data ages out of the cache. Size the hot cache window based on how far back your dashboards and alerts genuinely need sub-second response versus acceptable-but-slower historical queries.

A: Common triggers include the underlying Delta table exceeding Direct Lake’s size guardrails, RLS DAX expressions using functions like LOOKUPVALUE or iterators, certain relationship configurations, and the model being framed against the SQL analytics endpoint instead of OneLake directly. Fallback is silent and preserves correctness, but it trades Direct Lake’s performance advantage for DirectQuery’s query-time cost against the source.

A: High-cardinality columns — a GUID or a raw timestamp — consume disproportionately more memory when paged into Direct Lake’s cache and are far more expensive to encode than low-cardinality columns like a status flag. Removing unnecessary high-cardinality columns, or splitting a raw timestamp into separate date and time-of-day columns, is one of the most effective Direct Lake performance levers available.

A: A workspace role (Admin, Member, Contributor, Viewer) controls what a user can do at the item level — create, edit, or view items inside a workspace. A OneLake data access role controls what a user can see inside the data itself — specific rows, columns, or tables in a Lakehouse — independent of their workspace role. A workspace Viewer with no editing ability can still have granular OneLake data access roles determining exactly which rows they’re allowed to query.

A: Purview automatically catalogs Fabric items — Lakehouses, Warehouses, semantic models, reports — and captures lineage showing how data flows between them, largely without separate configuration. It also enforces sensitivity labels applied in Fabric, and the OneLake Catalog’s Govern tab surfaces Purview’s classification and lineage data directly inside the Fabric portal.