Fabric Power BI Interview Questions

Critically: Direct Lake only loads the columns actually queried, not the full table. This is “cold column” loading — a 50-column table with a query touching 5 columns loads only those 5 into VertiPaq memory.

The DirectLakeBehavior property on the semantic model gives you control. Set to DirectLakeOnly to disable fallback entirely on a Direct Lake on SQL model — this mimics the no-fallback behavior of the OneLake variant and forces you to design within guardrail limits rather than relying on a silent degradation path.

Common fallback triggers for Direct Lake on SQL:

• Table row count exceeds the SKU’s Max Rows per table guardrail
• Query targets a SQL view (views always fall back in Direct Lake on SQL)
• RLS or CLS defined at the SQL analytics endpoint layer
• OLS (Object Level Security) applied to the model
• Model size on disk exceeds the Max model size guardrail

For Direct Lake on SQL, framing is triggered by the SQL analytics endpoint polling the Delta log. For Direct Lake on OneLake, framing uses OneLake APIs directly. The framing process can be scheduled, triggered via the Power BI REST API, or set to automatic. Excessive small Parquet files (from streaming micro-batches) slow framing because more files must be enumerated — this is why running OPTIMIZE on Gold tables before framing matters.

Verify current values at Microsoft Learn — Direct Lake overview. Values may update with SKU refreshes.

The fix belongs upstream — normalize string casing (e.g., UPPER() or LOWER()) in the Silver→Gold transformation step before data reaches the Lakehouse tables that Direct Lake reads. This is a data quality issue, not a Power BI configuration issue, so the solution is in the engineering layer, not the report layer.

The practical pattern: a Sales fact table (10B rows) stays in Direct Lake on a Lakehouse. A Targets CSV from SharePoint is added as an Import table in the same model. The model refreshes the Import table on a schedule while the Direct Lake fact table updates via framing. No ETL pipeline needed to land the CSV in OneLake first.

The design implication: Direct Lake can technically handle datasets larger than the SKU’s memory limit because it loads columns on demand and evicts cold ones. The cost is latency when evicted columns are re-accessed — a query that hits many columns in a rarely-accessed table will feel slower than a query on frequently-accessed columns that stay warm in memory.

Previously, the Default Semantic Model was effectively an append to the Lakehouse — delete the Lakehouse, lose the model. As an independent item, it has its own lifecycle, can be independently shared, certified, and Git-versioned. The recommendation is still to build Custom Semantic Models for production reporting (curated tables, specific business domains) and use the Default model for ad-hoc exploration.

The governance advantage of Custom models: a Sales analyst doesn’t need access to HR tables even if they’re in the same Lakehouse. A Custom Sales Semantic Model exposes only Sales tables. This also limits the surface area for RLS and governance policies — you’re securing a well-defined perimeter rather than managing security on every table in the Lakehouse.

Best practice remains: create computed columns physically in the Lakehouse using Spark or SQL whenever possible. Parquet-stored computed columns are faster because they’re compressed and read directly, with no runtime computation. Reserve calculated columns in the model for genuinely dynamic logic that can’t be pre-computed.

The “chaining” problem from DirectQuery for Power BI Datasets (where perf degraded through layers) doesn’t apply the same way here — the Direct Lake tables still load from OneLake directly; it’s the Import tables that add a refresh requirement. The performance impact is isolated to the Import table portion of the model.

A practical example: a data scientist building a churn prediction model wants to use the “Customer Revenue” measure defined in the corporate semantic model rather than reimplementing the complex DAX logic in Python. With Semantic Link, they call that measure from a Spark notebook and get a consistent number. This prevents the “two different revenue numbers” problem that plagues organizations where BI and DS teams calculate things independently.

For Direct Lake models specifically, XMLA reveals the mode: directLake partition property and shows whether the model is the OneLake variant (expression points to OneLake storage location) or the SQL variant (expression points to SQL analytics endpoint). This is the programmatic way to verify which variant a model is using. The compatibilityLevel is 1604 or higher for Direct Lake models.

