Implement and manage semantic models: free practice questions

PREVIOUSQUARTER returns the set of dates in the quarter immediately preceding the last date in the current filter context, making it the standard function for this use case. DATEADD with QUARTER shifts the current period by one quarter, which is equivalent but PREVIOUSQUARTER is the idiomatic choice — DATEADD is also correct in behavior, but PREVIOUSQUARTER is the most direct answer. PARALLELPERIOD shifts by a complete period and is similar but typically used for same-quarter comparisons across years. DATESINPERIOD counts back one quarter from MIN(Date), which would return dates from the beginning of the selection minus one quarter, not necessarily the prior complete quarter, making it inaccurate for this purpose.

Incremental refresh is specifically designed to solve this problem: by partitioning the data and only refreshing recent partitions (e.g., the last 30 days), the majority of historical data (which rarely changes) does not need to be re-imported on every refresh cycle, dramatically reducing refresh duration. Option A (DirectQuery) would eliminate import refresh entirely but at the cost of query performance — every report interaction would hit the source database, which is not appropriate for a 200M row fact table used in interactive reports. Option C (splitting into yearly tables) is an anti-pattern that increases model complexity, breaks single-table measures, and does not actually reduce the time to refresh historical data if the union query still loads all rows. Option D (large model format + SKU increase) allows the model to grow larger in memory but does not address the root cause of slow refresh — the volume of data being re-imported each cycle.

The Format String Expression property on a calculation item accepts a DAX expression that returns a format string. Using IF(SELECTEDMEASURE() >= 1000000, ...) evaluates the magnitude of the current measure at runtime and returns the appropriate Excel-style format string, which Power BI then applies to the displayed value. This is the purpose-built mechanism for dynamic format strings in calculation groups. Returning a text string with the formatted value concatenated would change the measure's data type to text, breaking further aggregations and numeric operations. A separate 'Format' calculation group could theoretically work but would require users to manually select a format item — it does not dynamically respond to value magnitude. Field parameters control which field/measure is displayed, not how values are formatted; they cannot supply dynamic format strings to a calculation group.

WINDOW(1, ABS, 0, REL, ALL(DimDate[Date]), ORDERBY(DimDate[Date], ASC)) defines a window that starts at absolute position 1 (the first row in the ordered partition, i.e., the first date of all time) and ends at relative position 0 (the current row). This creates a running total from the very beginning of the data to the current date. Using ALL ensures all dates are considered regardless of filter context, which is appropriate for a cumulative total. Option A uses ALLSELECTED, which would respect slicer filters and could truncate the window start if a date slicer is applied. Option C (DATESYTD) is a valid YTD approach but does not use WINDOW as specified. Option D uses REL for the start position (-1, REL) which means 'one row before the current row,' producing a one-row lag rather than starting from the beginning of the dataset.

ALL(DimProduct) removes the row-level filter from the visual, and TOPN then selects the global top 10 products. CALCULATE replaces the existing product filter with this set of 10 products, so every row in the visual evaluates [Total Revenue] over the same 10 products, returning the same grand total for each row. TOPN does not require RANKX; it is a standalone table function. CALCULATE can be used with TOPN and this is a common pattern. KEEPFILTERS would intersect filters rather than replace them, but the core issue is ALL removing row context, not missing KEEPFILTERS.