How should I use these Visualize and analyze the data practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

Can I practise just Visualize and analyze the data questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Visualize and analyze the data domain.

PL-300 · topic practice

Visualize and analyze the data practice questions

This domain covers building and refining Power BI report visuals: choosing the right visual type, configuring fields and formatting, enabling interactions like highlighting and filtering, and fixing geocoding so maps render correctly. Questions are scenario-based, asking you to pick the correct visual, feature, or configuration step to solve a stated reporting problem.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Editorial oversight:Johnson Ajibi· MSc IT Security, IEEE Senior Member

20 questionsDomain: Visualize and analyze the data

Practice 10 questions Browse domain →

What the exam tests

What to know about Visualize and analyze the data

You must be able to choose the correct visual for a scenario, add and configure slicers or custom visuals, and control how visuals interact. The most important thing is matching the visual and its configuration to the analytical question, especially setting correct geographic data categories for maps.

Selecting appropriate visual types, such as scatter charts for correlation and line charts for trends

Importing custom visuals from the marketplace or an organizational visual file

Configuring slicers and cross-highlighting so selections filter or highlight other visuals

Setting geographic data categories and fixing ambiguous place names for accurate map geocoding

Watch out for

Common Visualize and analyze the data exam traps

▸Choosing a column or pie chart for correlation when a scatter chart is the correct visual for two numeric measures
▸Assuming a slicer filters only its own visual instead of filtering or highlighting related visuals on the page
▸Leaving geography columns as text without assigning a data category, causing maps to misplace or drop locations

Practice set

Visualize and analyze the data questions

20 questions · select your answer, then reveal the explanation

Question 1mediummultiple choice

Read the full Visualize and analyze the data explanation →

A Power BI report uses a measure that calculates Year-over-Year sales growth. Users report that the measure shows incorrect values for January 2024 when compared to January 2023. The data model contains a Date table with a continuous date range from January 1, 2020 to December 31, 2024. Which DAX function is most likely causing the issue?

Trap 1: DATEADD

DATEADD('Date'[Date], -1, YEAR) shifts each selected date by exactly 365 or 366 days, preserving individual date values rather than calendar month boundaries. While this can work for daily or continuous data, a month-level visual may show mismatched day-to-day alignment, such as comparing February/2024 with February/2023, and any missing dates in the Date table become excluded from the result. Since the report is measuring the same period last year, DATEADD is less likely to be the root cause when the expected behavior is calendar-month alignment.

Trap 2: SAMEPERIODLASTYEAR

SAMEPERIODLASTYEAR is the most likely cause because it returns the same period from the previous year, but if the Date table lacks data for the entire previous period, it can produce incorrect results for month-over-month comparisons.

Trap 3: PREVIOUSYEAR

PREVIOUSYEAR('Date'[Date]) entirely ignores the active month or quarter filter and returns all dates from January 1 to December 31 of the prior year. In a month-level visual, this means each row would receive the same full-year previous-year value, so the year-over-year calculation would compare a single month to a sum of twelve months. That behavior is clearly incompatible with the required same-period comparison, making it an unlikely cause when the symptom is inconsistent month-over-month differences.

Study all Visualize and analyze the data common traps →

A
PARALLELPERIOD
PARALLELPERIOD('Date'[Date], -1, YEAR) does not preserve the current filtering granularity; it shifts the entire set of dates to the previous full year at the level defined by the period argument. When the visual is filtered to a single month, this function returns the whole previous year, not the same month one year earlier, so the measure would produce an inflated year-over-year total. Thus it is an incorrect choice for a same-period comparison.
B
DATEADD
Why it fails: DATEADD('Date'[Date], -1, YEAR) shifts each selected date by exactly 365 or 366 days, preserving individual date values rather than calendar month boundaries. While this can work for daily or continuous data, a month-level visual may show mismatched day-to-day alignment, such as comparing February/2024 with February/2023, and any missing dates in the Date table become excluded from the result. Since the report is measuring the same period last year, DATEADD is less likely to be the root cause when the expected behavior is calendar-month alignment.
C
SAMEPERIODLASTYEAR
Why it fails: SAMEPERIODLASTYEAR is the most likely cause because it returns the same period from the previous year, but if the Date table lacks data for the entire previous period, it can produce incorrect results for month-over-month comparisons.
D
PREVIOUSYEAR
Why it fails: PREVIOUSYEAR('Date'[Date]) entirely ignores the active month or quarter filter and returns all dates from January 1 to December 31 of the prior year. In a month-level visual, this means each row would receive the same full-year previous-year value, so the year-over-year calculation would compare a single month to a sum of twelve months. That behavior is clearly incompatible with the required same-period comparison, making it an unlikely cause when the symptom is inconsistent month-over-month differences.

Full breakdown with real-world context →

Question 2mediummulti select

Read the full Visualize and analyze the data explanation →

A Power BI report includes a slicer for 'Year' and a line chart showing monthly sales. The report designer wants to ensure that when a user selects a year in the slicer, the line chart shows only the months of that year, with month names on the x-axis sorted chronologically. Which TWO actions must be taken?

Trap 1: Create a date hierarchy with Year and Month.

Creating a date hierarchy with Year and Month is unnecessary here because the slicer and line chart can use separate Year and Month columns directly. Hierarchies are only a convenience for drill-down, not a solution for data modeling or time-intelligence issues. Adding a hierarchy does not affect how Power BI interprets dates or sorts months, so it leaves the underlying problem unresolved.

Trap 2: Set the slicer to 'Single select' mode.

The slicer's single-select mode is a user-facing interaction option only; it does not alter the data model or how the underlying date table is processed. Whether the slicer allows one or multiple selections, the year filtering still works correctly. Since the issue is likely related to the date table being unrecognized, changing the slicer mode has no impact on the correctness of the visual.

Trap 3: Hide the Month column in the Date table.

Hiding the Month column in the Date table would make it unavailable in the field list, preventing the line chart from using it as an axis field. This action does not fix any date-table configuration issue; it removes a field that is essential to the visual you are trying to display. Hiding only affects field visibility, not filter behavior or time intelligence, so it would break the report rather than repair it.

Study all Visualize and analyze the data common traps →

A
Mark the Date table as a date table in the model.
Marking the Date table as a date table is a mandatory modeling step for time intelligence functions such as TOTALYTD, SAMEPERIODLASTYEAR, and DATESINPERIOD. This designation tells Power BI which column is the unique date key, ensuring that DAX date calculations and slicers behave consistently across the model. Without this, the line chart and year slicer may filter unpredictably, and time-intelligence measures return incorrect results.
B
Create a date hierarchy with Year and Month.
Why it fails: Creating a date hierarchy with Year and Month is unnecessary here because the slicer and line chart can use separate Year and Month columns directly. Hierarchies are only a convenience for drill-down, not a solution for data modeling or time-intelligence issues. Adding a hierarchy does not affect how Power BI interprets dates or sorts months, so it leaves the underlying problem unresolved.
C
Set the slicer to 'Single select' mode.
Why it fails: The slicer's single-select mode is a user-facing interaction option only; it does not alter the data model or how the underlying date table is processed. Whether the slicer allows one or multiple selections, the year filtering still works correctly. Since the issue is likely related to the date table being unrecognized, changing the slicer mode has no impact on the correctness of the visual.
D
Set the 'Sort by Column' property for Month to a numeric month number column.
Setting the 'Sort by Column' property for the Month name to a numeric month number (1–12) is essential because Power BI defaults to alphabetical sorting, which would display months as April, August, December, etc. Without this property, the line chart's x-axis would be chronologically wrong, obscuring trends. This sorting is independent of marking the table as a date table and must be configured separately for any month-name column used in a visual.
E
Hide the Month column in the Date table.
Why it fails: Hiding the Month column in the Date table would make it unavailable in the field list, preventing the line chart from using it as an axis field. This action does not fix any date-table configuration issue; it removes a field that is essential to the visual you are trying to display. Hiding only affects field visibility, not filter behavior or time intelligence, so it would break the report rather than repair it.

Full breakdown with real-world context →

Question 3hardmulti select

Read the full Visualize and analyze the data explanation →

A company has a Power BI dataset that includes a table 'Orders' with columns: OrderID, CustomerID, OrderDate, ShipDate, and Amount. They want to create a measure that calculates the number of orders shipped within 3 days of the order date. Which THREE of the following steps are necessary to create this measure?

Trap 1: Use COUNTROWS without any filter.

COUNTROWS with no arguments (or COUNTROWS(Orders)) evaluates the entire Orders table with no row restriction, so it returns the total number of orders, including those shipped after more than 3 days. This ignores the core business requirement of isolating the fast-shipping subset. Because the measure must respect the date-difference condition, an unfiltered COUNTROWS is fundamentally incorrect and will always overcount.

Trap 2: Use SUM to add up the Amount column.

SUM(Orders[Amount]) adds up the numeric values in the Amount column, producing a total dollar amount rather than a count of orders. Even if you wrapped this SUM in a FILTER or CALCULATE, you would still be aggregating money, not counting rows. The question asks for 'the number of orders' (a cardinality), so a counting function like COUNTROWS or COUNT is required; SUM is semantically mismatched.

