PL-300 Model the data Practice Question
Which THREE of the following are best practices for designing a Power BI data model?
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
✓
Implement business logic in measures rather than calculated columns
Option C is correct because measures are evaluated at query time and do not consume memory or storage in the model, whereas calculated columns are materialized during refresh, increasing model size and refresh time; pushing business logic into measures therefore improves performance and flexibility. Option D is correct because a star schema with dimension and fact tables is the recommended Power BI modeling pattern: it produces simpler relationships, more efficient DAX and VertiPaq compression, and better query performance than snowflaked or flat designs. Option E is correct because surrogate keys (meaningless integer keys) in dimension tables keep relationships narrow and integer-based, which compresses better and performs faster than natural or string keys, and they insulate the model from changes in source business keys. Option A is not a best practice because composite keys in relationships are not supported for all cardinalities and generally add complexity and overhead; a single surrogate key is preferred. Option B is not a best practice because bidirectional cross-filtering by default can introduce ambiguous filter paths, degrade performance, and cause unexpected results; it should be enabled only when a specific requirement demands it.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use composite keys in relationships for better performance
Why it's wrong here
Composite keys in relationships require multiple columns to join tables, which increases the size of the relationship index and adds complexity to query resolution. This often degrades performance because Power BI must evaluate and match every key column on each row, and any change to one of the key columns forces a re-evaluation of the relationship. In contrast, a single-column surrogate key provides a smaller, more efficient join key and avoids the risk of ambiguous matches.
- ✗
Enable bidirectional cross-filtering by default
Why it's wrong here
Enabling bidirectional cross-filtering by default is a common anti-pattern because it lets a filter on one table flow through to another table and then back again, which can create multiple, conflicting filter paths. This ambiguity often leads to inaccurate results, especially when multiple fact tables or many-to-many relationships are involved, and it can significantly slow down query execution. You should enable this feature only when a specific business requirement demands it, typically combined with CALCULATETABLE or CROSSFILTER functions to control the flow.
- ✓
Implement business logic in measures rather than calculated columns
Why this is correct
Measures are evaluated within the current filter context at query time, so they compute values dynamically and consume no physical memory for storage beyond their definition. Calculated columns, on the other hand, are computed during data refresh and stored in the model, increasing model size and refresh time. By implementing business logic in measures, you gain greater flexibility—logic can change without triggering a full refresh, and the same measure can respond differently based on how users filter or slice data, which is the intended DAX pattern.
- ✓
Use a star schema design with dimension and fact tables
Why this is correct
A star schema organizes a model into fact tables that contain measurable numeric data and dimension tables that hold descriptive attributes, with each dimension linked to the fact table by one-to-many relationships. This design minimizes redundant data, aligns with how DAX and the VertiPaq engine optimize queries, and makes filters and aggregations faster and easier to author. It also eliminates the complexities of normalized schemas (which would require many joins) and supports intuitive, performant calculations for end users.
- ✓
Use surrogate keys for dimension tables
Why this is correct
Surrogate keys are single-column, system-generated unique identifiers (often integers) used as primary keys in dimension tables. Because they are independent of business keys, they remain stable even when source data changes, and they let you avoid composite relationships that require multiple join columns. In Power BI, using a surrogate key creates a simpler and more efficient relationship, improves query performance by reducing index complexity, and ensures each dimension row is uniquely identifiable, which is critical for accurate row-level joins.
Go deeper
Related to this question
About these practice questions
This PL-300 question is part of Courseiva's 524-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.