PL-300 Visualize and analyze the data Practice Question
You are designing a Power BI report for executives. The dataset contains sales data with a many-to-many relationship between 'Sales' and 'Product' tables via a 'ProductSales' bridge table. Users complain that some measures return incorrect totals when using multiple related fields. What is the most likely cause?
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 many-to-many relationship is causing ambiguity in measure evaluation
The many-to-many relationship is causing ambiguity in measure evaluation. In a bridge-table (ProductSales) many-to-many model, a single fact row can be reached through multiple product paths, so measures like SUM over Sales can be double-counted or misallocated when users slice by multiple related fields, producing incorrect totals. This is a classic DAX/modeling ambiguity that requires resolving the relationship (e.g., proper bridge filtering or distinct-count logic) rather than a simple setting change. Option B is unlikely because key data type mismatches would typically block relationship creation or cause blanks, not selective wrong totals. Option C is not the root cause, since single vs. both cross-filter direction affects filter propagation but does not by itself create the many-to-many double-counting ambiguity. Option D is unrelated, as RLS would consistently hide rows for restricted users, not produce incorrect aggregate totals for executives with full access.
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 many-to-many relationship is causing ambiguity in measure evaluation
Why this is correct
A many-to-many relationship (for example, via a bridge table) does not provide a unique path for filter propagation between the two tables. When a measure evaluates a total, the storage engine must apply filters to both sides of the relationship, but because multiple rows can match on either side, the filter context becomes ambiguous and the engine may include duplicate or omitted rows. As a result, the detail rows for each record can appear correct, but the aggregated total becomes inflated or deflated because the same underlying row is counted multiple times or not at all. This ambiguity is a known limitation of many-to-many model relationships and directly explains incorrect totals.
- ✗
Data type mismatches between key columns
Why it's wrong here
Data type mismatches between the key columns would prevent Power BI from creating the relationship at all, because the engine cannot join a numeric key to a text key without implicit coercion. Even if the mismatch is subtle (such as integer versus decimal), the relationship creation would fail or require you to fix the column types before the model can be used for reporting. A report that already functions with valid relationships, producing visible detail values, could not have an underlying type mismatch. Thus, while type mismatches cause errors, they cannot be the cause of incorrect totals in an otherwise working report.
- ✗
The cross-filter direction is set to single instead of both
Why it's wrong here
Setting a cross-filter direction to single instead of both limits the direction in which filters can travel across the relationship, but it does not introduce ambiguity in measure evaluation. With a single direction, filters simply do not propagate from one table to the other, so a related table might remain unfiltered—leading to a broader result set rather than a mathematically inconsistent total. Moreover, in a many-to-many relationship, making the cross-filter direction bidirectional can itself generate ambiguity, which is why Power BI often restricts or warns about it. Therefore, a single-direction setting is not the explanation for incorrect totals.
- ✗
Row-level security (RLS) is filtering out some rows
Why it's wrong here
Row-level security (RLS) applies a DAX filter predicate to every query that runs against the model, so it reduces the rows visible to a user uniformly across all measures and visuals. If RLS were filtering out rows, the total would be composed of the remaining permitted rows, and all other metrics (counts, averages, percentages) would be consistently based on that same restricted set. It would not cause some numbers to be correct and others to be subtly wrong, nor would it create values that exceed the plausible sum of the visible rows. RLS is a security boundary, not a logic error, and it cannot explain a discrepancy limited to totals.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 524 original PL-300 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.