Study all Visualize and analyze the data common traps →

A
Use FILTER to filter the Orders table based on the condition.
FILTER is required because it iterates over the Orders table in row context, evaluating the shipping-time condition (e.g., DATEDIFF(ShipDate, OrderDate, DAY) <= 3) for each row and returning only the matching rows. This filtered table can then be passed to COUNTROWS to produce the correct scalar count. Without FILTER (or an equivalent CALCULATE filter), there is no way to restrict the rows to those shipped within 3 days.
B
Use COUNTROWS without any filter.
Why it fails: COUNTROWS with no arguments (or COUNTROWS(Orders)) evaluates the entire Orders table with no row restriction, so it returns the total number of orders, including those shipped after more than 3 days. This ignores the core business requirement of isolating the fast-shipping subset. Because the measure must respect the date-difference condition, an unfiltered COUNTROWS is fundamentally incorrect and will always overcount.
C
Use SUM to add up the Amount column.
Why it fails: SUM(Orders[Amount]) adds up the numeric values in the Amount column, producing a total dollar amount rather than a count of orders. Even if you wrapped this SUM in a FILTER or CALCULATE, you would still be aggregating money, not counting rows. The question asks for 'the number of orders' (a cardinality), so a counting function like COUNTROWS or COUNT is required; SUM is semantically mismatched.
D
Use COUNTROWS inside CALCULATE.
CALCULATE(COUNTROWS(Orders), condition) is the idiomatic DAX pattern for counting rows that satisfy a filter condition. CALCULATE modifies the filter context for its first argument, so the COUNTROWS only sees Orders rows where the predicate (such as DATEDIFF(OrderDate, ShipDate, DAY) <= 3) is true. This is often more performant than an explicit FILTER because CALCULATE can push filters down to the storage engine, and it correctly handles context transitions in row-level calculations.
E
Use DATEDIFF to calculate the difference between ShipDate and OrderDate.
DATEDIFF(Orders[OrderDate], Orders[ShipDate], DAY) is a scalar function that computes the whole number of days between two dates, but it does not by itself filter rows or count anything. To use it correctly, you must embed it in a predicate that is evaluated per row (e.g., inside FILTER) or in a filter argument of CALCULATE. In the correct solution, DATEDIFF provides the condition that defines 'shipped within 3 days,' making it an essential but incomplete part of the measure.

Full breakdown with real-world context →

Question 4mediummultiple choice

Read the full Visualize and analyze the data explanation →

A company has a Power BI report that uses a DirectQuery dataset from an Azure SQL Database. Users report that the report is slow when filtering by date. Which action should you take to improve performance?

Trap 1: Increase the date range filter to include more data

Increasing the date range filter to include more data directly expands the number of rows that DirectQuery must retrieve and process from the relational source. DirectQuery sends each aggregation to the source database without caching results, so a wider date range means longer query execution, larger data transfers, and heavier load on both the database and the report. This is opposite to performance improvement—it will slow down the report, especially when combined with DirectQuery's lack of in-memory compression.

Trap 2: Disable cross-filtering in the report

Disabling cross-filtering in the report only changes how visuals interact on the canvas, but it does not change the underlying DirectQuery queries that are sent to the source database. Cross-filtering affects slicer interactions and visual highlighting, but each visual already generates its own DAX queries; turning off cross-filtering might reduce the number of queries in some interactions, but it doesn't address the root performance problem of querying large fact tables directly. It could even confuse report users, as they would lose the ability to filter related visuals, while the actual date-filtering performance remains unchanged.

Trap 3: Remove unnecessary columns from the date table

Removing unnecessary columns from the date table can slightly reduce the data model size, but a date dimension is already a relatively small table compared to the fact table, and in DirectQuery the date table may be sourced in a way that still requires querying the database. The primary performance bottleneck for date filtering is not the width of the date table but how the relationship and filters are pushed down to the fact table; trimming columns has negligible impact on the date-filtering query path. In fact, if the date table is also in DirectQuery, it might not even be cached, so column removal wouldn't help much either.

Study all Visualize and analyze the data common traps →

A
Create a separate date dimension table and relate it to the fact table
In DirectQuery mode, the fact table stays in the source database, and every visual interaction sends queries to that source. A separate date dimension table—especially one imported or cached as a small static table—lets you define the relationship to the fact table's date column, so filters applied to the date dimension are pushed down as efficient joins against a known, indexed date key rather than performing expensive scans on raw datetime columns. It also makes time-intelligence functions (like YTD, MTD) work correctly in DirectQuery, because those functions require a contiguous date table marked as a date table. This improves query performance and ensures the report is both correct and fast.
B
Increase the date range filter to include more data
Why it fails: Increasing the date range filter to include more data directly expands the number of rows that DirectQuery must retrieve and process from the relational source. DirectQuery sends each aggregation to the source database without caching results, so a wider date range means longer query execution, larger data transfers, and heavier load on both the database and the report. This is opposite to performance improvement—it will slow down the report, especially when combined with DirectQuery's lack of in-memory compression.
C
Disable cross-filtering in the report
Why it fails: Disabling cross-filtering in the report only changes how visuals interact on the canvas, but it does not change the underlying DirectQuery queries that are sent to the source database. Cross-filtering affects slicer interactions and visual highlighting, but each visual already generates its own DAX queries; turning off cross-filtering might reduce the number of queries in some interactions, but it doesn't address the root performance problem of querying large fact tables directly. It could even confuse report users, as they would lose the ability to filter related visuals, while the actual date-filtering performance remains unchanged.
D
Remove unnecessary columns from the date table
Why it fails: Removing unnecessary columns from the date table can slightly reduce the data model size, but a date dimension is already a relatively small table compared to the fact table, and in DirectQuery the date table may be sourced in a way that still requires querying the database. The primary performance bottleneck for date filtering is not the width of the date table but how the relationship and filters are pushed down to the fact table; trimming columns has negligible impact on the date-filtering query path. In fact, if the date table is also in DirectQuery, it might not even be cached, so column removal wouldn't help much either.

Full breakdown with real-world context →

Question 5hardmultiple choice

Read the full Visualize and analyze the data explanation →

A Power BI report uses a composite model with a DirectQuery source and an imported table. The imported table has many rows, and the report is taking a long time to refresh. What is the most likely cause?

Trap 1: Measures are using CALCULATE with multiple filter conditions

Measures are not involved in the refresh pipeline. A scheduled or manual refresh only performs Power Query extract/transform/load steps and writes data into the model; measures are computed on demand when visuals or queries execute DAX against that model. CALCULATE with multiple filter conditions changes filter context during a query and can slow report interaction, but it has zero effect on refresh duration.

Trap 2: The DirectQuery table is set to Import storage mode

DirectQuery storage mode is intrinsic to the table when its data source connection is DirectQuery; you cannot simply change it to Import storage mode without altering the underlying connection/partition configuration. In a composite model, a table from a DirectQuery source remains DirectQuery by design, so the stated option is impossible and cannot be the cause. Moreover, if it somehow were Import, the model would no longer have a live DirectQuery table causing refresh delays.

Trap 3: The report contains many complex visuals that need to be rendered

Visual rendering and DAX query execution happen at user interaction time, not during the refresh process. A refresh operation loads and transforms data into the model and never draws or renders report pages, regardless of how many complex custom visuals exist. Complex visuals can slow report opening and response times, but they have no bearing on how long a scheduled refresh takes.

Study all Visualize and analyze the data common traps →

A
Measures are using CALCULATE with multiple filter conditions
Why it fails: Measures are not involved in the refresh pipeline. A scheduled or manual refresh only performs Power Query extract/transform/load steps and writes data into the model; measures are computed on demand when visuals or queries execute DAX against that model. CALCULATE with multiple filter conditions changes filter context during a query and can slow report interaction, but it has zero effect on refresh duration.
B
The imported table is set to Dual storage mode, causing dependency on the DirectQuery source
Dual storage mode is a hybrid: the table is fully imported but also remains available for DirectQuery queries. When a Dual table lives in a composite model alongside a genuine DirectQuery table, refresh must keep the imported copy coherent with the DirectQuery source's schema, relationships, and security, so Power BI issues extra metadata/consistency queries to that source during refresh. Those additional source round-trips make refresh dependent on DirectQuery source latency, which is exactly why this configuration can slow refresh and is the correct answer.
C
The DirectQuery table is set to Import storage mode
Why it fails: DirectQuery storage mode is intrinsic to the table when its data source connection is DirectQuery; you cannot simply change it to Import storage mode without altering the underlying connection/partition configuration. In a composite model, a table from a DirectQuery source remains DirectQuery by design, so the stated option is impossible and cannot be the cause. Moreover, if it somehow were Import, the model would no longer have a live DirectQuery table causing refresh delays.
D
The report contains many complex visuals that need to be rendered
Why it fails: Visual rendering and DAX query execution happen at user interaction time, not during the refresh process. A refresh operation loads and transforms data into the model and never draws or renders report pages, regardless of how many complex custom visuals exist. Complex visuals can slow report opening and response times, but they have no bearing on how long a scheduled refresh takes.

