PL-300 Model the data Practice Question
Which TWO of the following are best practices when 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
✓
Use a star schema design
Option B is correct because a star schema — a central fact table surrounded by dimension tables — is the recommended Power BI model design: it produces simpler DAX, better compression, and faster query performance than snowflaked or flat models. Option E is correct because foreign key columns in dimension tables are implementation details used only for relationship joins; hiding them from report view keeps the field list clean and prevents report authors from accidentally grouping or filtering by meaningless surrogate keys. Option A is wrong because measures (evaluated at query time, not stored) are generally preferred over calculated columns, which consume memory and are computed during refresh. Option C is wrong because collapsing everything into one flat table causes massive redundancy, poor compression, and slow aggregations. Option D is wrong because bidirectional relationships can introduce ambiguity and unexpected filter propagation; they should be used sparingly and only when a specific cross-filtering requirement demands it, not as the default.
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 calculated columns instead of measures
Why it's wrong here
Calculated columns are evaluated row-by-row during data refresh and consume memory within the table, whereas measures are evaluated at query time and aggregate dynamically based on slicer context. This option fails because the scenario requires dynamic aggregation that adapts to user filters—calculated columns cannot respond to runtime filter changes. It is tempting because calculated columns are useful for static row-level categorisation or creating new dimension attributes when no measure logic is needed.
- ✓
Use a star schema design
Why this is correct
A star schema design organizes data into dimension and fact tables, creating a hub-and-spoke structure that simplifies relationships and enables efficient query performance. By separating descriptive attributes from numeric measures, the model becomes intuitive for business users and allows DAX to filter and aggregate correctly across one-to-many relationships. This is the recommended practice because it balances normalization with usability, reduces model complexity, and ensures that filters propagate predictably from dimensions to facts, which is essential for dynamic reporting.
- ✗
Denormalize all tables into a single flat table
Why it's wrong here
Denormalizing all tables into a single flat table creates massive data redundancy, causing the model to bloat and refresh times to spike. With no separate dimension tables, hierarchies and shared relationships are lost, making it impossible to maintain consistent attributes like a customer's region or product category across multiple facts. The lack of a star schema also forces slicer filters to over-filter rows, leading to incorrect aggregations and discouraging the reuse of dimensions across various business processes.
- ✗
Use bidirectional relationships as default
Why it's wrong here
Setting bidirectional cross-filtering as the default behavior means every relationship filters in both directions, which multiplies the number of filter paths DAX must evaluate. This can cause severe performance degradation and ambiguous results when multiple tables are related in complex patterns, as the filter context may unexpectedly propagate to unrelated tables. Best practice is to keep single-direction filters unless a specific, rare requirement demands bidirectional filtering, then enable it only on the needed relationship and fully test the impact.
- ✓
Hide foreign key columns from report view
Why this is correct
Hiding foreign key columns from the report view hides the granular ID fields that are technical keys used solely to join tables, not to answer business questions. Leaving them visible clutters the field list and confuses users who might drag them onto visuals or create unintended filters. Hidden columns remain fully functional in relationships and DAX calculations, so hiding them improves report usability without sacrificing analytical capability and also reduces the risk of users misinterpreting cryptic numeric identifiers.
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.