PL-300 Domain 2: Model the data (25-30%) - Complete Study Guide 2026

Domain 2 Overview: What "Model the Data" Actually Covers

Domain 2, Model the data, sits at 25-30% of the PL-300 exam - statistically tied with Prepare the data and Visualize and analyze the data for the heaviest weighting in the entire skills outline (dated April 20, 2026). Unlike Domain 1, which is largely about getting data into Power BI cleanly, this domain asks whether you can design a model that behaves correctly once it's there. That distinction matters because the exam tests reasoning, not just tool familiarity: you'll be shown a model diagram or a DAX snippet and asked to identify what's wrong or what's missing.

If you haven't already mapped out how this domain fits with the other three, read the complete guide to all four PL-300 content areas first - it gives useful context for why Microsoft groups modeling separately from data preparation and visualization.

Star Schema and Relationships

A large share of Domain 2 questions revolve around a single design pattern: the star schema. You need to recognize it, build it, and defend design choices around it - not just define it.

Expect exam items that test relationship mechanics directly:

• Cardinality: one-to-one, one-to-many, many-to-many - and when each is appropriate
• Cross-filter direction: single vs. bidirectional, and the performance/ambiguity risks of bidirectional filtering
• Active vs. inactive relationships: using USERELATIONSHIP in DAX to activate an inactive relationship for a specific calculation
• Composite models: combining Import and DirectQuery tables, and understanding storage mode implications

DAX Fundamentals You Must Master

DAX is the single biggest differentiator in Domain 2. The exam assumes you're already "proficient with Power Query and DAX" per Microsoft's own prerequisites guidance - there's no beginner on-ramp built into the questions.

Measures vs. Calculated Columns vs. Calculated Tables

You'll be tested on choosing the right calculation type for a given scenario:

• Measures are calculated at query time and respond to filter context - use them for anything that should change based on slicers, visuals, or filters
• Calculated columns are computed at refresh and stored in the model - use them when you need a static row-level value, such as a category label
• Calculated tables generate entire new tables, often used for date tables or bridge tables built with DAX rather than Power Query

Core Function Families to Know Cold

• Aggregation: SUM, AVERAGE, COUNTROWS, DISTINCTCOUNT
• Filter modification: CALCULATE, FILTER, ALL, ALLEXCEPT, REMOVEFILTERS
• Iterators: SUMX, AVERAGEX, RANKX - and why row context differs from filter context
• Relationship functions: RELATED, RELATEDTABLE, USERELATIONSHIP
• Logical/conditional: IF, SWITCH, and nested variable use with VAR/RETURN for readability

Time Intelligence and Calculation Groups

Time-based analysis is a near-guaranteed topic. You need a proper date table and fluency with time intelligence functions.

Newer skills outlines also emphasize calculation groups and field parameters as ways to reduce measure duplication - expect at least conceptual recognition of why calculation groups exist (to avoid writing separate YTD/QTD/PY versions of every measure) even if deep implementation isn't heavily tested.

Row-Level Security and Model Performance

Row-level security (RLS) design decisions live conceptually in Domain 2 even though enforcement and administration are covered more fully under Domain 4: Manage and secure Power BI. On the modeling side, you're expected to know how to write DAX filter expressions for roles and understand static vs. dynamic RLS.

• Static RLS: hardcoded filter expressions per role (e.g., Region = "West")
• Dynamic RLS: using USERNAME() or USERPRINCIPALNAME() joined against a permissions table so one role serves many users

Performance optimization is the other half of this section. Expect questions about reducing model size and improving refresh/query speed:

• Removing unnecessary columns and rows before loading (better done in Power Query, but tested here as a modeling concern)
• Using integers/whole number keys for relationships instead of text
• Disabling auto date/time hierarchies to reduce hidden table bloat
• Choosing Import vs. DirectQuery vs. Dual storage mode based on data volume and refresh needs
• Using Performance Analyzer to identify slow visuals or DAX expressions

These modeling decisions have real career weight - teams that hire for Power BI roles specifically screen for candidates who can design efficient, secure models, which is part of why this credential appears so often in analyst and BI job postings. See the PL-300 jobs overview and the salary guide for how modeling skills translate into role expectations.

How Domain 2 Questions Are Actually Asked

Domain 2 questions tend to be less "definition recall" than Domain 1 and more "diagnose the model." The exam runs 100 minutes across roughly 40-60 items, including case studies, so pacing matters - Domain 2 items often take longer to read because they include a relationship diagram, a DAX formula, or both.

• Scenario diagnosis: "A measure returns an incorrect total when sliced by Region. What is the most likely cause?" - tests filter context understanding
• Formula completion: selecting the correct DAX function or argument to complete a stated business requirement
• Design justification: choosing between a calculated column and a measure for a described use case
• Model diagram interpretation: identifying which relationship should be made inactive or bidirectional based on described symptoms

Case study sections may present a broader business scenario and ask several Domain 2 questions against the same fictional dataset - read the scenario once carefully rather than skimming, since later questions often depend on details established early.

A Focused Study Sequence for Domain 2

Rather than a generic weekly template, sequence your Domain 2 prep around dependency: relationships before DAX, DAX before time intelligence, time intelligence before security/performance.

Once this domain feels solid, revisit the full PL-300 study guide to see how Domain 2 prep fits alongside the other three domains in a complete first-attempt plan, and cross-check your readiness against the Domain 1 study guide since clean data prep directly affects how easy your modeling work will be.

How Domain 2 Compares to the Other PL-300 Domains

Because Domain 2 feeds directly into Domain 3 - visuals are only as good as the measures behind them - many candidates study these two together. If you're mapping out that connection, the Domain 3 study guide picks up exactly where model-building leaves off.

You can also run timed practice covering all four domains together on our PL-300 practice test platform to see how your Domain 2 accuracy compares to the other three before exam day.

FAQ: PL-300 Domain 2