PL-300 Model the data Practice Question
Which THREE considerations are important when designing a Power BI data model for large datasets?
⚠ Common exam trap
Many candidates think calculated columns in fact tables improve performance (Option A) or that more columns provide flexibility (Option B), but in reality both degrade performance and violate star schema best practices.
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
✓
Disable the auto-date/time feature.
Option C is correct because Power BI's Auto date/time feature creates a hidden calculated date table for every date column, which adds memory overhead and can bloat a large model, so disabling it (via Options or Tabular Editor) keeps the model lean. Option D is correct because a star schema with a central fact table surrounded by dimension tables produces efficient, simple relationships that the VertiPaq engine compresses and queries faster than snowflake or normalized designs. Option E is correct because integer keys consume less memory and compress better than text keys, and integer-to-integer relationships are processed more efficiently during query execution. Option A is not appropriate because calculated columns are stored and compressed in the model, consuming memory and increasing refresh time, so measures or calculated tables should be preferred where possible. Option B is not appropriate because adding unnecessary columns increases model size, hurts compression, and slows processing, so fact tables should contain only the columns needed for analysis.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store calculated columns in the fact table for quick access.
Why it's wrong here
Calculated columns are physically stored row-by-row in the fact table, consuming memory both during refresh and at rest. Because they are evaluated once at load time rather than on demand, they do not accelerate query-time access or aggregations; they merely bloat the model. Use measures for calculations that vary with context, or add computed columns in the dimension or source query if they are truly needed.
- ✗
Include as many columns as possible in fact tables for flexibility.
Why it's wrong here
Cramming every available attribute into the fact table degrades storage compression and forces VertiPaq to scan wider data pages, which slows down every query. Fact tables should be limited to foreign keys, numeric additive measures, and a few degenerate dimension keys; descriptive columns belong in related dimension tables. This aligns with star-schema principles and keeps the model lean and fast.
- ✓
Disable the auto-date/time feature.
Why this is correct
Power BI's auto-date/time feature silently creates hidden date tables for every date column, inflating model size and creating extra relationships that can confuse the report layer. Disabling this option forces you to use an explicit date table, giving you control over data type, granularity, and contiguous date ranges, which improves time-intelligence performance and reduces memory footprint.
- ✓
Use a star schema design.
Why this is correct
A star schema organizes facts in a central table surrounded by conformed dimensions, minimizing join complexity and maximizing the efficiency of filter propagation and aggregation. Power BI's VertiPaq engine thrives on this structure because it reduces cross-filtering and enables better compression on dimension attributes. It also makes DAX calculations easier to write and debug, a fundamental best practice for enterprise models.
- ✓
Use integer keys for relationships instead of text.
Why this is correct
Integer surrogate keys are fixed-width numeric values that VertiPaq can sort, hash, and compress far more efficiently than text strings, which require dictionary encoding that consumes memory and CPU. Using integer keys in relationships reduces the cost of lookup and join operations during query execution and refresh. This is especially critical for large fact tables where every byte matters.
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.