Model the data →mediumMultiple ChoiceObjective-mapped

PL-300 Model the data Practice Question

Exhibit

Refer to the exhibit.
```json
{
  "tables": [
    {
      "name": "Sales",
      "columns": [
        {"name": "OrderID", "dataType": "int"},
        {"name": "OrderDate", "dataType": "datetime"},
        {"name": "Amount", "dataType": "decimal"}
      ],
      "partitions": [
        {
          "name": "Partition1",
          "source": {
            "type": "m",
            "expression": "let Source = Sql.Database(\"server\", \"db\"), Sales = Source{[Schema=\"dbo\",Item=\"Sales\"]}[Data], FilteredRows = Table.SelectRows(Sales, each [OrderDate] >= #datetime(2020,1,1) and [OrderDate] < #datetime(2021,1,1)) in FilteredRows"
          }
        },
        {
          "name": "Partition2",
          "source": {
            "type": "m",
            "expression": "let Source = Sql.Database(\"server\", \"db\"), Sales = Source{[Schema=\"dbo\",Item=\"Sales\"]}[Data], FilteredRows = Table.SelectRows(Sales, each [OrderDate] >= #datetime(2021,1,1) and [OrderDate] < #datetime(2022,1,1)) in FilteredRows"
          }
        }
      ]
    }
  ]
}
```

You are reviewing the partition configuration for a Power BI Import model as shown in the exhibit. The table Sales is partitioned by year. You need to modify the model to improve incremental refresh performance. What change should you make?

⚠ Common exam trap

It's easy for candidates to think increasing partition count (Option A) always improves performance, but in Power BI, too many partitions increase metadata overhead and refresh orchestration time, making incremental refresh policies the correct solution for efficient, automated partition management.

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

✓

Configure incremental refresh policy

Configuring an incremental refresh policy (Option B) is the correct approach because it automatically manages partition creation and refresh for the Sales table based on a date/time column. This improves performance by refreshing only the most recent data (e.g., last 5 years) while keeping historical partitions unchanged, reducing refresh time and resource consumption compared to manual yearly partitions.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Increase the number of partitions to monthly
Why it's wrong here
Simply increasing the number of partitions to monthly does not automatically improve refresh performance. In Power BI, partitions are primarily managed by the incremental refresh feature; manually creating monthly partitions through the XMLA endpoint adds complexity and metadata overhead, yet without an incremental refresh policy, a full refresh will still reprocess all data each time, canceling any potential benefit. Moreover, excessive partitioning can degrade query performance due to increased metadata management and maintenance tasks rather than optimizing it.
✓
Configure incremental refresh policy
Why this is correct
Configuring an incremental refresh policy is the correct approach because it automatically creates and manages partitions based on a date range, typically using RangeStart and RangeEnd parameters. During each refresh, only the data that has changed or is new within the sliding window is processed, while historical partitions remain untouched, significantly reducing refresh time and resource consumption. This also enables query pruning in the Power BI service, as only relevant partitions are scanned when building visuals, making it the most efficient way to optimize refresh performance for large fact tables.
✗
Remove all partitions and load data as a single table
Why it's wrong here
Removing all partitions and loading the data as a single table forces Power BI to perform a full refresh of the entire dataset on every scheduled refresh. This dramatically increases refresh duration and data load because there is no mechanism to isolate recent changes or historical data, meaning every row is re-read and reprocessed. Even if the table is moderately large, the absence of partition pruning raises memory pressure and query latency, making this option counterproductive for any scenario requiring efficient refreshes.
✗
Change the storage mode to DirectQuery
Why it's wrong here
Changing the storage mode to DirectQuery does not improve refresh performance; it eliminates the need to refresh imported data but introduces major trade-offs. DirectQuery issues live queries to the underlying source, making query performance dependent on source-system indexing and network latency, and it loses the in-memory compression and highly optimized query engine that import mode provides. This option changes the data-access strategy entirely rather than addressing partition configuration, and it requires a stable source connection, making it unsuitable as a solution for optimizing scheduled data refreshes.

Go deeper

PL-300 Model the data Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question