PL-300 Prepare the data Practice Question
Which THREE of the following are best practices for data modeling in Power BI? (Select exactly three.)
⚠ Common exam trap
Many candidates think bi-directional cross-filtering is a safe default (option A) or that calculated columns are always preferable for simplicity (option B), but the exam tests the understanding that these choices degrade performance and model clarity.
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
✓
Create a separate date table for time intelligence functions.
Option C is correct because a dedicated, continuous date table marked as a date table is required for reliable time intelligence functions such as TOTALYTD, SAMEPERIODLASTYEAR, and DATEADD, and it avoids gaps or duplicate dates that break those calculations. Option D is correct because primary key columns in dimension tables are used only for relationship joins, so hiding them from report view keeps the field list clean and prevents report authors from accidentally dragging surrogate keys into visuals. Option E is correct because a star schema with a central fact table surrounded by dimension tables delivers optimal VertiPaq compression, simpler DAX, and faster query performance than snowflaked or flat designs. Option A is not a best practice because bi-directional cross-filtering on all tables creates ambiguous filter paths, hurts performance, and can produce incorrect results; it should be used sparingly and only for specific many-to-many or security scenarios. Option B is not a best practice because calculated columns are computed at refresh, consume memory, and cannot respond to slicer context, whereas measures are evaluated at query time and are the preferred way to store dynamic business logic.
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 bi-directional cross-filtering relationships for all tables.
Why it's wrong here
Bi-directional cross-filtering relationships should be used sparingly because they allow filters to propagate in both directions, which can create ambiguous filter paths, slow down query performance, and produce unexpected row contexts in complex snowflake or multi-table models. This direction is genuinely useful only for specific scenarios such as row-level security or limited many-to-many relationships, not as a blanket default. In a star schema, single-direction cross-filtering from dimension to fact is more predictable and performant.
- ✗
Store calculated logic in calculated columns rather than measures when possible.
Why it's wrong here
Storing logic in calculated columns rather than measures contradicts the Power BI data model best practice of pushing transformation work upstream to Power Query (M) and reserving measures for dynamic, context-aware aggregation. Calculated columns are evaluated during data refresh and consume memory for every row, whereas measures compute only at query time based on slicer and filter context. The option is tempting because calculated columns can simplify DAX for row-level operations like categorisation, which is their legitimate use case when a static column is genuinely needed for filtering or grouping.
- ✓
Create a separate date table for time intelligence functions.
Why this is correct
A separate date table is a best practice because DAX time intelligence functions like DATESYTD, SAMEPERIODLASTYEAR, and TOTALYTD require a continuous, contiguous date range and a table marked as a date table to work reliably. When you mark a dedicated date table, Power BI establishes the necessary relationship and ensures that time-based calculations respect the fiscal year and other custom calendars. Without it, time intelligence can return incorrect results due to missing dates or auto-generated date hierarchies.
- ✓
Hide the primary key columns in dimension tables from report view.
Why this is correct
Hiding primary key columns in dimension tables from report view keeps the field list clean and prevents report creators from accidentally using keys, which have no analytical meaning, in visuals or measures. These columns still remain available to DAX calculations and maintain their role as relationship anchors, so hiding them does not reduce model functionality. This practice reduces confusion and enforces a focus on descriptive attributes and measures rather than raw identifiers.
- ✓
Use a star schema design with fact and dimension tables.
Why this is correct
Star schema design, with fact tables at the center surrounded by dimension tables, is the recommended Power BI modeling approach because it minimizes data redundancy, avoids filtering ambiguity, and optimizes query performance through single-hop relationships. This structure enables correct aggregations by providing clean filter propagation from dimensions to facts and simplifies DAX logic. Departing from star schema, such as using wide flat tables or snowflake designs, can degrade performance and complicate maintenance.
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.