Microsoft Fabric Power BI
Interview Questions

Direct Lake is a new storage mode available only in Fabric. Specifically, it allows the Power BI engine (VertiPaq) to load Parquet files directly from OneLake into memory without having to “Import” or refresh the data. Consequently, it combines the speed of Import mode with the real-time freshness of DirectQuery.

Import Mode copies data into a proprietary `.pbix` file, requiring scheduled refreshes and duplicating storage. In contrast, Direct Lake reads the Delta Parquet files referenced in the Lakehouse/Warehouse. There is no data movement; as a result, updates in the Lakehouse are visible immediately after a metadata refresh.

DirectQuery translates DAX into SQL and sends it to the source (e.g., Snowflake, SQL Server), which is often slow for complex aggregations. However, Direct Lake does not send SQL; it loads the column segments into memory on-demand. Therefore, Direct Lake is significantly faster than DirectQuery for analytical workloads.

Fallback occurs when a Direct Lake semantic model cannot execute a query using the Direct Lake path (e.g., due to unsupported DAX features, RLS limitations, or memory constraints). Consequently, it switches to DirectQuery mode against the SQL Endpoint. Unfortunately, this results in much slower performance.

Common causes include: 1) Using OLS (Object Level Security). 2) Using calculated columns in the semantic model. Instead, best practice dictates creating them in the Lakehouse using Spark/SQL. 3) Exceeding the memory limit of the F-SKU. 4) Using views in the Warehouse that don’t support Direct Lake.

It does not require a data refresh (copying rows). However, it requires a metadata refresh (framing). When the underlying Delta table changes (new files added), Power BI needs to be notified to reload the column dictionaries. This can be automatic or triggered via API.

When you create a Lakehouse or Warehouse, Fabric automatically creates a Default Semantic Model containing all tables. However, for production reporting, you should create Custom Semantic Models that include only the tables relevant to specific business domains (e.g., Sales Model, HR Model). Thus, you ensure better governance and performance.

Yes, you can edit relationships and DAX measures in the Default Model. However, you cannot remove tables from it, as it syncs with the Lakehouse schema. Therefore, best practice dictates leaving the Default Model for ad-hoc exploration and building Custom Models for curated reporting.

You can create a Composite Model (DirectQuery for PBI Datasets) on top of a Direct Lake model. This allows you to extend the central Direct Lake model with local Excel files or other sources. However, be aware that this introduces “chaining,” which can impact performance if the local source is slow.

Semantic Link allows Data Scientists working in Fabric Notebooks (Spark/Python) to connect directly to Power BI Semantic Models. They can query measures and hierarchies using the SemPy library. Consequently, this bridges the gap between BI and Data Science, ensuring both teams use the same logic.

Fabric encourages “Web Authoring” for Direct Lake models. While you can connect via Desktop using XMLA, the web interface allows you to model relationships and write DAX directly in the browser without downloading massive datasets. Furthermore, web authoring enables co-development capabilities.

Fabric workspaces support the XMLA endpoint. This means you can use external tools like Tabular Editor, ALM Toolkit, or DAX Studio to manage Fabric semantic models. As a result, this is crucial for enterprise Lifecycle Management (ALM) and advanced scripting.

V-Order is a write-time optimization in Fabric Spark engines. Specifically, it sorts and compresses Parquet files to maximize the read speed of the VertiPaq engine (Power BI). Consequently, enabling V-Order on your Delta tables can improve Direct Lake performance by 2x-3x.

High cardinality columns (e.g., GUIDs, Datetime with milliseconds) consume massive amounts of memory because dictionaries cannot compress them effectively. In Direct Lake, if a column segment is too large for the allocated memory, it may trigger a fallback. Therefore, always optimize data types upstream in the Lakehouse.

Framing is the process where Power BI identifies which Parquet files in OneLake constitute the current version of the data. When a refresh occurs, Power BI updates the “Frame” to point to the latest files. Importantly, queries executed during framing remain consistent due to Snapshot Isolation.

Use the Performance Analyzer in Power BI Desktop to check if queries are using DirectQuery (fallback). Furthermore, use the Fabric Capacity Metrics App to see if the dataset is causing memory thrashing or eviction. See our guide on Fixing Direct Lake Fallback.

Spark (Linux) is case-sensitive. However, Power BI (VertiPaq) is case-insensitive. This mismatch can cause issues in Direct Lake. For example, “Apple” and “apple” are distinct in Spark but identical in PBI. As a best practice, normalize case (e.g., UPPER()) during the ETL phase before the data hits the Lakehouse.

Direct Lake models support paging. If the model size exceeds the memory of the F-SKU, Fabric can page out cold column segments (eviction to disk cache). However, paging causes latency. Therefore, to fix this, you must either resize the SKU or optimize the model schema.

The maximum model size is dictated by the F-SKU memory limit. For example, an F64 supports larger models than an F2. That said, Direct Lake can technically handle larger data volumes than Import mode because it only loads the columns queried into memory (load-on-demand), not the entire table.

