PL-300 Model the data Practice Question
Which THREE of the following are best practices when designing a Power BI data model for performance?
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
✓
Hide columns that are not needed in reports.
Option A is correct because hiding unused columns reduces the model's exposed surface and prevents report authors from accidentally dragging unnecessary fields into visuals, which keeps the VertiPaq engine from scanning and materializing columns that add no analytical value. Option B is correct because bi-directional cross-filtering forces the engine to propagate filter context in both directions, which can create ambiguous filter paths, increase query complexity, and degrade performance; single-direction relationships should be the default unless a specific requirement demands otherwise. Option C is correct because a star schema with dimension and fact tables minimizes relationship hops, keeps filter propagation simple, and lets the VertiPaq engine compress and scan narrow fact tables efficiently, which is the recommended modeling pattern for Power BI performance. Option D is not correct because many-to-many relationships without bridge tables introduce ambiguity and expensive filter propagation; the best practice is to resolve many-to-many with a bridge table and single-direction relationships. Option E is not correct because calculated columns are computed at refresh time and stored in the model, consuming memory and increasing refresh cost, whereas measures are evaluated at query time and are the preferred approach for aggregations in a performant model.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Hide columns that are not needed in reports.
Why this is correct
Marking unused columns as hidden simplifies the report field list and keeps users focused on the required metrics, which lowers the apparent model complexity and reduces the risk of building visuals on irrelevant data. Because hidden columns remain resident in the Tabular engine unless physically removed, this practice works hand-in-hand with deleting never-used columns to actually shrink the model and speed up refresh. It is a core modeling hygiene step that also makes column-level security and role definitions easier to audit.
- ✓
Avoid bi-directional cross-filtering unless necessary.
Why this is correct
Bi-directional cross-filtering makes filter contexts flow from any table to its related tables, but this flexibility comes at a cost: the DAX query optimizer must evaluate multiple relationship paths, and the storage engine can lose the ability to use efficient semi-join reductions, leading to slower queries and possible ambiguous aggregation results. Unless a calculation genuinely requires filters to flow both ways—for example, when using a bridge table in a many-to-many pattern—you should keep relationships single-directional from dimension to fact. Restricting bi-directional filtering to specific measures with CROSSFILTER is a safer way to get that behavior only where needed.
- ✓
Use star schema design with dimension and fact tables.
Why this is correct
Arranging tables into a star schema means each dimension is denormalized around a central fact table, which lets the VertiPaq engine achieve better column compression and reduces the number of joins needed during query time. Because every relationship follows a clear one-to-many path from a unique dimension key to a foreign key in the fact table, DAX filter propagation is deterministic and fast, avoiding the ambiguity of looping or snowflake relationships. This design is the performance foundation of a well-built Power BI model and is what the exam expects for most enterprise scenarios.
- ✗
Use many-to-many relationships directly without bridge tables.
Why it's wrong here
Creating a direct many-to-many relationship without a bridge table forces the engine to resolve ambiguous joins between two non-unique key columns, which can cause row inflation and unpredictable totals in visuals. In Power BI, a many-to-many cardinality is only supported in specific modeling scenarios (for example, when both tables have non-unique keys but a bridge table is absent); it should still be avoided because the query plan cannot guarantee correct aggregate results. The recommended pattern is to introduce a bridge table that splits the many-to-many into two one-to-many relationships, preserving deterministic filter semantics and making performance easier to control.
- ✗
Use calculated columns instead of measures for aggregations.
Why it's wrong here
Calculated columns are evaluated at data refresh time and stored in memory, increasing model size and slowing refresh, whereas measures are evaluated at query time and do not consume storage. This fails the performance goal because aggregations in measures avoid unnecessary memory overhead and recalculate only when needed. It is tempting because calculated columns are useful for row-level static categorisation or creating relationships, where pre-computed values are required before any user interaction.
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.