PL-300 Model the data Practice Question
A company has a fact table with sales data and multiple dimension tables. They want to create a measure that calculates the total sales amount for the current year, but the measure returns incorrect results when used in a visual with a date hierarchy. What is the most likely cause?
⚠ Common exam trap
It's easy for candidates to assume any relationship between tables will automatically filter, but Power BI requires exactly one active relationship per pair of tables, and inactive relationships are ignored unless explicitly activated in DAX.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The relationship between the date table and the fact table is inactive.
If the relationship between the date table and the fact table is inactive, measures that rely on time intelligence functions (like TOTALYTD, SAMEPERIODLASTYEAR, or a simple SUM with date filtering) will not automatically propagate filters from the date hierarchy to the fact table. In Power BI, only one active relationship can exist between two tables; inactive relationships require explicit activation via USERELATIONSHIP in DAX. Without that, the measure ignores the date filter and returns incorrect or blank results.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The date table is not marked as a date table in Power BI.
Why it's wrong here
In Power BI, marking a table as a date table enables DAX time intelligence functions such as TOTALYTD and SAMEPERIODLASTYEAR, which rely on built-in date intervals. However, when you use a standard date hierarchy (year, quarter, month) from that table, the engine filters fact rows based on the actual date column relationships, so an unmarked date table does not directly cause incorrect numeric results in simple aggregation measures. The failure mode for an unmarked date table is limited to time intelligence functions, not to ordinary measure values shown against a date hierarchy.
- ✗
The fact table is not in a star schema; it is snowflaked.
Why it's wrong here
A snowflake schema normalizes dimension tables into multiple related tables, but in Power BI this is still a valid dimensional model as long as relationships connect the fact table to each dimension (directly or transitively). Filter propagation follows those relationships in a deterministic way, so aggregations like SUM or COUNT are computed correctly; snowflaking may increase query complexity and memory usage, but it does not introduce incorrect measure calculations. A genuine star schema is not a correctness requirement in Power BI, so this option is not a plausible cause of wrong results.
- ✓
The relationship between the date table and the fact table is inactive.
Why this is correct
If the relationship between the date table and the fact table is inactive, the date table's columns will not automatically filter the fact table because an inactive relationship is ignored during normal filter propagation. A visual that uses a date hierarchy from the date table will still display dates, but the measure values will be evaluated without that date context—often showing the grand total or a blend of all dates—so the results appear correct in shape but are numerically wrong. The only way to apply the filter is to explicitly activate the relationship in DAX using USERELATIONSHIP, which the user has evidently not done.
- ✗
The relationship between the date table and the fact table is set to bidirectional cross-filtering.
Why it's wrong here
Bidirectional cross-filtering makes filters flow in both directions between the date table and the fact table, which is the opposite of having an inactive relationship; it actively propagates date filters and is generally not a reason for incorrect measure results. While bidirectional filtering can create ambiguous filter contexts or circular dependency warnings when a model has multiple date columns, a simple fact–dimension relationship with bidirectional filtering still yields the correct filtered totals. Thus, this setting is a modeling design choice, not a direct cause of the described symptom of date-filtered values being wrong.
Go deeper
Related to this question
About these practice questions
Courseiva writes every PL-300 question from scratch — 217 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PL-300 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PL-300 exam.