In Direct Lake, Calculated Columns are generally discouraged because they are computed on the fly or force a fallback. Instead, creating computed columns physically in the Lakehouse (using Spark or SQL) is preferred so they are stored as compressed Parquet data. Consequently, read performance improves.

Fabric fully supports Calculation Groups. They allow you to reduce redundant measures (e.g., YTD, MTD, YoY) by applying dynamic calculation logic on top of existing base measures. Moreover, you can create them using Tabular Editor (via XMLA) or now natively in the Web Modeling view.

Direct Lake supports standard RLS defined in the semantic model (DAX roles). However, there is a nuance: if you define RLS in the Warehouse (SQL), the Direct Lake model does not inherit it automatically. Therefore, you typically define RLS in the Semantic Model layer for Power BI users.

Field Parameters work in Direct Lake just as they do in Import. They allow end-users to dynamically change the measures or dimensions displayed in a visual. As a result, this feature significantly empowers self-service reporting.

Copilot in Fabric can auto-generate DAX measures, create report pages based on natural language prompts, and generate narrative summaries of data. See our guide on Troubleshooting Power BI Copilot.

To use Copilot, your capacity must be F64 or higher (or P1). Furthermore, the tenant admin must enable the AI settings. Finally, Copilot leverages the data in your semantic model to generate insights, so clear column naming and descriptions are vital.

For Copilot (and Q&A) to work effectively, your model must be “AI Ready.” Specifically, this means using user-friendly synonyms, hiding technical ID columns, providing descriptions for measures, and ensuring relationships are clean (Star Schema). See Getting Power BI AI Ready.

Fabric workspaces support Git integration (Azure DevOps). When you commit, the report is saved as a PBIP (Power BI Project) format. This breaks the binary `.pbix` into human-readable text files (JSON). Consequently, this allows for diffing, version control, and collaborative development.

Use Deployment Pipelines to promote content across Dev, Test, and Prod workspaces. Moreover, Fabric pipelines can swap the connection of a report from a “Dev Lakehouse” to a “Prod Lakehouse” automatically using parameter rules during deployment.

Promoted: Data owners can mark their items as promoted to encourage usage. Certified: A higher tier, usually restricted to a central IT or Governance team. Basically, it indicates the data is fully validated and trustworthy for enterprise decision-making.

Before deleting a Lakehouse or Semantic Model, use the Lineage View to perform impact analysis. This visualization shows all downstream dependencies (reports, dashboards). Thus, you can avoid breaking critical reports if the upstream item is modified.

Domains allow you to group workspaces by business unit (e.g., Finance, Sales). In the Power BI OneLake Data Hub, users can filter data by Domain. As a result, this improves discoverability in large organizations preventing “data swamp” issues.

The OneLake Data Hub inside Power BI Desktop allows analysts to discover existing Fabric items (Lakehouses, Warehouses, Semantic Models). Consequently, it encourages reuse of “Golden Datasets” rather than every analyst importing raw CSVs repeatedly.

Migration involves repointing your capacity. You do not need to redeploy reports. However, to gain the benefits of Fabric (Direct Lake), you must migrate the Storage. Move data from Azure SQL/Import mode to OneLake (Parquet), then create a new Direct Lake semantic model. See our Migration Guide.

For PB-scale history, use Hybrid Tables via Composite Models (combining Direct Lake + DirectQuery). You can create a model that covers specific partitions (e.g., last 3 years). Additionally, older data can be queried via the SQL Endpoint using DirectQuery if needed, keeping the hot model lean.

Yes. If you use a streaming ingestion job (Eventstream) into a Lakehouse, the Parquet files update continuously. You can configure the Direct Lake model to refresh its metadata automatically (e.g., every 5-15 minutes). Consequently, this provides near-real-time dashboards without the query load of DirectQuery.

Use Power BI Projects (PBIP) with Git integration. Each developer creates a feature branch. They work on local copies of the report. Then, Pull Requests (PRs) are used to merge changes into the `main` branch, resolving conflicts in the JSON definitions before deploying to the workspace.

Power BI consumption (rendering reports) burns CUs (Capacity Units). Use the Capacity Metrics App to identify which reports are “expensive.” If a report causes throttling, optimize its DAX or move it to a different capacity to isolate the noisy neighbor.

Fabric allows External Sharing (B2B). You can share a Fabric app or report with a guest user (Azure AD B2B). The guest user accesses the report using their own credentials. However, the compute is charged to your Fabric capacity.

Direct Lake memory limits are tied to the SKU. An F64 behaves like a P1 (Premium). If you are migrating from Premium, start with F64. In contrast, for smaller workloads, F2-F4 are fine for development but may hit memory limits for large Direct Lake models.

For Semantic Models, you can use the XMLA endpoint to perform backups (`.abf` files) to ADLS Gen2. For the data in OneLake, Fabric handles redundancy (ZRS/GRS). Additionally, you should configure retention policies in the Lakehouse to recover from logical data corruption.