PL-300 Model the data Practice Question
Exhibit
Refer to the exhibit.
```json
{
"relationships": [
{
"fromTable": "Sales",
"fromColumn": "ProductID",
"toTable": "Product",
"toColumn": "ProductID",
"crossFilteringBehavior": "oneDirection"
},
{
"fromTable": "Sales",
"fromColumn": "CustomerID",
"toTable": "Customer",
"toColumn": "CustomerID",
"crossFilteringBehavior": "oneDirection"
},
{
"fromTable": "Product",
"fromColumn": "CategoryID",
"toTable": "Category",
"toColumn": "CategoryID",
"crossFilteringBehavior": "both"
}
]
}
```You are reviewing the relationships in a Power BI data model as shown in the exhibit. The model has tables: Sales, Product, Customer, and Category. You need to evaluate the performance impact of the current configuration. Which relationship is most likely to cause performance issues?
⚠ Common exam trap
Many exam-takers assume all relationships are equally performant if they are correctly defined, overlooking that many-to-many cardinality inherently requires more complex processing than one-to-many relationships.
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 Product and Category
The relationship between Product and Category is most likely to cause performance issues because it is a many-to-many relationship without a bridge table. In Power BI, many-to-many relationships require the engine to materialize cross-join-like intermediate tables in memory, increasing query complexity and reducing performance. This is especially problematic when filtering or aggregating across these tables, as the VertiPaq engine must resolve ambiguity by creating additional internal tables.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
All relationships are equally efficient
Why it's wrong here
This is incorrect because relationship efficiency is directly affected by filter direction and cardinality. Unidirectional relationships are generally cheaper than bidirectional ones, which require the storage engine to propagate filters in both directions, raising query processing cost. Additionally, a relationship's status as active/inactive and its cardinality (one-to-many vs. many-to-many) further change performance. Therefore, the Product–Category bidirectional relationship is clearly less efficient than the unidirectional relationships in this model, disproving the idea that all relationships perform equally.
- ✗
The relationship between Sales and Customer
Why it's wrong here
The Sales-to-Customer relationship is a conventional many-to-one relationship with unidirectional cross-filtering, so filters flow only from Customer to Sales without any reverse propagation. This directionality is computationally efficient because the engine doesn't need to traverse back-reference paths or maintain extra join indexes. In normal reporting, there is no need for Sales to filter Customer, so this relationship doesn't introduce ambiguity or slowdown. Hence, it is not the relationship causing performance concerns in this scenario.
- ✓
The relationship between Product and Category
Why this is correct
This is the correct answer because this relationship is the one configured with bidirectional filtering, a configuration known to degrade query performance. With bidirectional cross-filtering, a filter on Category flows to Product and then to Sales, but also filters on Product or Sales can propagate back to Category, causing extra dependency chains and potential ambiguity in filter context. This forces the query engine to evaluate additional row combinations and can make the model significantly less responsive. In contrast to unidirectional relationships, this bidirectional flow creates unnecessary complexity, so the Product–Category relationship is the least efficient.
- ✗
The relationship between Sales and Product
Why it's wrong here
The Sales-to-Product relationship is unidirectional, meaning Product filters Sales but not the other way around, and that is the standard, efficient design. It doesn't directly cause performance issues because the engine only has to follow a simple many-to-one lookup path. The real bottleneck appears upstream, where the Product-to-Category relationship is bidirectional; that relationship causes filters to bounce back and forth and cascades into the Sales table. So even though Sales–Product participates in the filter chain, the inefficiency originates from the Product–Category relationship, making this option incorrect.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 217 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.