Features only in web modeling: Edit Tables (change which OneLake tables the model uses), Transform Data (Power Query online for Import tables). Features only in Desktop: create a new Direct Lake on OneLake model, multi-artifact table selection, PBIP export. Authoring is increasingly Desktop-first for the OneLake variant — Fabric web is the previous generation’s primary surface.

The architectural implication: the old pattern of “Import = data locked in a .pbix blob, disconnected from the data platform” is gone. Import tables in Fabric semantic models are now Delta tables in OneLake, accessible by Spark, T-SQL, and other Fabric engines — closing the historic gap between BI storage and the data platform.

V-Order is enabled by default in Fabric Spark. It optimizes Parquet’s encoding for VertiPaq’s dictionary encoding — reducing the transcoding work VertiPaq does when loading column segments. For tables not read by Direct Lake (Bronze raw, Silver staging), the write overhead is pure cost with no read payoff. See the Direct Lake Optimization Guide for layer-by-layer configuration.

Fix upstream in the Lakehouse: truncate DateTime to minute-level (not millisecond) for reporting tables, replace GUID primary keys with integer surrogate keys in the model-facing layer, and avoid exposing raw transactional IDs as dimensions. These are Star Schema best practices that become Direct Lake performance requirements.

Why you’d set it: in production, silent fallback to DirectQuery means users get inconsistent performance without warning. A report that runs in 200ms under Direct Lake and 8 seconds under DirectQuery fallback delivers a confusing user experience. Setting DirectLakeOnly makes the failure explicit and detectable, which forces the engineering team to fix the root cause rather than working around it.

The split is critical: if Performance Analyzer shows “Direct query,” the problem is a fallback configuration issue (fix: DirectLakeBehavior or resolve the fallback trigger). If it shows “Direct Lake” but is still slow, the problem is the VertiPaq engine — cardinality, missing relationships, or inefficient DAX. If the model loads quickly but initial framing takes long, the problem is too many Parquet files in the source table — run OPTIMIZE.

The updated 2026 nuance: calculated columns that reference Direct Lake tables are now in Preview for the OneLake variant. But even when available, the best-practice recommendation doesn’t change — Parquet-stored columns (created in the Lakehouse) are still faster because they’re compressed at rest and load directly. Model-level calculated columns add runtime computation at framing time. Use them when the logic genuinely can’t be pre-computed.

For true sub-second real-time, Real-Time Intelligence (KQL Databases + Eventhouses) is the right Fabric tool — not Direct Lake semantic models. Direct Lake’s strength is “fresh enough” for business reporting, not streaming telemetry dashboards. Understanding this distinction prevents over-engineering Direct Lake for use cases it’s not designed for.

A model with 50 base measures and 5 time intelligence patterns would require 250 measures without Calculation Groups. With them: 50 base measures + 1 Calculation Group with 5 items. Maintenance reduces dramatically — update the time intelligence logic once, not 50 times.

The common production mistake: defining RLS in the Warehouse’s SQL security and connecting a Direct Lake on SQL model — every secured query falls back to DirectQuery, negating the performance benefit of Direct Lake. The right pattern: define RLS at the semantic model layer (DAX roles) for Direct Lake on SQL, or use OneLake Security for Direct Lake on OneLake.

The architectural significance: historically, a Power BI report told you what to do, and you’d then open a different system to do it. Task Flows embed the action into the report surface. Example: a manager viewing a procurement report can approve a purchase order directly in the visual — the approval writes back to the source system via a Fabric Data Agent or API connection, without leaving the report.

Copilot’s quality ceiling is directly determined by the semantic model’s metadata quality. A model where every column is named with business terms, every measure has a description, technical ID columns are hidden, and relationships are clean (star schema) gives Copilot the context it needs to generate accurate DAX. A model with columns named col_7_b will produce confusing outputs regardless of prompt quality.

From a governance perspective, Field Parameters are a significant maintenance tool: fewer report versions to publish, fewer semantic models to manage, less surface area for RLS configurations. One certified, well-governed semantic model + a Field Parameter-enabled report can serve a broad self-service audience safely.

