Microsoft PL-300: Model the data Practice Questions

Calculation items can reuse logic across explicit measures. Columns store row-level results; bookmarks and tooltips change report presentation rather than define reusable model calculations.

RELATED is used in a calculated column to retrieve a value from the 'one' side of a relationship when you are on the 'many' side. Since Shipments is the fact table (many side) and Customers is the dimension (one side), RELATED(Customers[CustomerCity]) is the correct function. LOOKUPVALUE works but is typically used when no relationship exists — it is less efficient and more verbose than RELATED when a relationship is already defined. RELATEDTABLE retrieves a table of related rows (from the many side), not a single scalar value from the one side. CALCULATE modifies filter context and does not directly retrieve column values from another table.

DAX query view runs DAX queries against the semantic model. Column Quality profiles source data, the Selection pane manages visual layers, and mobile layout controls presentation.

D is correct: since there is no relationship between ExchangeRates and Sales, LOOKUPVALUE is the appropriate DAX function to retrieve a scalar value from ExchangeRates based on the currently selected currency. MAX(Currency[CurrencyCode]) retrieves the single currency code in the current filter context (from a Currency slicer), and LOOKUPVALUE fetches the corresponding rate from ExchangeRates. Multiplying by SUM(Sales[Amount]) gives the converted total. A is wrong: RELATED is a row-context function used in calculated columns to traverse a relationship — it cannot be used in a measure context and requires an existing active relationship. B is wrong: USERELATIONSHIP activates an existing inactive relationship; it cannot create a relationship that does not exist in the model, and it is used inside CALCULATE for measure filters, not for arithmetic multiplication. C is wrong: SUMX with LOOKUPVALUE per row would work correctly in some scenarios, but it is inefficient for this use case because it performs a row-by-row lookup on the entire Sales table. Additionally, if all Sales[Amount] values are in USD and the exchange rate is a single scalar per selected currency, the row-level lookup is unnecessary. D is more efficient. E is wrong: TREATAS maps a table's columns to behave like another table's columns for filter propagation; it does not retrieve a scalar rate for multiplication and would not produce the desired calculation.

Option C is correct: TOTALYTD accepts an optional third argument — a string representing the fiscal year-end date in MM/DD format. Adding "6/30" correctly shifts the year-to-date calculation to reset on July 1 each year, matching a June 30 fiscal year-end. Option B is incorrect — DATESYTD does accept a year-end argument, but the question asks about the fix to the existing TOTALYTD measure; the equivalent fix for TOTALYTD is passing the year-end argument directly to it, not switching functions. Additionally, while replacing with DATESYTD(Date[Date], "6/30") inside CALCULATE would work, option B says to "replace TOTALYTD with DATESYTD and pass '6/30'" which is a valid alternative but option C is the more direct and minimal fix to the described code. Option D is incorrect — creating a fiscal year column does not change how TOTALYTD accumulates; you still need the year-end argument. Option A is incorrect — there is no setting in the Date table to specify a fiscal year-end that TOTALYTD automatically respects; the argument must be in the DAX expression.