Microsoft Power BI Data Analyst PL-300 Practice Test 22
Question 210
A semantic model contains unique product rows and repeated sales lines by ProductKey, and product slicers must filter Sales without filtering other product attributes backward. A design reviewer proposes this alternative: Set the relationship inactive and assume product slicers still filter Sales. Which objection BEST explains why it would not satisfy the stated requirement?
- Unneeded bidirectional filtering can create ambiguous paths and performance costs
- Repeated fact keys are normal and do not make the dimension side nonunique
- The unique Product dimension is the one side and its filter flows to repeated transaction rows
- An inactive relationship does not automatically propagate filters to the fact
Explanation
Correct Answer
D:An inactive relationship does not automatically propagate filters to the fact This specifically addresses the deployed or proposed alternative: Set the relationship inactive and assume product slicers still filter Sales.
Incorrect Answers
A:Unneeded bidirectional filtering can create ambiguous paths and performance costs That limitation describes Set both-direction filtering on every relationship by default, not the specified approach.
B:Repeated fact keys are normal and do not make the dimension side nonunique That limitation applies to a different alternative (Use a many-to-many relationship because Sales repeats ProductKey), not the one here.
C:The unique Product dimension is the one side and its filter flows to repeated transaction rows This supports the recommended design but does not diagnose why the specified alternative fails.
Question 211
A DirectQuery report becomes slow because Power Query transformations cause large source tables to be processed locally before filtering. A design reviewer proposes this alternative: Add unnecessary custom per-row transformations before source filters. Which objection BEST explains why it would not satisfy the stated requirement?
- Nonfoldable steps can prevent efficient server-side query execution
- Formatting does not reduce data movement caused by nonfoldable source transformations
- Early materialization can defeat source-side predicate pushdown
- Maintaining folding can let the source execute selective predicates before transferring large data
Explanation
Correct Answer
A:Nonfoldable steps can prevent efficient server-side query execution This specifically addresses the deployed or proposed alternative: Add unnecessary custom per-row transformations before source filters.
Incorrect Answers
B:Formatting does not reduce data movement caused by nonfoldable source transformations That limitation describes Use a measure that only changes result formatting, not the specified approach.
C:Early materialization can defeat source-side predicate pushdown That limitation applies to a different alternative (Buffer the whole source immediately and filter afterward), not the one here.
D:Maintaining folding can let the source execute selective predicates before transferring large data This supports the recommended design but does not diagnose why the specified alternative fails.
Question 212
A monthly table displays a numerical total but the analyst wants a simple percentage-of-grand-total measure without manually building complex DAX. Which Power BI or Power Query action BEST meets the stated requirement?
- Apply Percentage number formatting to the existing total amount
- Create and inspect a Quick measure for percent of grand total
- Use a calculated table containing a fixed percent label
- Use Sort Descending on the visual
Explanation
Correct Answer
B:Quick measures generate DAX for common calculations that can then be reviewed and modified This addresses the specific requirement: a monthly table displays a numerical total but the analyst wants a simple percentage-of-grand-total measure without manually building complex DAX.
Incorrect Answers
A:Percent formatting alone does not divide each value by the overall total This alternative therefore fails an explicit scenario constraint.
C:A fixed calculated label does not respond to report filters This alternative therefore fails an explicit scenario constraint.
D:Sorting does not calculate percentage of any grand total This alternative therefore fails an explicit scenario constraint.
Question 213
Finance wants the cumulative revenue from the start of the year through each month of a report, resetting when the year changes. After the correct solution is implemented, which result provides the MOST DIRECT evidence that the requirement actually works?
- Monthly YTD values accumulate through December and restart at the following year
- The field uses the expected numeric format, but no zero-denominator or date-boundary case was tested
- The DAX expression parses and returns a number for one unfiltered report page
- The measure changes after a slicer click, but the result has not been compared against known test rows
Explanation
Correct Answer
A:Monthly YTD values accumulate through December and restart at the following year This exercises the requested business outcome and the necessary positive or negative boundary.
Incorrect Answers
B:Formatting and a normal case do not validate the edge condition the calculation is supposed to handle.
C:A valid DAX expression may still evaluate the wrong period, denominator or context under filters.
D:Reacting to a slicer does not establish the correct math or intended filter semantics.
Question 214
A Power BI report takes nine seconds to render and the team must find whether a specific visual or DAX query dominates the delay. A pilot instead implemented the following proposed change: Increase the font size of all cards and assume performance improves. The business requirement was not met. Which technical limitation MOST DIRECTLY explains the result?
- Workspace location alone does not diagnose the expensive visual
- Performance Analyzer identifies expensive visual operations and supports targeted optimization
- Removing functionality before measurement can hide the real bottleneck
- Visual typography does not identify the slow query
Explanation
Correct Answer
D:Visual typography does not identify the slow query This specifically addresses the deployed or proposed alternative: Increase the font size of all cards and assume performance improves.
Incorrect Answers
A:Workspace location alone does not diagnose the expensive visual That limitation describes Publish the same report to another workspace without inspecting query timings, not the specified approach.
B:Performance Analyzer identifies expensive visual operations and supports targeted optimization This supports the recommended design but does not diagnose why the specified alternative fails.
C:Removing functionality before measurement can hide the real bottleneck That limitation applies to a different alternative (Disable all page slicers without timing each visual), not the one here.
Question 215
A semantic model contains unique product rows and repeated sales lines by ProductKey, and product slicers must filter Sales without filtering other product attributes backward. A pilot instead implemented the following proposed change: Use a many-to-many relationship because Sales repeats ProductKey. The business requirement was not met. Which technical limitation MOST DIRECTLY explains the result?
- The unique Product dimension is the one side and its filter flows to repeated transaction rows
- An inactive relationship does not automatically propagate filters to the fact
- Repeated fact keys are normal and do not make the dimension side nonunique
- Unneeded bidirectional filtering can create ambiguous paths and performance costs
Explanation
Correct Answer
C:Repeated fact keys are normal and do not make the dimension side nonunique This specifically addresses the deployed or proposed alternative: Use a many-to-many relationship because Sales repeats ProductKey.
Incorrect Answers
A:The unique Product dimension is the one side and its filter flows to repeated transaction rows This supports the recommended design but does not diagnose why the specified alternative fails.
B:An inactive relationship does not automatically propagate filters to the fact That limitation applies to a different alternative (Set the relationship inactive and assume product slicers still filter Sales), not the one here.
D:Unneeded bidirectional filtering can create ambiguous paths and performance costs That limitation describes Set both-direction filtering on every relationship by default, not the specified approach.
Question 216
A measure must calculate revenue only for Internet sales while respecting an existing year slicer. After the correct solution is implemented, which result provides the MOST DIRECT evidence that the requirement actually works?
- Changing Year changes Internet Revenue while Retail sales remain excluded
- The DAX expression parses and returns a number for one unfiltered report page
- The measure changes after a slicer click, but the result has not been compared against known test rows
- The field uses the expected numeric format, but no zero-denominator or date-boundary case was tested
Explanation
Correct Answer
A:Changing Year changes Internet Revenue while Retail sales remain excluded This exercises the requested business outcome and the necessary positive or negative boundary.
Incorrect Answers
B:A valid DAX expression may still evaluate the wrong period, denominator or context under filters.
C:Reacting to a slicer does not establish the correct math or intended filter semantics.
D:Formatting and a normal case do not validate the edge condition the calculation is supposed to handle.
Question 217
A product table is used to calculate a row-level category key at refresh rather than a slicer-dependent aggregate; it must participate in a relationship. A pilot instead implemented the following proposed change: Create only a DAX measure returning the category for each row. The business requirement was not met. Which technical limitation MOST DIRECTLY explains the result?
- A parameter is not a row-by-row category assignment for relationship matching
- A measure produces a context-dependent scalar and cannot be a normal relationship key column
- A persisted per-row attribute can participate as a relationship key after materialization
- A subtitle is a visual label rather than a data model column
Explanation
Correct Answer
B:A measure produces a context-dependent scalar and cannot be a normal relationship key column This specifically addresses the deployed or proposed alternative: Create only a DAX measure returning the category for each row.
Incorrect Answers
A:A parameter is not a row-by-row category assignment for relationship matching That limitation describes Build an unrelated what-if parameter to store category, not the specified approach.
C:A persisted per-row attribute can participate as a relationship key after materialization This supports the recommended design but does not diagnose why the specified alternative fails.
D:A subtitle is a visual label rather than a data model column That limitation applies to a different alternative (Place category text in a report subtitle), not the one here.
Question 218
A sales model needs an explicit Total Revenue measure that sums the existing numeric SalesAmount column under report filters. Which Power BI or Power Query action BEST meets the stated requirement?
- Use COUNTROWS(Sales) as revenue
- Create MAX(Sales[SalesAmount]) to represent total revenue
- Use DISTINCTCOUNT(Sales[ProductKey]) as revenue
- Define a DAX measure such as SUM(Sales[SalesAmount])
Explanation
Correct Answer
D:SUM over the numeric fact column respects report filter context for additive revenue This addresses the specific requirement: a sales model needs an explicit Total Revenue measure that sums the existing numeric SalesAmount column under report filters.
Incorrect Answers
A:Row count measures transactions, not their monetary values This alternative therefore fails an explicit scenario constraint.
B:Maximum transaction value is not the sum of all filtered transactions This alternative therefore fails an explicit scenario constraint.
C:Distinct products are not the sum of sales amounts This alternative therefore fails an explicit scenario constraint.
Question 219
Product campaigns target multiple products and each product can be in multiple campaigns, but the model must filter campaign sales without duplicating fact rows. A pilot instead implemented the following proposed change: Join Campaign directly to each Sales line by a nonunique text label. The business requirement was not met. Which technical limitation MOST DIRECTLY explains the result?
- Repeating dimension keys breaks the one-side uniqueness needed for the normal star
- A bridge represents the many-to-many business membership without blindly joining the fact at a multiplied grain
- Text-label joining can duplicate rows and misattribute sales across campaign membership
- Direct many-to-many without examining grain can create ambiguous or inflated results
Explanation
Correct Answer
C:Text-label joining can duplicate rows and misattribute sales across campaign membership This specifically addresses the deployed or proposed alternative: Join Campaign directly to each Sales line by a nonunique text label.
Incorrect Answers
A:Repeating dimension keys breaks the one-side uniqueness needed for the normal star That limitation applies to a different alternative (Expand campaign memberships into the Product dimension and repeat ProductKey rows), not the one here.
B:A bridge represents the many-to-many business membership without blindly joining the fact at a multiplied grain This supports the recommended design but does not diagnose why the specified alternative fails.
D:Direct many-to-many without examining grain can create ambiguous or inflated results That limitation describes Enable a single many-to-many relationship with no bridge or grain audit, not the specified approach.
Question 220
A report stores one row per sales line but the analyst created a related Customer table with three rows per CustomerID; totals increase unexpectedly. A design reviewer proposes this alternative: Aggregate the Sales fact to one row per CustomerID and delete order detail. Which objection BEST explains why it would not satisfy the stated requirement?
- Collapsing fact grain destroys required transaction-line analysis
- A one-row-per-customer dimension prevents join multiplication when facts link by CustomerID
- Names are nonunique and an extra relationship does not repair customer grain
- Cross-filter direction does not eliminate duplicated dimension members
Explanation
Correct Answer
A:Collapsing fact grain destroys required transaction-line analysis This specifically addresses the deployed or proposed alternative: Aggregate the Sales fact to one row per CustomerID and delete order detail.
Incorrect Answers
B:A one-row-per-customer dimension prevents join multiplication when facts link by CustomerID This supports the recommended design but does not diagnose why the specified alternative fails.
C:Names are nonunique and an extra relationship does not repair customer grain That limitation describes Use CustomerName as a second many-to-many relationship key, not the specified approach.
D:Cross-filter direction does not eliminate duplicated dimension members That limitation applies to a different alternative (Set both-direction filtering to remove duplicated Customer rows), not the one here.