With Fabric IQ (announced FabCon 2026), the semantic model’s business context extends beyond Power BI to Copilot in Microsoft 365 and external AI agents via the OneLake MCP server. A well-described semantic model with synonyms and descriptions becomes the interface through which AI agents understand your business data — making metadata quality a first-order architecture concern, not documentation housekeeping.

For Direct Lake models specifically, the PBIP format stores the model definition including the directLake partition mode and the OneLake/SQL endpoint expression. This means the entire model — structure, measures, relationships, storage mode — is versionable and deployable as code. Combined with Deployment Pipelines (Dev → Test → Prod), it’s a complete CI/CD story for Power BI.

This is the critical pattern for environment management: parameterize the Lakehouse reference in the semantic model so Deployment Pipelines can apply environment-specific rules without manual reconnection. Without this, promoting a Direct Lake model to production requires manually repointing the data source — error-prone and unscalable.

In practice, Certified = “this is the single source of truth for this metric.” In large organizations, having multiple teams build their own “Sales” semantic models leads to different revenue numbers across dashboards. Certification with enforced discovery (only Certified models appear in team-level report creation workflows) solves this.

In a large Fabric deployment, a single Lakehouse Gold table might feed 3 semantic models, 15 reports, and 40 dashboard tiles. Dropping or renaming a column without checking lineage breaks all of them silently — Direct Lake fallback or errors appear only when reports are loaded by users. The Lineage View is the pre-change risk assessment tool that prevents this.

Without Domains in a 500-workspace tenant: an analyst searching for “Sales” semantic models finds items from every team that named something “Sales.” With Domain-filtered discovery: the Finance analyst sees only Finance Domain items; they build reports on Finance-certified models rather than accidentally using a dev/test model with wrong numbers.

Security implication: guest users see only what the host’s RLS/OLS allows. But if the host model has no RLS, a guest sees everything the shared item exposes. Before sharing externally, audit the semantic model’s security — especially Direct Lake models where fallback to DirectQuery can sometimes bypass model-level security unexpectedly depending on the variant and configuration.

Most organizations complete Phase 1 quickly (a single admin action) and then evaluate Phase 2 table by table. Import tables that are under the guardrail limits and not requiring frequent refresh are candidates for conversion to Direct Lake. Large Import tables with complex transformations may stay as Import during a transition period.

The hot/cold architecture: the Gold Lakehouse holds 3 years of data in well-optimized Delta tables — this is the Direct Lake layer. A separate “Archive” Lakehouse holds everything older, accessible via a Shortcut in the same workspace. Report visuals that need historical depth switch to DirectQuery against the Archive; day-to-day dashboards run entirely on Direct Lake. The semantic model uses both in a single composite model.

A “noisy neighbor” pattern in Power BI: one heavily-used executive dashboard with multiple expensive calculated measures runs at 9 AM and consumes 60% of the F-SKU, causing throttling for everyone else. The Capacity Metrics App surfaces this. The fix: optimize the dashboard’s DAX (simplify measures, pre-aggregate in Lakehouse), move it to off-peak scheduling if results don’t need to be live, or isolate the workspace to a dedicated capacity.

The workflow for semantic model changes specifically: Tabular Editor via XMLA can script out and apply measure changes as code (BIM files or TMDL), which can be reviewed in a PR without needing to open Desktop. For large teams, TMDL (Tabular Model Definition Language) in the PBIP format enables truly collaborative model development without overwriting each other’s changes.

For viewer licensing: F64 removes the per-viewer Power BI Pro license requirement. If you have 200 report consumers, the F64 capacity cost may be cheaper than 200 × $10/month Pro licenses plus a smaller F-SKU. This is often the financial trigger for choosing F64 over F32 regardless of the technical guardrail calculation.

For a complete recovery strategy: (1) Semantic model definition → XMLA backup + PBIP in Git (Git is often sufficient and more granular), (2) OneLake data → Fabric’s BCDR (ZRS/GRS) + Delta time travel within the retention window, (3) Lakehouse notebooks and pipelines → Git integration. All three must be covered; any one gap leaves a recovery hole.