Full breakdown with real-world context →

Question 6mediummultiple choice

Read the full Visualize and analyze the data explanation →

A Power BI developer writes the Power Query M code shown in the exhibit. The code runs successfully but returns an error when the user selects a year from a slicer in the report. The error states: 'Expression.Error: The key did not match any rows in the table.' Which is the most likely cause?

Exhibit

Refer to the exhibit.

```
let
    Source = Sql.Database("server", "database"),
    SalesTable = Source{[Schema="dbo",Item="Sales"]}[Data],
    FilteredRows = Table.SelectRows(SalesTable, each [Year] = 2021),
    GroupedRows = Table.Group(FilteredRows, {"ProductID"}, {{"TotalSales", each List.Sum([Amount]), type number}})
in
    GroupedRows
```

Trap 1: The table name Sales does not exist in the database

The Sales table not existing would cause an immediate refresh failure at the source connection step, typically raising a DataSource.Error or 'Invalid object name' message. The existing note confirms the code runs successfully initially, proving the table is present. A missing table cannot produce the kind of key-match error described, because the failure would occur before any table operations.

Trap 2: The ProductID column has duplicate values

Duplicate ProductID values do not break Table.Group operations, because grouping aggregates all rows sharing the same key into one group without requiring uniqueness. A key-not-found error would more plausibly come from operations like Table.Lookup or a merge that expects a single matching row, not from grouping. Therefore, duplicates are irrelevant to the reported failure.

Trap 3: The data type of the Year column is text instead of number

If the Year column were stored as text, comparing it to the numeric literal 2021 would result in a type mismatch that M handles by returning false for all comparisons, producing an empty table rather than a key error. The slicer would simply show no rows, not raise a database-level key lookup failure. Thus, a text-typed Year column cannot explain the observed M code error.

Study all Visualize and analyze the data common traps →

A
The table name Sales does not exist in the database
Why it fails: The Sales table not existing would cause an immediate refresh failure at the source connection step, typically raising a DataSource.Error or 'Invalid object name' message. The existing note confirms the code runs successfully initially, proving the table is present. A missing table cannot produce the kind of key-match error described, because the failure would occur before any table operations.
B
The code hardcodes the year 2021, but the slicer passes a different year, causing the M code to fail when the source is queried
The M code treats 2021 as a literal constant in the filter step, so the query is static and cannot respond to slicer interactions. When a slicer selects a different year, Power BI does not rewrite the M code; instead, it tries to query the source for that slicer's selected value, which is absent from the source table. That mismatch between the hardcoded 2021 expectation and the slicer's requested year makes the key lookup fail, causing the M code to error out.
C
The ProductID column has duplicate values
Why it fails: Duplicate ProductID values do not break Table.Group operations, because grouping aggregates all rows sharing the same key into one group without requiring uniqueness. A key-not-found error would more plausibly come from operations like Table.Lookup or a merge that expects a single matching row, not from grouping. Therefore, duplicates are irrelevant to the reported failure.
D
The data type of the Year column is text instead of number
Why it fails: If the Year column were stored as text, comparing it to the numeric literal 2021 would result in a type mismatch that M handles by returning false for all comparisons, producing an empty table rather than a key error. The slicer would simply show no rows, not raise a database-level key lookup failure. Thus, a text-typed Year column cannot explain the observed M code error.

Full breakdown with real-world context →

Question 7easymultiple choice

Read the full Visualize and analyze the data explanation →

A Power BI admin applies the Azure Policy shown in the exhibit. What is the effect of this policy?

Exhibit

Refer to the exhibit.

```json
{
  "Version": "1.0",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "Microsoft.PowerBi/datasets/read"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "Microsoft.PowerBi/workspace": "finance-workspace-id"
        }
      }
    }
  ]
}
```

Trap 1: No one can read any datasets

This option is impossible because the Azure Policy definition contains an explicit conditional branch that permits dataset reads when the workspace path resolves to the finance workspace. The deny effect is scoped to non-matching workspace paths, not to the entire data plane, so read operations in finance continue to succeed. Thus, the statement that no one can read any datasets overstates the policy's reach and ignores the allowed condition.

Trap 2: Users cannot read datasets in the finance workspace

This option reverses the policy's condition logic. The policy's `if` expression checks whether the workspace is the finance workspace and, if true, the read action is allowed; the deny effect fires only when the workspace is something other than finance. Since finance is exactly the workspace that is explicitly exempted from the deny, users with appropriate roles there can read datasets, making this statement false.

Trap 3: All users can read datasets in all workspaces

This option fails on both the workspace and user dimensions. The policy denies read for any workspace whose path does not match finance, so all-workspace access is blocked. Additionally, Azure Policy does not grant read permissions to all users; it merely denies non-compliant actions, and the only users who can read are those holding a role in the finance workspace. Therefore, neither 'all users' nor 'all workspaces' reflects the policy's effective behavior.

Study all Visualize and analyze the data common traps →

A
No one can read any datasets
Why it fails: This option is impossible because the Azure Policy definition contains an explicit conditional branch that permits dataset reads when the workspace path resolves to the finance workspace. The deny effect is scoped to non-matching workspace paths, not to the entire data plane, so read operations in finance continue to succeed. Thus, the statement that no one can read any datasets overstates the policy's reach and ignores the allowed condition.
B
Users cannot read datasets in the finance workspace
Why it fails: This option reverses the policy's condition logic. The policy's `if` expression checks whether the workspace is the finance workspace and, if true, the read action is allowed; the deny effect fires only when the workspace is something other than finance. Since finance is exactly the workspace that is explicitly exempted from the deny, users with appropriate roles there can read datasets, making this statement false.
C
All users can read datasets in all workspaces
Why it fails: This option fails on both the workspace and user dimensions. The policy denies read for any workspace whose path does not match finance, so all-workspace access is blocked. Additionally, Azure Policy does not grant read permissions to all users; it merely denies non-compliant actions, and the only users who can read are those holding a role in the finance workspace. Therefore, neither 'all users' nor 'all workspaces' reflects the policy's effective behavior.
D
Only users in the finance workspace can read datasets
The policy's condition is an allow-list style rule: it only permits dataset read operations when the workspace attribute equals 'finance'. Because a deny effect is applied to every other workspace path, the finance workspace becomes the sole location where Power BI dataset reads can succeed. Users who are members of that workspace (and hold at least the Viewer role) are the only ones who can read datasets, as non-finance workspace requests are blocked regardless of the user's other permissions.

Full breakdown with real-world context →

Question 8mediummultiple choice

Read the full Visualize and analyze the data explanation →

A sales manager wants to create a report that shows year-over-year growth for each product category. They have a date table and a sales table with daily sales. Which DAX measure should they use to calculate the previous year's sales?

