PL-300 Time Intelligence 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.

• ✓

  A separate date table with a continuous range of dates and a relationship to the fact table.

  Why this is correct

  This is the minimum requirement for correct time intelligence in Power BI. A separate date table must include every date in the range spanning the fact table's dates, with no gaps, and be marked as a date table; critically, it must also have a relationship (typically one-to-many) to the fact table's date column so that filters propagate correctly. With this structure, DAX functions such as TOTALYTD, SAMEPERIODLASTYEAR, and DATEADD can safely rely on the continuous calendar to compute period-over-period comparisons. Note that marking the table as a date table is also mandatory, but the separate table and relationship are the foundational prerequisite.

• ✗

  Mark the date table as a date table in Power BI.

  Why it's wrong here

  Marking a table as a date table is a necessary post-creation step, but it is not the minimum requirement by itself—the table must first exist, contain a continuous range of dates, and be related to the fact table. If you merely mark an unrelated or incomplete table as the date table, Power BI's time intelligence functions will fail to filter the fact table correctly because there is no relationship to propagate the date context. In short, marking enables DAX to recognize the calendar, but it cannot substitute for actually having a valid date table and a relationship from it to the fact table.

• ✗

  Combine date and fact tables into one table.

  Why it's wrong here

  Combining the date and fact tables into a single table removes the dedicated calendar dimension that time intelligence requires, because the resulting table would have multiple rows per date (one per fact row), violating the rule that a date table must have exactly one row per date with no duplicates. This also destroys the one-to-many relationship and makes it impossible to mark the table as a date table, since Power BI will reject a table with non-unique dates. The standard star-schema approach keeps the date table separate to allow slicers, hierarchies, and time intelligence to work against a clean, unique calendar.

• ✗

  A single date column in the fact table.

  Why it's wrong here

  A single date column in the fact table cannot serve as a time-intelligence-ready date dimension because DAX time intelligence functions require a separate table with a continuous, gap-free range of dates, not the transactional dates scattered across fact rows. Fact tables typically contain duplicate dates, missing non-business days, or a limited range that does not span the entire reporting period, which would produce incorrect YTD or prior-period comparisons. Furthermore, without a dedicated date table, there is no place to hold calendar attributes such as fiscal year or week number, and you cannot mark it as a date table.

Go deeper

Related to this question