PL-300 Model the data Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  CALCULATE(SUM(Sales[Amount]), PARALLELPERIOD('Date'[Date], -1, MONTH))

  Why it's wrong here

  PARALLELPERIOD shifts the entire current filter context back by one month, but it preserves the shape of the original period rather than trimming to a single calendar month. If the current filter context is a partial month or spans multiple months, PARALLELPERIOD will return a similarly structured multi-row date range, causing the sales total to include dates outside the exact previous month. PREVIOUSMONTH, by contrast, always returns the complete contiguous preceding calendar month, which is the precise range needed for a month-over-month comparison. Thus, while PARALLELPERIOD may seem similar, its behavior is less deterministic for arbitrary date contexts and therefore incorrect here.

• ✓

  CALCULATE(SUM(Sales[Amount]), PREVIOUSMONTH('Date'[Date]))

  Why this is correct

  PREVIOUSMONTH is the correct time-intelligence function because it returns a single-column table containing all dates from the calendar month immediately before the last date visible in the current filter context on the 'Date' table. When this table is used as a filter argument inside CALCULATE, it overrides the existing date filtering on the Sales table, so SUM(Sales[Amount]) is evaluated over exactly the prior month's dates. This is the idiomatic DAX pattern for a previous-month measure, and it avoids the shape-preserving ambiguity of PARALLELPERIOD and the forward-looking behavior of NEXTMONTH. No other period-shifting function gives as clean a one-month window as PREVIOUSMONTH in this scenario.

• ✗

  CALCULATE(SUM(Sales[Amount]), DATEADD('Date'[Date], -1, MONTH))

  Why it's wrong here

  This option is tempting because `DATEADD` is a standard time intelligence function for calculating values from a shifted period, such as the previous month. It would be the correct choice if a dedicated 'Date' table, named 'Date', existed and was properly connected to the 'Sales' table. However, it fails this scenario because the question stem only specifies the `Sales` table with an `OrderDate` column, not a separate 'Date' table. Referencing `'Date'[Date]` without such a table or relationship would result in an error or an incorrect calculation, as `DATEADD` requires a contiguous date column from a date table.

• ✗

  CALCULATE(SUM(Sales[Amount]), NEXTMONTH('Date'[Date]))

  Why it's wrong here

  NEXTMONTH is the temporal opposite of PREVIOUSMONTH, returning all dates from the calendar month that follows the last date in the current filter context. This would cause CALCULATE to evaluate SUM(Sales[Amount]) over the upcoming month's sales, not the previous month's, which is the exact opposite of what the question requires. Even if the current filter context were a single month, NEXTMONTH always moves the date window forward, never backward. Therefore, this expression is fundamentally incompatible with any 'previous month' business question, making it clearly incorrect.

Go deeper

Related to this question