Implement and manage semantic models
Free Microsoft Certified: Fabric Analytics Engineer Associate practice — 6 questions on Implement and manage semantic models, with explanations. No sign-up. Full 12-question mixed test →
A Direct Lake semantic model in Fabric runs on an F64 capacity. A developer adds a calculated column to the Sales fact table that uses the RELATED() function to pull a category name from a dimension table. After publishing, capacity metrics show the model executing DirectQuery operations instead of using Direct Lake mode. What is the MOST likely cause?
Calculated columns (and calculated tables) require row-by-row DAX evaluation that Direct Lake's columnar OneLake reading engine doesn't support, so any such objects force the engine to fall back to DirectQuery for the affected queries.
You create a calculation group named 'Time Calcs' containing a calculation item 'YoY %' that returns a DIVIDE() expression producing a ratio. When report authors apply this item to the Total Sales measure, the visual displays the result as currency instead of a percentage. Which change correctly fixes the display without altering the base measure's format?
Calculation items support a Format String Expression property that lets each item dynamically override the display format of any measure it's applied to — exactly the pattern used for switching a ratio result to percentage format without touching the base measure.
A semantic model hosted in a Fabric workspace grows to 14 GB after adding several years of transaction history. Refresh operations begin failing with an error referencing the maximum size for the current storage format. The workspace is assigned to an F64 Fabric capacity. What should you do to resolve this without reducing the amount of data in the model?
The 'Large semantic model storage format' setting removes the default dataset size limit and is only available for models hosted in workspaces on Fabric (or Premium) capacities such as F64 — exactly the situation described.
A team is designing a semantic model with a 200 million row fact table. They want to configure an Incremental Refresh policy using RangeStart and RangeEnd parameters to only refresh recent partitions on a schedule. Which storage mode configuration supports this feature?
Incremental refresh policies with RangeStart/RangeEnd apply to tables that are actually loaded into the model (Import mode, including the Import partitions of hybrid tables). They define how Power Query partitions and refreshes data on a schedule.
A composite model has a large DirectQuery fact table (Sales) sourced from a Fabric warehouse and several small dimension tables (Date, Product, Region) currently also set to DirectQuery. Report performance is slow because every slicer interaction re-queries the warehouse for dimension values. What change will BEST improve performance while keeping the fact table live?
Dual storage mode lets small dimension tables be cached in memory (like Import) for fast, local filtering while still being usable in DirectQuery queries against the live fact table — the standard composite-model pattern for this exact scenario.
A Direct Lake semantic model is hosted on an F64 Fabric capacity. One lakehouse table has grown past the row-count guardrail for that capacity SKU, and the model's Fallback Behavior property is set to Automatic. A report visual queries a measure that references this oversized table. What happens?
When a Direct Lake table exceeds capacity guardrails and Fallback Behavior is set to Automatic, Fabric silently falls back to DirectQuery for queries against that specific table so the report keeps working, while unaffected tables remain in Direct Lake mode.
Ready for the real thing?
The full course: two full-length practice tests, video lessons for every exam domain, hands-on labs and detailed explanations.
$109.99 $34.99 with code FREETEST33 — valid through September 16.
Get my $34.99 deal →