General Exam Tips
- 1.Read every question twice — scenario-based questions often embed the key constraint in a single phrase you can miss on a first pass
- 2.For code-based questions, look for two nearly identical options first — the correct answer is almost always one of those two, not the oddly different ones
- 3.Read case study questions BEFORE reading the scenario material, then scan the text only for what each question actually needs
- 4.Flag and skip questions you are unsure about; 100 minutes for ~50 questions gives roughly 2 minutes per question, and spending 5 minutes on one question breaks your pacing
- 5.Never leave a question blank — there is no penalty for wrong answers, always guess if you must
- 6.The exam may allow access to Microsoft Learn via a split window. Note: Ctrl+F does not work in that window, so learn to use the search bar before exam day
- 7.Prepare Data is 45-50% of the exam (the heaviest domain) — treat it as its own exam embedded inside the larger one
- 8.Hands-on experience matters more than documentation reading: candidates who only read report conceptual gaps in scenario questions that require judgment about when to use which tool
- 9.When a question asks which tool or approach is BEST, look for constraint keywords: 'low-code', 'large scale', 'complex logic', 'real-time', 'preserve history', 'reduce cost' — those words narrow the answer
- 10.Practical experience creates false confidence: candidates with daily Fabric use have reported scoring under 60% on first practice tests. The exam tests conceptual precision, not just familiarity
Prepare Data
Must-Know Facts
- Lakehouse SQL analytics endpoint is READ-ONLY — it does not support INSERT, UPDATE, DELETE, stored procedures, or user-defined functions
- Warehouse supports full T-SQL read-write: views, stored procedures, user-defined functions, ACID transactions
- OPTIMIZE compacts small Delta files into larger ones and improves query speed — it is a performance operation
- VACUUM removes old Delta file versions beyond the retention threshold — it reclaims storage, it does NOT improve query performance
- SCD Type 1 overwrites the existing value — no history is preserved
- SCD Type 2 inserts a new row with effective start/end dates — the old record remains with an end date, preserving full history
- Bridge tables are the correct solution for many-to-many relationships in a star schema — avoid direct many-to-many unless you understand the bidirectional filter implications
- Dataflows Gen2 destination options include Lakehouse tables, Warehouse tables, and other Fabric items — they do not execute Spark directly
- Data Pipelines orchestrate activities (Copy, Dataflow, Notebook, Stored Procedure) but do not transform data themselves — transformation happens inside the activities
- KQL is exclusively for Eventhouse (Real-Time Intelligence) — it does not work against Lakehouse or Warehouse
- DAX is for semantic models — do not confuse it with the query language for raw data stores
- T-SQL is for Warehouse and the Lakehouse SQL analytics endpoint — but only the Warehouse supports DML
- Shortcuts in OneLake are pointers, not data copies — they allow accessing external data without ingestion overhead
- A workspace on Shared capacity cannot host Fabric items (Lakehouse, Warehouse, Dataflow Gen2, Notebooks, Pipelines) — Fabric capacity or Premium is required
- Query folding in Dataflows Gen2 means the transformation logic is pushed to the source system — breaking query folding forces processing in the dataflow engine, which is slower
- Dataflows Gen2 staging: staging routes data through a Lakehouse before the final destination, which enables query folding across more steps
- Visual Query Editor in the Fabric portal provides a no-code drag-and-drop interface to build and run T-SQL queries against Lakehouse SQL endpoints and Warehouses
- OneLake integration for Eventhouse: Eventhouse data can be exposed to OneLake as Delta tables, allowing downstream tools (semantic models, Notebooks, Warehouses) to query real-time data without duplicating it
Common Traps
Confusing Pairs
Scenario Tips
When the question asks about querying real-time telemetry or log data stored in Eventhouse with time-based filtering...
Use KQL. Eventhouse is purpose-built for time-series and telemetry data, and KQL's pipe syntax with where, summarize, and ago() functions handles this natively
T-SQL seems plausible because Fabric uses T-SQL in Warehouse, but T-SQL does not work against Eventhouse. Never use T-SQL for Eventhouse scenarios
When a scenario requires customer dimension attributes to reflect only the current values (old values are irrelevant), and the question asks which SCD type to implement...
SCD Type 1. Overwrite the existing dimension row. No history table needed
Type 2 sounds more comprehensive, but Type 2 is only warranted when history must be preserved for analytical querying (e.g., 'what region was this customer in when they placed this order in 2022?')
When a question asks which tool to use for 500GB+ JSON ingestion with custom incremental load logic and schema inference...
Apache Spark Notebook. Handle schema inference with Spark, write incremental logic in PySpark, write output as Delta tables to Lakehouse
Dataflows Gen2 can handle JSON but struggles with 500GB, complex schema inference, and custom incremental logic. The Data Pipeline Copy activity moves data but cannot apply complex transformation logic
When a scenario asks how to support many-to-many relationships between sales territories and products where a product can belong to multiple territories and vice versa...
Create a bridge table (also called a junction or association table) that holds the foreign keys from both dimension tables, then create one-to-many relationships from each dimension to the bridge table
Direct many-to-many relationships in semantic models work but create ambiguous filter paths and can produce incorrect aggregations in complex DAX scenarios. The exam expects the bridge table pattern for star schema design
When a question describes a business analyst who needs to query and aggregate Warehouse data visually without writing SQL code...
Use the Visual Query Editor inside the Fabric portal — it provides a drag-and-drop no-code interface for filtering, joining, and aggregating data that generates T-SQL behind the scenes
Power BI reports and DAX measures are for visualization and modeling, not ad-hoc SQL querying. Dataflows Gen2 are for ETL pipelines, not exploratory querying. The Visual Query Editor is the no-code query tool within Fabric itself
When a question describes a scenario where users cannot see the option to create a Lakehouse or Dataflow Gen2 in a workspace, despite having Contributor access...
The workspace is on Shared capacity. Fabric items require Fabric or Premium capacity — the absence of these creation options is a capacity indicator, not a permissions issue
Adding the user to a higher workspace role (Admin, Member) will not fix this. The issue is the capacity type of the workspace, not the user's role. This is a common exam trap that tests capacity knowledge
Last-Minute Facts
Maintain a Data Analytics Solution
Must-Know Facts
- RLS (Row-Level Security) filters rows using DAX expressions — users see the table and column names, only their permitted rows are hidden
- OLS (Object-Level Security) hides entire tables or columns — the field list shows nothing; the object is invisible to unauthorized users
- OLS can ONLY be configured via external tools like Tabular Editor — it cannot be configured natively in Power BI Desktop
- CLS (Column-Level Security) restricts access to specific columns at the SQL/data layer — configured in Warehouse or the Lakehouse SQL endpoint, separate from semantic model security
- File-level access control restricts access to specific files or folders in the Lakehouse Files section using OneLake access permissions — this operates at the storage layer, below the SQL analytics endpoint
- Workspace roles: Admin > Member > Contributor > Viewer — Viewer can read content but cannot create reports or use Analyze in Excel
- Build permission on a semantic model is separate from workspace Contributor role — a user needs Build permission to create reports on a shared model
- Item-level permissions override workspace roles for specific items — you can grant a Viewer-level user Build access on one semantic model without promoting their workspace role
- Sensitivity labels propagate DOWNSTREAM automatically — if a Lakehouse is labeled Confidential, derived warehouses and semantic models inherit the label
- Endorsement: Promoted = team-level signal of quality. Certified = organization-wide single source of truth, requires specific tenant permission
- Git integration connects a workspace to Azure DevOps or GitHub — enables version control, branching, pull requests for Fabric items
- Deployment pipelines promote content through Dev, Test, and Production stages — separate from Git, which handles source control
- PBIP (Power BI Project) stores report components as human-readable JSON in a folder structure — Git-friendly, designed for team collaboration
- PBIX is a binary monolithic file — not suitable for Git version control or collaborative development
- PBIDS (Power BI Data Source) is a connection file that pre-configures data source settings — sharing a PBIDS lets team members connect to the same data source without entering connection strings manually
- XMLA endpoint enables external tools (SSMS, Tabular Editor, ALM Toolkit) to connect and manage semantic models programmatically
- Lineage view and impact analysis show downstream dependencies before you make changes — use them before modifying source tables or semantic models
- Direct Lake mode requires Fabric or Premium capacity — it does not work on Shared capacity
Common Traps
Confusing Pairs
Scenario Tips
When a question asks how to ensure sales managers see only their region's data in a Power BI report built on a shared Fabric semantic model...
Configure Row-Level Security (RLS) in Power BI Desktop — define a role with a DAX filter expression like [Region] = USERNAME() or USERPRINCIPALNAME()
OLS hides the Region column entirely, which is wrong — managers need to see the column, just filtered to their own region. CLS restricts columns, not rows. Workspace permissions control access to the whole workspace, not individual rows
When a question asks how to hide the Salary column from non-HR users so the column does not appear in their field list at all...
Configure Object-Level Security (OLS) using Tabular Editor to hide the Salary column from non-HR roles
RLS filters rows, not columns — the Salary column would still appear in the field list. Hiding a column in Power BI Desktop's field properties hides it from everyone including authorized users. OLS via Tabular Editor is the only way to selectively hide a column based on user role
When a team needs to develop Power BI reports collaboratively using pull requests and branching...
Use PBIP format and connect the workspace via Git Integration to Azure DevOps or GitHub. PBIP stores components as JSON files that Git can diff and merge
Deployment Pipelines do not provide version control or branching — they only promote content between environments. PBIX files cannot be meaningfully diffed in Git because they are binary
When a scenario describes external consultants who need to build reports on one specific semantic model but should not see anything else in the workspace...
Grant item-level Build permission on the specific semantic model directly to the consultants — do not add them to the workspace at all, or add them as Viewer at workspace level plus Build permission on the item
Adding them as Contributor at workspace level exposes all workspace items to them, which violates the constraint in the scenario
When a question asks how to prevent a data engineer from reading raw Delta Parquet files in a Lakehouse while still allowing them to query the Lakehouse SQL analytics endpoint...
Configure file-level access control using OneLake access permissions to restrict access to the Files section of the Lakehouse, while granting the user SQL endpoint read permissions separately through item-level permissions
RLS and OLS operate at the semantic model layer, not the file storage layer. Workspace Viewer role gives read access to items but does not control raw file access at the OneLake storage level. File-level and SQL endpoint permissions are configured independently
When the question asks what to review BEFORE deleting a Lakehouse table that is used by multiple downstream reports and semantic models...
Use Impact Analysis (Lineage view) in the Fabric workspace to identify all downstream dependencies — semantic models, dataflows, and reports that reference the table — before making any changes
Simply checking the Lakehouse item properties or searching the workspace manually will miss hidden dependencies. Impact Analysis is the specific Fabric feature for this — the exam tests that candidates know it exists and when to use it
Last-Minute Facts
Implement and Manage Semantic Models
Must-Know Facts
- Import mode copies data into the semantic model at refresh time — fast queries, but data is stale until next refresh
- DirectQuery mode sends every report interaction as a live query to the source — always current data, but slower and source-dependent
- Direct Lake on SQL endpoints reads Delta tables from a single SQL endpoint into memory — fast like Import, near-real-time like DirectQuery. Falls back to DirectQuery for SQL views, RLS enforcement, or guardrail breaches
- Direct Lake on OneLake references Delta tables from multiple Fabric items (Lakehouse + Warehouse in one model) — does NOT fall back to DirectQuery; guardrail violations cause refresh failure instead
- Direct Lake framing: the engine loads column data into memory from OneLake — no data is copied, just loaded into the in-memory engine
- Composite models with Direct Lake on OneLake: can mix with Import tables from any source. Composite models with Direct Lake on SQL endpoints: cannot mix with DirectQuery or Dual tables
- Calculation groups apply to ALL measures by default — explicitly exclude measures that should not be affected using precedence or exclusion filters
- Incremental refresh requires a DateTime column AND named parameters RangeStart and RangeEnd of type DateTime — without these, incremental refresh cannot be configured
- Large semantic model storage format removes the default size cap — enables enterprise-scale models beyond 10GB in Premium/Fabric capacity
- DAX CALCULATE changes the filter context — it is the most important DAX function and the source of most evaluation context confusion
- DAX iterators (SUMX, AVERAGEX, MAXX, MINX) evaluate a table row by row — they accept a table and an expression, not a single column
- VAR/RETURN in DAX: variables are evaluated at the point of definition, not at the point of use — this freezes the filter context at definition time
- External tools for semantic models: DAX Studio (DAX query performance), Tabular Editor (model scripting, OLS, calculation groups), ALM Toolkit (compare/merge models), Vertipaq Analyzer (column memory usage)
- Dynamic Management Views (DMVs): query $SYSTEM.DISCOVER_STORAGE_TABLE_COLUMN_SEGMENTS to analyze column memory usage; $SYSTEM.MDSCHEMA_MEASURES to list measures
- Field parameters allow report consumers to dynamically swap which measures or dimensions appear on visual axes — configured in the semantic model, surfaced as a slicer in the report
- Dynamic format strings use DAX expressions to conditionally format measures (e.g., show $ symbol only when a currency measure is selected)
- Fixed identity cloud connection: strongly recommended when using semantic model RLS with Direct Lake to ensure consistent data access control regardless of end user identity
Common Traps
Confusing Pairs
Scenario Tips
When a semantic model needs to access Delta tables from both a Lakehouse and a Warehouse in the same Fabric workspace without copying data...
Use Direct Lake on OneLake — it can reference tables from multiple Fabric items in a single model without data duplication
Direct Lake on SQL endpoints only supports a single SQL endpoint. DirectQuery adds query overhead. Import copies data. Only Direct Lake on OneLake supports multiple source items in one model
When a question asks why a Direct Lake semantic model is falling back to DirectQuery for some queries...
Direct Lake on SQL endpoints falls back when: (1) the model uses SQL views instead of Delta tables, (2) RLS defined in the model is enforced, or (3) guardrail thresholds are exceeded
If using Direct Lake on OneLake, fallback to DirectQuery does not happen — the query fails instead. The question will specify which variant if relevant. If you see 'falls back to DirectQuery', the model is using Direct Lake on SQL endpoints
When a 50GB semantic model exceeds the default dataset size limit and the question asks what to enable...
Enable large semantic model storage format in the workspace settings and dataset settings. This removes the default cap
Incremental refresh reduces refresh time but does not change the model size limit. DirectQuery avoids loading data but is a different trade-off. The size limit is resolved by enabling large model storage format, not by changing storage mode
When the question asks about applying year-to-date, quarter-to-date, and month-to-date calculations across 20 different measures without duplicating DAX logic...
Use calculation groups — define calculation items (YTD, QTD, MTD) once, and they apply to all measures automatically
Creating separate YTD, QTD, MTD variants of each measure (20 x 3 = 60 measures) is the anti-pattern calculation groups exist to prevent. Field parameters are for swapping what is displayed, not applying time intelligence logic
When a scenario involves analyzing which columns consume the most memory in a Direct Lake model to optimize its footprint...
Use Vertipaq Analyzer (accessible through Tabular Editor or DAX Studio) to inspect column-level memory consumption, or query DMVs like $SYSTEM.DISCOVER_STORAGE_TABLE_COLUMN_SEGMENTS
The Fabric portal performance analyzer shows report visual timings, not model memory breakdown. The exam specifically tests knowledge of DMVs and external tools for model analysis
When a question asks about enabling fallback behavior control for a Direct Lake semantic model, and the organization wants queries to FAIL rather than silently switch to DirectQuery...
Disable the fallback setting on the Direct Lake connection — this forces queries to fail when Direct Lake cannot serve them, helping the team detect incompatibilities rather than silently degrading to DirectQuery
Allowing fallback (the default) is appropriate when reliability is more important than enforcing Direct Lake performance. The exam tests whether you understand the fallback setting exists and what each option means for the business