Describe an analytics workload on Azure →hardMultiple ChoiceObjective-mapped

DP-900 Describe an analytics workload on Azure Practice Question

Exhibit

{
  "version": "1.0",
  "aggregations": [
    {
      "table": "Sales",
      "measure": "SUM(Amount)",
      "dimensions": ["ProductCategory", "Region", "Date"],
      "aggregationLevel": "Monthly"
    }
  ]
}

Refer to the exhibit. An administrator is configuring aggregations in Power BI Premium to improve performance on a large dataset. The aggregation is defined on the Sales table with SUM(Amount) grouped by ProductCategory, Region, and Date at the monthly level. However, some reports that query daily data are still slow. What is the most likely reason?

⚠ Common exam trap

It's easy for candidates to think aggregations automatically speed up all queries on a table, but they must match the exact granularity of the query; otherwise, the aggregation is ignored and the full dataset is scanned.

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

✓

The aggregation level is monthly, but queries need daily granularity

The aggregation is defined at the monthly level (grouping by month), but the slow reports are querying daily data. Power BI aggregations work by pre-aggregating data at a specified granularity; when a query requests a lower level of detail (daily), the aggregation cannot satisfy the query, so Power BI falls back to scanning the full detailed dataset, causing slow performance. To improve daily queries, an additional aggregation at the daily level would be needed.

Answer analysis

Option-by-option breakdown

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

✗
The dataset is too large for aggregations
Why it's wrong here
Aggregations are a performance feature explicitly designed for large datasets, pre-summarizing data to reduce query load. Dataset size alone does not prevent an aggregation from being created or used; rather, large datasets often benefit the most from aggregations. The real problem is a grain mismatch, not data volume. Therefore, this statement incorrectly identifies size as the blocker.
✗
The aggregation is not in DirectQuery mode
Why it's wrong here
Aggregations in Power BI can be configured for both import and DirectQuery storage modes; DirectQuery is not a prerequisite for using aggregations. The mode determines how data is stored and queried, but it does not determine whether an aggregation's granularity matches query requirements. Since the issue is that daily queries cannot leverage a monthly aggregation, the storage mode is irrelevant to this failure.
✓
The aggregation level is monthly, but queries need daily granularity
Why this is correct
When an aggregation is built at the monthly grain, any query that filters or groups by date at the daily level cannot be satisfied by that aggregation because the daily detail rows are not preserved. Power BI must then fall back to querying the full detail table, which defeats the purpose of the aggregation and causes poor performance. The aggregation level must match or be a rollup of the query granularity to be used.
✗
The aggregation has too many dimensions
Why it's wrong here
The number of dimensions in an aggregation affects its size and potential to answer queries, but a high dimension count does not prevent an aggregation from being used; it may just reduce compression. The core issue described is a granularity mismatch—monthly vs daily—not the count of dimensions. Thus, this misdiagnoses the cause because dimension count and aggregation grain are separate design considerations.

Go deeper

DP-900 Describe an analytics workload on Azure Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question