Trap 1: Sales PY = CALCULATE(SUM(Sales[Amount]), PARALLELPERIOD(Date[Date],…

PARALLELPERIOD shifts the entire date range backwards by one year, but it returns a full-year period, not a range that mirrors the current filter context. If the current selection is a partial period such as quarter-to-date or year-to-date, it will retrieve the complete previous year, including dates outside the comparable span. This breaks the period-to-period equality needed for accurate year-over-year growth, making it more suitable for whole-period aggregates than for matching-month comparisons.

Trap 2: Sales PY = CALCULATE(SUM(Sales[Amount]), PREVIOUSYEAR(Date[Date]))

PREVIOUSYEAR returns the entire prior calendar year (or fiscal year, as defined by the date table's year-end date) irrespective of the current filter context. In a report showing a specific month or quarter, this formula will return the full previous year's total, not the matching period from last year. Because it changes the granularity of the comparison, it is only appropriate when the desired comparison is against the whole prior year, not for line-level year-over-year growth.

Study all Visualize and analyze the data common traps →

A
Sales PY = CALCULATE(SUM(Sales[Amount]), DATEADD(Date[Date], -1, YEAR))
DATEADD with -1 YEAR shifts each date in the current filter context individually by one calendar year. While this may work for many year-over-year calculations, it is vulnerable to leap year edge cases: February 29 has no exact equivalent, forcing alignment to February 28 or March 1 and introducing small inconsistencies. Because it operates on a per-date basis rather than preserving the overall period shape, it is not the recommended standard for YoY comparisons.
B
Sales PY = CALCULATE(SUM(Sales[Amount]), PARALLELPERIOD(Date[Date], -1, YEAR))
Why it fails: PARALLELPERIOD shifts the entire date range backwards by one year, but it returns a full-year period, not a range that mirrors the current filter context. If the current selection is a partial period such as quarter-to-date or year-to-date, it will retrieve the complete previous year, including dates outside the comparable span. This breaks the period-to-period equality needed for accurate year-over-year growth, making it more suitable for whole-period aggregates than for matching-month comparisons.
C
Sales PY = CALCULATE(SUM(Sales[Amount]), SAMEPERIODLASTYEAR(Date[Date]))
SAMEPERIODLASTYEAR returns a set of dates exactly one year prior to the current filter context, preserving the same date shape and number of days. Because it mirrors the current period—whether that is a month, a quarter, or a custom range—it is purpose-built for year-over-year comparisons. This function is the recommended time intelligence approach for YoY calculations and handles leap day by falling back to the closest valid date, ensuring continuity.
D
Sales PY = CALCULATE(SUM(Sales[Amount]), PREVIOUSYEAR(Date[Date]))
Why it fails: PREVIOUSYEAR returns the entire prior calendar year (or fiscal year, as defined by the date table's year-end date) irrespective of the current filter context. In a report showing a specific month or quarter, this formula will return the full previous year's total, not the matching period from last year. Because it changes the granularity of the comparison, it is only appropriate when the desired comparison is against the whole prior year, not for line-level year-over-year growth.

Full breakdown with real-world context →

Question 9mediummulti select

Read the full Visualize and analyze the data explanation →

Which TWO of the following are valid ways to create a measure in Power BI?

Trap 1: From the Format pane, add a measure.

The Format pane is exclusively for changing the visual appearance of an existing visual—such as colors, labels, borders, and conditional formatting rules—and it has no connection to model calculation objects. Measures are schema-level DAX formulas that live in the tabular model, not visual-level properties, so no command or section in the Format pane can add, edit, or define a measure.

Trap 2: From Power Query Editor, add a custom column.

Power Query Editor is the data transformation surface for M code; creating a custom column there appends a new column to the query result, not a measure to the model. A custom column is evaluated row-by-row at data refresh, whereas a measure is evaluated at query time with adjustable filter context—so adding a custom column is an ETL action, not a modeling action, and produces a static value rather than a dynamic DAX measure.

Trap 3: From the Visualizations pane, click New Measure.

The Visualizations pane (or the Build pane) is designed to configure visuals by dragging fields onto wells and selecting chart types; it contains no 'New Measure' command or DAX input box. If users mistake it for a creation surface, they are actually adding an implicit measure by dragging a numeric column into a visual, which is different from a user-defined explicit measure and does not provide complex DAX expression control.

Study all Visualize and analyze the data common traps →

A
From the Modeling tab, click New Measure.
The Modeling tab's 'New Measure' button is the canonical DAX creation path: it launches a Formula Bar with a default measure name and DAX skeleton, letting you type an expression that is stored as an explicit measure in the model. Because Power BI auto-selects the target table based on your current selection in the Fields pane, this method is direct and always available regardless of context.
B
Right-click a table in the Fields pane and select New Measure.
Right-clicking a table in the Fields pane and selecting 'New Measure' creates an explicit DAX measure whose home table is predetermined by the table you choose. This is functionally identical to the Modeling tab approach, but it reinforces the physical model's organization because the measure is immediately tied to the right table, and it is a faster path when you already have the Fields pane open and need to scope the measure correctly.
C
From the Format pane, add a measure.
Why it fails: The Format pane is exclusively for changing the visual appearance of an existing visual—such as colors, labels, borders, and conditional formatting rules—and it has no connection to model calculation objects. Measures are schema-level DAX formulas that live in the tabular model, not visual-level properties, so no command or section in the Format pane can add, edit, or define a measure.
D
From Power Query Editor, add a custom column.
Why it fails: Power Query Editor is the data transformation surface for M code; creating a custom column there appends a new column to the query result, not a measure to the model. A custom column is evaluated row-by-row at data refresh, whereas a measure is evaluated at query time with adjustable filter context—so adding a custom column is an ETL action, not a modeling action, and produces a static value rather than a dynamic DAX measure.
E
From the Visualizations pane, click New Measure.
Why it fails: The Visualizations pane (or the Build pane) is designed to configure visuals by dragging fields onto wells and selecting chart types; it contains no 'New Measure' command or DAX input box. If users mistake it for a creation surface, they are actually adding an implicit measure by dragging a numeric column into a visual, which is different from a user-defined explicit measure and does not provide complex DAX expression control.

Full breakdown with real-world context →

Question 10hardmulti select

Read the full Visualize and analyze the data explanation →

Which THREE of the following are best practices for designing Power BI reports for mobile devices?

Trap 1: Include all pages from the desktop report in the mobile layout.

Mobile layouts should be curated for the small-screen context; replicating every desktop page forces mobile users to pan and scroll through dense dashboards that were designed for a wide canvas. Reporting best practice is to reduce the mobile experience to the most critical KPIs and insights, so including all desktop pages directly contradicts the goal of streamlined, at-a-glance mobile consumption. This also increases load time and requires users to hunt for relevant information, degrading the mobile experience.

Trap 2: Use only responsive visuals that automatically resize.

Not all Power BI visuals are fully responsive; many built-in and custom visuals require manual adjustment to render well on a mobile layout, and even 'responsive' visuals cannot handle all types of data or axis configurations gracefully. Relying solely on automatic resizing can produce truncated labels, overlapping elements, or unreadable charts, especially with dense text or many series. The supported approach is to combine the mobile layout designer with visual-level settings (like font size and padding) rather than trusting universal auto-resize.

Study all Visualize and analyze the data common traps →

A
Include all pages from the desktop report in the mobile layout.
Why it fails: Mobile layouts should be curated for the small-screen context; replicating every desktop page forces mobile users to pan and scroll through dense dashboards that were designed for a wide canvas. Reporting best practice is to reduce the mobile experience to the most critical KPIs and insights, so including all desktop pages directly contradicts the goal of streamlined, at-a-glance mobile consumption. This also increases load time and requires users to hunt for relevant information, degrading the mobile experience.
B
Create a separate mobile layout for the report.
Power BI's mobile layout feature lets you design a distinct view by rearranging, resizing, and hiding visuals from the desktop report, giving you full control over what appears on phones. Instead of relying on automatic reflow, a separate layout lets you build a purpose-specific narrative for mobile users, such as stacking key charts vertically for one-thumb scrolling. This is a core best practice because it adapts information density and visual hierarchy to the constraints of a small screen without altering the desktop report's structure.
C
Minimize the number of visuals on each page to avoid clutter.
On a mobile screen, each visual occupies a substantial portion of the viewport, so placing too many visuals on one page forces excessive scrolling and makes it hard for users to compare or interpret data at a glance. Best practice is to limit each mobile page to three to five focused visuals, letting each chart or card remain readable without requiring pinch-to-zoom. Reducing clutter also lowers cognitive load, which is essential for mobile users who may be in a distracting environment.
D
Use large, readable fonts and high-contrast colors.
Mobile devices are often viewed at arm's length in bright or dim conditions, so small fonts and low-contrast palettes cause readability failures that would be less severe on a desktop monitor. Power BI's theme settings allow you to enforce minimum font sizes and accessible color pairings across visuals, ensuring that text and data points are distinguishable on screens as small as five inches. This practice directly supports accessibility and makes mobile dashboards usable without zooming or squinting.
E
Use only responsive visuals that automatically resize.
Why it fails: Not all Power BI visuals are fully responsive; many built-in and custom visuals require manual adjustment to render well on a mobile layout, and even 'responsive' visuals cannot handle all types of data or axis configurations gracefully. Relying solely on automatic resizing can produce truncated labels, overlapping elements, or unreadable charts, especially with dense text or many series. The supported approach is to combine the mobile layout designer with visual-level settings (like font size and padding) rather than trusting universal auto-resize.

Full breakdown with real-world context →

Question 11hardmultiple choice

Read the full Visualize and analyze the data explanation →

You are a Power BI analyst for a retail company. You have a dataset containing a 'Sales' table with columns: SalesDate, StoreID, ProductID, Quantity, UnitPrice, and Discount. You also have a 'Calendar' table marked as a date table with a continuous date range from 2018 to 2023. You need to create a measure that calculates the running total of sales amount (Quantity * (UnitPrice - Discount)) over the last 12 months, but only for products that have been sold in at least 10 different stores in the current month. The measure should be dynamic based on the current filter context (e.g., month, year). The report will be used by regional managers to monitor product performance. You have already created a base measure: TotalSales = SUMX(Sales, Sales[Quantity] * (Sales[UnitPrice] - Sales[Discount])). Which DAX measure should you create?

Trap 1: RunningTotal = CALCULATE([TotalSales],…

Unlike the correct version, VALUES(Sales[ProductID]) merely preserves the current filter context on ProductID without imposing any condition on store count. It does not iterate over all products to exclude those with fewer than 10 stores in the current month; it simply carries forward whatever product selection already exists. Additionally, without a CALCULATE-wrapped DISTINCTCOUNT per product, the measure cannot determine store eligibility, so products with low store counts remain included.

Trap 2: RunningTotal = CALCULATE([TotalSales],…

ALL('Calendar') removes all filters from the Calendar table, which invalidates the date context needed for the running total. The MAX('Calendar'[Date]) inside DATESINPERIOD would then reference the overall maximum date in the calendar, not the selected month, so the rolling window shifts incorrectly. Moreover, ALL('Calendar') never applies the required store-count filter, so it fails both the date and product eligibility conditions.

Trap 3: RunningTotal = CALCULATE([TotalSales],…

COUNTROWS(SUMMARIZE(Sales, Sales[StoreID])) computes the distinct store count for each product across the entire Sales table (or the full filter context), ignoring the current-month constraint. This version evaluates the store count over all historical dates, so products that used to have 10 stores but not this month would be incorrectly included. It also lacks DATESMTD or any month-limiting logic, making it ineffective for the 'at least 10 stores in the current month' requirement.

Study all Visualize and analyze the data common traps →

A
RunningTotal = CALCULATE([TotalSales], DATESINPERIOD('Calendar'[Date], MAX('Calendar'[Date]), -12, MONTH), FILTER(ALL(Sales[ProductID]), CALCULATE(DISTINCTCOUNT(Sales[StoreID]), DATESMTD('Calendar'[Date])) >= 10))
This is correct because the inner CALCULATE(DISTINCTCOUNT(Sales[StoreID]), DATESMTD('Calendar'[Date])) is evaluated for each product in the FILTER iteration, using context transition to compute the distinct store count for the current month (month-to-date up to the max visible date). Only products meeting the >=10 threshold remain, and then DATESINPERIOD applies the trailing 12-month window for the running total. This properly layers the monthly store eligibility check within the historical aggregation.
B
RunningTotal = CALCULATE([TotalSales], DATESINPERIOD('Calendar'[Date], MAX('Calendar'[Date]), -12, MONTH), VALUES(Sales[ProductID]))
Why it fails: Unlike the correct version, VALUES(Sales[ProductID]) merely preserves the current filter context on ProductID without imposing any condition on store count. It does not iterate over all products to exclude those with fewer than 10 stores in the current month; it simply carries forward whatever product selection already exists. Additionally, without a CALCULATE-wrapped DISTINCTCOUNT per product, the measure cannot determine store eligibility, so products with low store counts remain included.
C
RunningTotal = CALCULATE([TotalSales], DATESINPERIOD('Calendar'[Date], MAX('Calendar'[Date]), -12, MONTH), ALL('Calendar'))
Why it fails: ALL('Calendar') removes all filters from the Calendar table, which invalidates the date context needed for the running total. The MAX('Calendar'[Date]) inside DATESINPERIOD would then reference the overall maximum date in the calendar, not the selected month, so the rolling window shifts incorrectly. Moreover, ALL('Calendar') never applies the required store-count filter, so it fails both the date and product eligibility conditions.
D
RunningTotal = CALCULATE([TotalSales], DATESINPERIOD('Calendar'[Date], MAX('Calendar'[Date]), -12, MONTH), FILTER(ALL(Sales[ProductID]), COUNTROWS(SUMMARIZE(Sales, Sales[StoreID])) >= 10))
Why it fails: COUNTROWS(SUMMARIZE(Sales, Sales[StoreID])) computes the distinct store count for each product across the entire Sales table (or the full filter context), ignoring the current-month constraint. This version evaluates the store count over all historical dates, so products that used to have 10 stores but not this month would be incorrectly included. It also lacks DATESMTD or any month-limiting logic, making it ineffective for the 'at least 10 stores in the current month' requirement.

Full breakdown with real-world context →

Question 12mediummultiple choice

Read the full Visualize and analyze the data explanation →

You are building a report for a logistics company. The dataset includes a 'Shipments' table with columns: ShipmentID, ShipDate, OriginCity, DestinationCity, Weight, Revenue, and Carrier. The company wants to analyze revenue trends by carrier over time. They have a date table marked as a date table. You create a line chart with ShipDate on the axis and Revenue as the value, with Carrier as the legend. However, the line chart shows a single line for each carrier, but the revenue values are aggregated across all dates, showing a constant line. What is the most likely cause?

Trap 1: There are missing relationships between Shipments and the date…

A missing relationship between the Shipments table and the date table would prevent date slicers and filters from propagating to the Shipments data. However, the line chart uses the ShipDate column directly from the Shipments table, so it would still display a distinct data point per unique ShipDate value. The lack of a relationship would not force all revenue values to collapse into a single constant line.

Trap 2: The ShipDate column is of type 'Text' instead of 'Date'.

When the ShipDate column is stored as Text instead of Date, Power BI cannot treat it as a continuous time series or apply date hierarchy logic. The line chart interprets each unique text string as a separate category, and if the values are not recognized as chronological, the chart may plot a single aggregate or a flat, constant line rather than varying over time. This directly matches the symptom described, making it the correct diagnosis.

Trap 3: The Revenue column is a measure that is not summing correctly.

A Revenue column that is a measure and summing incorrectly would still respond to the filter context of the chart. If the axis contains ShipDate, the measure would be recalculated for each ShipDate value, producing a varying line unless the measure is intentionally constant or the date context is removed. An incorrect sum would show wrong values, not a single horizontal line, so this does not explain the observed behavior.

Study all Visualize and analyze the data common traps →

A
There are missing relationships between Shipments and the date table.
Why it fails: A missing relationship between the Shipments table and the date table would prevent date slicers and filters from propagating to the Shipments data. However, the line chart uses the ShipDate column directly from the Shipments table, so it would still display a distinct data point per unique ShipDate value. The lack of a relationship would not force all revenue values to collapse into a single constant line.
B
The ShipDate column is of type 'Text' instead of 'Date'.
Why it fails: When the ShipDate column is stored as Text instead of Date, Power BI cannot treat it as a continuous time series or apply date hierarchy logic. The line chart interprets each unique text string as a separate category, and if the values are not recognized as chronological, the chart may plot a single aggregate or a flat, constant line rather than varying over time. This directly matches the symptom described, making it the correct diagnosis.
C
The Revenue column is a measure that is not summing correctly.
Why it fails: A Revenue column that is a measure and summing incorrectly would still respond to the filter context of the chart. If the axis contains ShipDate, the measure would be recalculated for each ShipDate value, producing a varying line unless the measure is intentionally constant or the date context is removed. An incorrect sum would show wrong values, not a single horizontal line, so this does not explain the observed behavior.
D
The date table is marked as a date table but not related to Shipments.
If the date table is marked as a date table but has no relationship to Shipments, the date table cannot filter or cross-filter the Shipments table. Nevertheless, the line chart is built directly on the ShipDate column from Shipments, so it would still show different revenue totals for each ShipDate. The missing relationship only breaks downstream filtering from date slicers; it does not collapse the chart into constant lines.

Full breakdown with real-world context →

Question 13mediummulti select

Read the full Visualize and analyze the data explanation →

You are developing a Power BI report to analyze sales performance. The data model includes a 'Sales' fact table with a 'Date' column and a 'Region' dimension table. You need to create a measure that calculates the total sales amount for the current year compared to the previous year. Which TWO of the following steps are required to implement this calculation correctly?

Trap 1: Use the Quick Measure feature to create a 'Year-over-year change'…

The Quick Measure feature can generate a Year-over-year change measure, but it is a convenience tool, not a required step. It does not create or mark a separate date table, which is the foundation for time intelligence. Using it may produce code that still fails if the underlying model lacks a proper date table or relationships.

Trap 2: Apply the CALCULATE function to switch between years.

CALCULATE is a powerful function for modifying filter context, but it is generic and not inherently designed for year-over-year comparison. To compute a previous year's value, you would need to combine CALCULATE with a filter expression or a dedicated time intelligence function. Simply applying CALCULATE does not automatically shift time periods and is not a substitute for a proper date table.

Trap 3: Ensure the 'Sales' table has a relationship to the 'Date' table…

A many-to-many relationship between the Sales table and the Date table is incorrect modeling for time intelligence. The proper relationship is many-to-one, where the Date table is on the one side and the fact table on the many side. Many-to-many relationships create ambiguous filtering and can cause aggregations to multiply incorrectly, breaking time intelligence calculations.

Study all Visualize and analyze the data common traps →

A
Use the Quick Measure feature to create a 'Year-over-year change' measure.
Why it fails: The Quick Measure feature can generate a Year-over-year change measure, but it is a convenience tool, not a required step. It does not create or mark a separate date table, which is the foundation for time intelligence. Using it may produce code that still fails if the underlying model lacks a proper date table or relationships.
B
Create a separate date table and mark it as a date table in Power BI.
Creating a separate date table and marking it as a date table is the foundational requirement for any time intelligence calculation in Power BI. Marking the table specifies the date column used by DAX time intelligence functions like SAMEPERIODLASTYEAR. Without this, functions may return errors or incorrect results because Power BI cannot reliably determine the continuous calendar range.
C
Apply the CALCULATE function to switch between years.
Why it fails: CALCULATE is a powerful function for modifying filter context, but it is generic and not inherently designed for year-over-year comparison. To compute a previous year's value, you would need to combine CALCULATE with a filter expression or a dedicated time intelligence function. Simply applying CALCULATE does not automatically shift time periods and is not a substitute for a proper date table.
D
Use the SAMEPERIODLASTYEAR function in a DAX measure.
SAMEPERIODLASTYEAR is a standard DAX time intelligence function that returns a set of dates from the previous year, using the current filter context. It is designed specifically for year-over-year comparisons and works correctly only when a separate date table is marked as a date table and has a proper relationship. This function is a direct and recommended approach for such calculations.
E
Ensure the 'Sales' table has a relationship to the 'Date' table with a many-to-many cardinality.
Why it fails: A many-to-many relationship between the Sales table and the Date table is incorrect modeling for time intelligence. The proper relationship is many-to-one, where the Date table is on the one side and the fact table on the many side. Many-to-many relationships create ambiguous filtering and can cause aggregations to multiply incorrectly, breaking time intelligence calculations.

Full breakdown with real-world context →

Question 14hardmultiple choice

Read the full Visualize and analyze the data explanation →

You are reviewing a Power Query M script that imports sales data. The script filters orders from 2023, groups by CustomerID to sum SubTotal, sorts descending, and takes the top 10 customers. However, the query fails with an error. What is the most likely cause?

Exhibit

Refer to the exhibit.

```
let
    Source = Sql.Database("server01", "AdventureWorks"),
    Sales = Source{[Schema="dbo",Item="SalesOrderHeader"]}[Data],
    #"Filtered Rows" = Table.SelectRows(Sales, each [OrderDate] >= #date(2023,1,1) and [OrderDate] < #date(2024,1,1)),
    #"Grouped Rows" = Table.Group(#"Filtered Rows", {"CustomerID"}, {{"TotalSales", each List.Sum([SubTotal]), type nullable number}}),
    #"Sorted Rows" = Table.Sort(#"Grouped Rows",{{"TotalSales", Order.Descending}}),
    #"Top Rows" = Table.FirstN(#"Sorted Rows", 10)
in
    #"Top Rows"
```

Trap 1: The parameters in Sql.Database are reversed; the correct order is…

The M function Sql.Database has a strict signature: the first argument is the server name and the second is the database name. The script's call `Sql.Database(ServerName, DatabaseName)` therefore correctly follows this order. Reversing them would make M attempt to connect to a server named as the database string, causing a connection failure. Thus, the claim that the parameters are reversed is false.

Trap 2: The Table.FirstN function is missing the second argument; it should…

Table.FirstN requires a second argument that specifies the number of rows to return or a condition; the script already includes that argument as `10` in `Table.FirstN(#"Sorted Rows", 10)`. Omitting the second argument would generate a function error, but that is not the case here. The statement mischaracterizes a complete and valid function call.

Trap 3: The #date function cannot be used with a datetime column; use…

The #date function is perfectly valid for constructing a date value; when compared to a datetime column, Power Query implicitly coerces the date to a datetime at midnight (00:00:00) for the comparison. DateTime.From would convert a value into a datetime, but it is unnecessary here and would not alter the comparison logic. Therefore, replacing #date with DateTime.From is neither required nor beneficial.

Study all Visualize and analyze the data common traps →

A
The parameters in Sql.Database are reversed; the correct order is database name first, then server.
Why it fails: The M function Sql.Database has a strict signature: the first argument is the server name and the second is the database name. The script's call `Sql.Database(ServerName, DatabaseName)` therefore correctly follows this order. Reversing them would make M attempt to connect to a server named as the database string, causing a connection failure. Thus, the claim that the parameters are reversed is false.
B
The Table.FirstN function is missing the second argument; it should be Table.FirstN(#"Sorted Rows", 10).
Why it fails: Table.FirstN requires a second argument that specifies the number of rows to return or a condition; the script already includes that argument as `10` in `Table.FirstN(#"Sorted Rows", 10)`. Omitting the second argument would generate a function error, but that is not the case here. The statement mischaracterizes a complete and valid function call.
C
The column name 'SubTotal' is misspelled; the correct column name is 'Subtotal'.
The column name 'SubTotal' is indeed incorrect; the correct source column is 'Subtotal' with a lowercase 't' after 'b'. In Power Query M, column references are case-sensitive, so using 'SubTotal' will cause the query to fail with a 'column not found' error or return null in certain contexts. This typographical error is the actual root cause of the issue.
D
The #date function cannot be used with a datetime column; use DateTime.From instead.
Why it fails: The #date function is perfectly valid for constructing a date value; when compared to a datetime column, Power Query implicitly coerces the date to a datetime at midnight (00:00:00) for the comparison. DateTime.From would convert a value into a datetime, but it is unnecessary here and would not alter the comparison logic. Therefore, replacing #date with DateTime.From is neither required nor beneficial.

Full breakdown with real-world context →

Question 15easymultiple choice

Read the full Visualize and analyze the data explanation →

You are a Power BI analyst at a retail company. The company has a Power BI dataset that imports daily sales data from an on-premises SQL Server database. The dataset includes tables: 'Sales' (columns: SaleID, ProductID, SaleDate, Quantity, UnitPrice, CustomerID), 'Products' (ProductID, ProductName, Category), and 'Customers' (CustomerID, CustomerName, Region). The report needs to display a matrix visual showing total sales amount (Quantity * UnitPrice) by Category (rows) and Year (columns). The report currently shows blank values for the matrix. You have verified that relationships exist between the tables and that there is a date table marked as a date table. The measure used is: Total Sales = SUMX(Sales, Sales[Quantity] * Sales[UnitPrice]). When you test the measure in a card visual, it returns a value. However, the matrix shows blanks. What is the most likely cause and solution?

Trap 1: Use the ALL function in the measure to ignore filter context.

Using the ALL function inside the measure would strip away the existing row and column filter context from the matrix, so every cell would show the same grand total rather than the correct date-sliced value. This does not repair the missing relationship; it merely suppresses context and yields misleading summaries. The root problem is that filters from the date table never reach the Sales table, and ALL does nothing to establish or activate a relationship.

Trap 2: Create an active relationship between the date table and the Sales…

Creating an active relationship between the date table and Sales on the SaleDate column is the correct fix because it allows filter propagation: when the matrix displays date fields (e.g., year or month) from the date table, DAX will automatically traverse the relationship to filter matching rows in Sales. An active one-to-many relationship is the standard star-schema design for a date dimension and ensures all standard visual interactions and time-intelligence functions work as intended without extra DAX workarounds.

Trap 3: Modify the measure to use CALCULATE with USERELATIONSHIP to force…

CALCULATE with USERELATIONSHIP is only useful when a relationship already exists but is marked as inactive, so it can be temporarily activated within that measure for a specific calculation. In this scenario, if no relationship is defined at all between the date table and Sales, USERELATIONSHIP will fail or have no effect, and even if it did exist but was inactive, rewriting every measure with this pattern would be far less maintainable than simply setting the relationship to active in the model.

Study all Visualize and analyze the data common traps →

A
Use the ALL function in the measure to ignore filter context.
Why it fails: Using the ALL function inside the measure would strip away the existing row and column filter context from the matrix, so every cell would show the same grand total rather than the correct date-sliced value. This does not repair the missing relationship; it merely suppresses context and yields misleading summaries. The root problem is that filters from the date table never reach the Sales table, and ALL does nothing to establish or activate a relationship.
B
Create an active relationship between the date table and the Sales table on the SaleDate column.
Why it fails: Creating an active relationship between the date table and Sales on the SaleDate column is the correct fix because it allows filter propagation: when the matrix displays date fields (e.g., year or month) from the date table, DAX will automatically traverse the relationship to filter matching rows in Sales. An active one-to-many relationship is the standard star-schema design for a date dimension and ensures all standard visual interactions and time-intelligence functions work as intended without extra DAX workarounds.
C
Modify the measure to use CALCULATE with USERELATIONSHIP to force the relationship.
Why it fails: CALCULATE with USERELATIONSHIP is only useful when a relationship already exists but is marked as inactive, so it can be temporarily activated within that measure for a specific calculation. In this scenario, if no relationship is defined at all between the date table and Sales, USERELATIONSHIP will fail or have no effect, and even if it did exist but was inactive, rewriting every measure with this pattern would be far less maintainable than simply setting the relationship to active in the model.
D
Convert the SaleDate column to a date data type using Power Query.
Converting SaleDate to a date data type in Power Query does not address the fundamental modeling issue: without a relationship, filter context cannot flow from the date table to the fact table regardless of column types. If the column is already a date (or a date/time), the conversion is redundant, and if it is text, Power BI can often still create a relationship after auto-detecting the type, but the absence of a relationship is the true cause of the blank or unsliced matrix. Data type changes affect storage and formatting, not table-level filter propagation.

Full breakdown with real-world context →

Question 16mediumdrag order

Read the full Visualize and analyze the data explanation →

Drag and drop the steps to import data from a SQL Server database into Power BI Desktop into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Click Get Data and select SQL Server, then open Power BI Desktop,…

In Power BI Desktop's import workflow, you cannot invoke the Get Data dialog before the application is running. The very first action must be launching Power BI Desktop, after which the Get Data experience becomes available. Placing Get Data first makes the sequence invalid, even though the remaining steps (SQL Server connector, server/database/authentication, and table/query selection) are in the correct relative order.

Trap 2: Open Power BI Desktop, then enter server name and database name and…

The Get Data step is not optional before connection details; it is the gateway that initializes the SQL Server connector and its corresponding connection dialog. Typing server, database, and authentication information before selecting the data source is impossible because no connector exists yet to accept those values. In the correct workflow, Get Data must come immediately after opening Power BI Desktop and before any connection-specific fields are entered.

Trap 3: Open Power BI Desktop, then click Get Data and select SQL Server,…

Power BI can only display database tables or execute a SQL query after a connection has been established with the server and database, including successful authentication. Selecting tables or writing a query before providing those connection details is not possible because the Navigator experience and the Load/Transform options are dependent on an active data source connection. Therefore, the connection details must be entered before any data selection or transformation choice.

Study all Visualize and analyze the data common traps →

A
Open Power BI Desktop, then click Get Data and select SQL Server, then enter server name and database name and authentication, then select tables or write a SQL query and click Load or Transform.
This is the correct order because you must first open Power BI Desktop, then initiate the data import by selecting Get Data and choosing SQL Server. After that, you connect to the server and database, and finally choose the tables or query and decide to load or transform the data.
B
Click Get Data and select SQL Server, then open Power BI Desktop, then enter server name and database name and authentication, then select tables or write a SQL query and click Load or Transform.
Why it fails: In Power BI Desktop's import workflow, you cannot invoke the Get Data dialog before the application is running. The very first action must be launching Power BI Desktop, after which the Get Data experience becomes available. Placing Get Data first makes the sequence invalid, even though the remaining steps (SQL Server connector, server/database/authentication, and table/query selection) are in the correct relative order.
C
Open Power BI Desktop, then enter server name and database name and authentication, then click Get Data and select SQL Server, then select tables or write a SQL query and click Load or Transform.
Why it fails: The Get Data step is not optional before connection details; it is the gateway that initializes the SQL Server connector and its corresponding connection dialog. Typing server, database, and authentication information before selecting the data source is impossible because no connector exists yet to accept those values. In the correct workflow, Get Data must come immediately after opening Power BI Desktop and before any connection-specific fields are entered.
D
Open Power BI Desktop, then click Get Data and select SQL Server, then select tables or write a SQL query and click Load or Transform, then enter server name and database name and authentication.
Why it fails: Power BI can only display database tables or execute a SQL query after a connection has been established with the server and database, including successful authentication. Selecting tables or writing a query before providing those connection details is not possible because the Navigator experience and the Load/Transform options are dependent on an active data source connection. Therefore, the connection details must be entered before any data selection or transformation choice.

Full breakdown with real-world context →

Question 17mediummatching

Read the full Visualize and analyze the data explanation →

Match each data connectivity mode to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Data is copied into Power BI

Queries are sent to the source database

Connects to a published dataset or Analysis Services

Combines Import and DirectQuery sources

Acts as Import or DirectQuery depending on context

Trap 1: Import: Data is not stored locally, queries are sent to source.

This description is incorrect because it swaps the roles of Import and DirectQuery: Import does store a local copy of the data inside the Power BI dataset. The phrase 'data is not stored locally, queries are sent to source' precisely characterizes DirectQuery, where each visual issues a query against the original database. Using this description for Import would confuse the mode's storage model and lead to incorrect expectations about refresh and performance.

Trap 2: DirectQuery: Data is stored in Power BI cache.

This is incorrect because DirectQuery never caches the underlying table data in Power BI; each interaction sends a query back to the source and only the minimal result set for a specific visual may be temporarily held for rendering. Data caching in Power BI is a hallmark of Import mode, where the VertiPaq engine compresses and stores all table data. If DirectQuery cached the data, it would no longer provide real-time freshness and would undermine its purpose for large or live sources.

Study all Visualize and analyze the data common traps →

A
Import: Data is stored in the Power BI dataset.
Import mode physically copies table data into Power BI's VertiPaq in-memory columnar store during refresh, making the dataset fully self-contained. Because queries execute against the local cache, visual interactions are fast even if the original source is slow or unreachable. This mode is the default for most Power BI datasets and is ideal when you need frequent refreshes, data transformations, or high-performance analytics.
B
DirectQuery: Queries are sent directly to the data source.
DirectQuery does not copy data into Power BI; instead, Power BI sends native queries to the underlying source (e.g., SQL Server, Snowflake) every time a visual changes or is filtered. This guarantees real-time freshness because data remains in the source, but performance depends heavily on the source's indexing, query concurrency, and network latency. It is best for very large data that cannot fit in Power BI or where the source is already optimized for querying.
C
Live Connection: Connects to a report or dataset in Power BI service.
Live Connection mode creates a direct link from a Power BI report to an existing semantic model (dataset), either in the Power BI service or in Azure Analysis Services, without importing any data. It ensures all reports use the same shared model, preserving row-level security and consistent definitions, but report authors cannot add new tables or columns. Because the connection is live, the model's refresh schedule and performance govern the report's behavior.
D
Composite Model: Combines data from multiple sources using Import and DirectQuery.
A Composite Model allows a single dataset to combine imported tables (cached in VertiPaq) with DirectQuery sources or even Live connections to other models. For example, you can import small dimension tables while leaving a massive fact table in DirectQuery, then create relationships and measures across both. This hybrid approach gives you the speed of Import where it matters and the freshness or scale of DirectQuery where necessary, but it introduces considerations around query behavior and aggregation.
E
Import: Data is not stored locally, queries are sent to source.
Why it fails: This description is incorrect because it swaps the roles of Import and DirectQuery: Import does store a local copy of the data inside the Power BI dataset. The phrase 'data is not stored locally, queries are sent to source' precisely characterizes DirectQuery, where each visual issues a query against the original database. Using this description for Import would confuse the mode's storage model and lead to incorrect expectations about refresh and performance.
F
DirectQuery: Data is stored in Power BI cache.
Why it fails: This is incorrect because DirectQuery never caches the underlying table data in Power BI; each interaction sends a query back to the source and only the minimal result set for a specific visual may be temporarily held for rendering. Data caching in Power BI is a hallmark of Import mode, where the VertiPaq engine compresses and stores all table data. If DirectQuery cached the data, it would no longer provide real-time freshness and would undermine its purpose for large or live sources.

Full breakdown with real-world context →

Question 18mediummatching

Read the full Visualize and analyze the data explanation →

Match each DAX function category to an example function.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

SUM

CALCULATE

TOTALYTD

SUMMARIZE

Trap 1: Text: DATE

DATE is not a text function; it is a date/time function that constructs a date value from year, month, and day arguments. The Text category in DAX comprises functions that manipulate strings, such as LEFT, RIGHT, CONCATENATE, and FORMAT. Since DATE returns a datetime data type and performs no string manipulation, labeling it as a Text function is a category mismatch.

Trap 2: Date/Time: LEFT

LEFT is not a date/time function; it is a text function that returns the first N characters from a string. DAX date/time functions are those that operate on or return dates, times, or durations, such as DATE, TODAY, YEAR, and DATEDIFF. LEFT does not handle date arithmetic or date values, so assigning it to the Date/Time category is incorrect.

Study all Visualize and analyze the data common traps →

A
Aggregation: SUM
SUM is a canonical DAX aggregation function: it evaluates an expression over a column and returns the arithmetic sum of the values in that column, ignoring blanks. In the DAX function reference, SUM is explicitly categorized under 'Aggregation', alongside functions like AVERAGE, MIN, MAX, and SUMX. Because it performs a scalar aggregation over a set of values, placing it in the Aggregation category is technically correct.
B
Logical: IF
IF is the foundational DAX logical function: it checks a condition and returns one value when the condition is TRUE and another when it is FALSE. In DAX, logical functions are those that evaluate a Boolean expression or test a condition, and IF is the classic representative of that category. It supports nested conditions and is often used inside calculated columns or measures to implement branching logic, making its placement in the Logical category correct.
C
Text: DATE
Why it fails: DATE is not a text function; it is a date/time function that constructs a date value from year, month, and day arguments. The Text category in DAX comprises functions that manipulate strings, such as LEFT, RIGHT, CONCATENATE, and FORMAT. Since DATE returns a datetime data type and performs no string manipulation, labeling it as a Text function is a category mismatch.
D
Date/Time: LEFT
Why it fails: LEFT is not a date/time function; it is a text function that returns the first N characters from a string. DAX date/time functions are those that operate on or return dates, times, or durations, such as DATE, TODAY, YEAR, and DATEDIFF. LEFT does not handle date arithmetic or date values, so assigning it to the Date/Time category is incorrect.
E
Filter: CALCULATE
CALCULATE is a filter function that modifies the filter context of a measure by applying explicit filter arguments to an expression. It is widely considered the most powerful and essential DAX function for dynamic measure calculation, because it allows you to change or override existing filters within an evaluation. DAX categorizes CALCULATE under the Filter category, along with related functions like FILTER, ALL, and REMOVEFILTERS, making this pairing correct.

Full breakdown with real-world context →

Question 19hardmultiple choice

Read the full Visualize and analyze the data explanation →

You are designing a Power BI report to analyze customer churn. The data model includes a 'Customers' table and a 'Churn' table. You need to create a measure that calculates the churn rate for each month, defined as the number of customers who churned that month divided by the total number of active customers at the beginning of the month. What is the best approach?

Trap 1: Write a measure using COUNTROWS and FILTER.

Incorrect. While COUNTROWS and FILTER could technically be used, it would require complex and potentially slow logic to get the snapshot of active customers at the start of each month. The calculated table approach is cleaner and more performant.

Trap 2: Use the RANKX function to order customers by churn date.

RANKX is a scalar iterator that assigns a rank to a value within an ordering context; it is designed for leaderboards, top-N filtering, or percentile comparisons, not for time-state aggregation. Even if you ranked customers by their churn date, the result is a single sequential number per customer that carries no information about how many were active at the start of each month, which is the denominator needed for churn rate. Additionally, RANKX does not inherently respect month boundary filters and would require complex slicing to extract a monthly count, making it both conceptually and practically the wrong tool for this calculation.

Trap 3: Create a calculated column in the 'Customers' table to mark churned…

Incorrect. A calculated column in the Customers table would mark churned status per row, but it does not provide the aggregation per month needed for the churn rate denominator. It would also be static and not respect month boundaries.

Study all Visualize and analyze the data common traps →

A
Create a calculated table that summarizes active customers at the start of each month.
A calculated table that snapshots the active customer population at the start of each month is the appropriate foundation for churn rate. Because the denominator must reflect the exact customer set in force at the beginning of the period, materializing one row per customer per month-start with a COUNTROWS or implicit count allows a simple measure like DIVIDE(churned_customers, [ActiveAtStart]) to work reliably. This table is computed once at data refresh, so it avoids expensive run-time iteration over the entire customer fact table, and it naturally supports month-over-month analysis via the report's date dimension.
B
Write a measure using COUNTROWS and FILTER.
Why it fails: Incorrect. While COUNTROWS and FILTER could technically be used, it would require complex and potentially slow logic to get the snapshot of active customers at the start of each month. The calculated table approach is cleaner and more performant.
C
Use the RANKX function to order customers by churn date.
Why it fails: RANKX is a scalar iterator that assigns a rank to a value within an ordering context; it is designed for leaderboards, top-N filtering, or percentile comparisons, not for time-state aggregation. Even if you ranked customers by their churn date, the result is a single sequential number per customer that carries no information about how many were active at the start of each month, which is the denominator needed for churn rate. Additionally, RANKX does not inherently respect month boundary filters and would require complex slicing to extract a monthly count, making it both conceptually and practically the wrong tool for this calculation.
D
Create a calculated column in the 'Customers' table to mark churned status per month.
Why it fails: Incorrect. A calculated column in the Customers table would mark churned status per row, but it does not provide the aggregation per month needed for the churn rate denominator. It would also be static and not respect month boundaries.

Full breakdown with real-world context →

Question 20hardmultiple choice

Read the full Visualize and analyze the data explanation →

You have a Power BI report with a date table and a sales table. The above DAX measure is used in a visual that also shows 'Date[Year]' on the axis. What does this measure return?

Exhibit

Refer to the exhibit.

```dax
CALCULATE(
    SUM(Sales[Amount]),
    FILTER(
        ALL(Date),
        Date[Year] = MAX(Date[Year])
    )
)
```

Trap 1: The sum of sales for all years.

This option misreads the FILTER predicate. The measure filters Date[Year] to equal MAX(Date[Year]), which selects only the single maximum year, not all years. The FILTER function acts as a restricted set, so the SUM is computed over rows in just that one year, not a cumulative total across every year in the Date table.

Trap 2: The sum of sales for the current year on the axis.

The ALL function in the measure removes the year filter that the visual's axis applies, so the measure no longer respects the current year on that axis. Instead, MAX(Date[Year]) is evaluated with the filter removed, yielding the maximum year in the entire Date table, not the year shown in the current row or column of the visual.

Trap 3: A blank because the measure conflicts with the visual filter.

A blank result would require the measure to yield no rows or a BLANK, but this measure always returns a scalar sum. Even if the maximum year had no sales, the SUM would be 0, not blank. There is no inherent conflict between the measure and the visual filter because CALCULATE explicitly modifies the filter context, and the expression is designed to produce a numeric result.

Study all Visualize and analyze the data common traps →

A
The sum of sales for all years.
Why it fails: This option misreads the FILTER predicate. The measure filters Date[Year] to equal MAX(Date[Year]), which selects only the single maximum year, not all years. The FILTER function acts as a restricted set, so the SUM is computed over rows in just that one year, not a cumulative total across every year in the Date table.
B
The sum of sales for the current year on the axis.
Why it fails: The ALL function in the measure removes the year filter that the visual's axis applies, so the measure no longer respects the current year on that axis. Instead, MAX(Date[Year]) is evaluated with the filter removed, yielding the maximum year in the entire Date table, not the year shown in the current row or column of the visual.
C
The sum of sales for the maximum year present in the Date table, regardless of the visual's year filter.
This is correct because ALL(Date[Year]) clears the filter context from the year column, and MAX(Date[Year]) then computes over the full Date table to return the highest year value. The resulting single-year filter is applied to the Sales table through the relationship, producing the sum of sales for that maximum year regardless of any year filter in the visual.
D
A blank because the measure conflicts with the visual filter.
Why it fails: A blank result would require the measure to yield no rows or a BLANK, but this measure always returns a scalar sum. Even if the maximum year had no sales, the SUM would be 0, not blank. There is no inherent conflict between the measure and the visual filter because CALCULATE explicitly modifies the filter context, and the expression is designed to produce a numeric result.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Visualize and analyze the data sessions

Start a Visualize and analyze the data only practice session

Every question in these sessions is drawn from the Visualize and analyze the data domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Visualize and analyze the data questions →Mixed PL-300 session

Frequently asked questions

What does the PL-300 exam test about Visualize and analyze the data?: You must be able to choose the correct visual for a scenario, add and configure slicers or custom visuals, and control how visuals interact. The most important thing is matching the visual and its configuration to the analytical question, especially setting correct geographic data categories for maps.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Visualize and analyze the data questions in a focused session?: Yes — the session launcher on this page draws every question from the Visualize and analyze the data domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other PL-300 topics?: Use the topic links above to move to related areas, or go back to the PL-300 question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the PL-300 exam covers. They are not copied from any real exam or dump site.

Visualize and analyze the data only

10 questions 20 questions 30 questions 50 questions

Mixed PL-300 session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All PL-300 questions Visualize and analyze the data domain overview PL-300 exam guide

Exam traps to avoid

▸Choosing a column or pie chart for correlation when a scatter chart is the correct visual for two numeric measures
▸Assuming a slicer filters only its own visual instead of filtering or highlighting related visuals on the page
▸Leaving geography columns as text without assigning a data category, causing maps to misplace or drop locations

Visualize and analyze the data practice questions

What to know about Visualize and analyze the data

Common Visualize and analyze the data exam traps

Visualize and analyze the data questions

A company has a Power BI report that uses a DirectQuery dataset from an Azure SQL Database. Users report that the report is slow when filtering by date. Which action should you take to improve performance?

A Power BI report uses a composite model with a DirectQuery source and an imported table. The imported table has many rows, and the report is taking a long time to refresh. What is the most likely cause?

A Power BI developer writes the Power Query M code shown in the exhibit. The code runs successfully but returns an error when the user selects a year from a slicer in the report. The error states: 'Expression.Error: The key did not match any rows in the table.' Which is the most likely cause?

Exhibit

A Power BI admin applies the Azure Policy shown in the exhibit. What is the effect of this policy?

Exhibit

A sales manager wants to create a report that shows year-over-year growth for each product category. They have a date table and a sales table with daily sales. Which DAX measure should they use to calculate the previous year's sales?

Which TWO of the following are valid ways to create a measure in Power BI?

Which THREE of the following are best practices for designing Power BI reports for mobile devices?

You are reviewing a Power Query M script that imports sales data. The script filters orders from 2023, groups by CustomerID to sum SubTotal, sorts descending, and takes the top 10 customers. However, the query fails with an error. What is the most likely cause?

Exhibit

Drag and drop the steps to import data from a SQL Server database into Power BI Desktop into the correct order.

Match each data connectivity mode to its description.

Match each DAX function category to an example function.

You have a Power BI report with a date table and a sales table. The above DAX measure is used in a visual that also shows 'Date[Year]' on the axis. What does this measure return?

Exhibit

Track your progress over time

Start a Visualize and analyze the data only practice session

Related PL-300 topic practice pages

Deploy and maintain assets practice questions

Prepare the data practice questions