Microsoft Power BI Data Analyst PL-300 Practice Test 15
Question 140
A report must calculate actual average item price across mixed sales quantities, weighted by units sold rather than average invoice price. Which Power BI or Power Query action BEST meets the stated requirement?
- Use SUM(Sales[UnitPrice]) as average price
- Use DIVIDE(SUMX(Sales, Sales[UnitPrice] * Sales[Quantity]), SUM(Sales[Quantity]))
- Use COUNTROWS(Sales) as the unit denominator
- Use AVERAGE(Sales[UnitPrice]) without quantity weights
Explanation
Correct Answer
B:SUMX aggregates line value and DIVIDE uses the correct units denominator for a weighted average This addresses the specific requirement: a report must calculate actual average item price across mixed sales quantities, weighted by units sold rather than average invoice price.
Incorrect Answers
A:Summing price values is not dividing by total units This alternative therefore fails an explicit scenario constraint.
C:Row counts can differ from total units sold across order lines This alternative therefore fails an explicit scenario constraint.
D:Simple averaging weights a one-unit item equally with a thousand-unit item This alternative therefore fails an explicit scenario constraint.
Question 141
A report must calculate actual average item price across mixed sales quantities, weighted by units sold rather than average invoice price. A design reviewer proposes this alternative: Use SUM(Sales[UnitPrice]) as average price. Which objection BEST explains why it would not satisfy the stated requirement?
- SUMX aggregates line value and DIVIDE uses the correct units denominator for a weighted average
- Summing price values is not dividing by total units
- Row counts can differ from total units sold across order lines
- Simple averaging weights a one-unit item equally with a thousand-unit item
Explanation
Correct Answer
B:Summing price values is not dividing by total units This specifically addresses the deployed or proposed alternative: Use SUM(Sales[UnitPrice]) as average price.
Incorrect Answers
A:SUMX aggregates line value and DIVIDE uses the correct units denominator for a weighted average This supports the recommended design but does not diagnose why the specified alternative fails.
C:Row counts can differ from total units sold across order lines That limitation describes Use COUNTROWS(Sales) as the unit denominator, not the specified approach.
D:Simple averaging weights a one-unit item equally with a thousand-unit item That limitation applies to a different alternative (Use AVERAGE(Sales[UnitPrice]) without quantity weights), not the one here.
Question 142
Sales has OrderDate and ShipDate columns but business users need two independent date slicers, one for order month and one for ship month. After the correct solution is implemented, which result provides the MOST DIRECT evidence that the requirement actually works?
- The relationship diagram displays a line between tables, but no matching-key uniqueness test has run
- Changing Order Date and Ship Date slicers independently gives the expected sales intersection
- One aggregate value is nonblank, but filtering has not been tested from each intended dimension
- The model saves successfully, but source keys and report totals have not been reconciled
Explanation
Correct Answer
B:Changing Order Date and Ship Date slicers independently gives the expected sales intersection This exercises the requested business outcome and the necessary positive or negative boundary.
Incorrect Answers
A:A visible relationship is not proof that the dimension key and relationship cardinality are valid.
C:An unfiltered total cannot establish that the model's date roles and cross-filter paths behave as specified.
D:Saving a model does not rule out duplicate dimension rows, ambiguous paths or fact multiplication.
Question 143
A report already filters a set of allowed product colors and the new measure must further require Red without reintroducing Red if it was previously excluded. A design reviewer proposes this alternative: Use REMOVEFILTERS(Product[Color]). Which objection BEST explains why it would not satisfy the stated requirement?
- A normal filter on the same column may replace the existing color selection
- Removing Color filters erases the original user restriction entirely
- KEEPFILTERS intersects the new filter with existing Color selections instead of overwriting them
- A title does not affect DAX filter intersection semantics
Explanation
Correct Answer
B:Removing Color filters erases the original user restriction entirely This specifically addresses the deployed or proposed alternative: Use REMOVEFILTERS(Product[Color]).
Incorrect Answers
A:A normal filter on the same column may replace the existing color selection That limitation applies to a different alternative (Use a normal replacement CALCULATE color filter without KEEPFILTERS), not the one here.
C:KEEPFILTERS intersects the new filter with existing Color selections instead of overwriting them This supports the recommended design but does not diagnose why the specified alternative fails.
D:A title does not affect DAX filter intersection semantics That limitation describes Change only the report title to indicate Red, not the specified approach.
Question 144
A model's bidirectional relationships create multiple filter routes and expensive queries across several fact tables. A design reviewer proposes this alternative: Remove all product relationships and use disconnected tables. Which objection BEST explains why it would not satisfy the stated requirement?
- Disconnecting necessary dimensions breaks normal filtering and measure logic
- Additional fact-to-fact routes can multiply ambiguity rather than fixing it
- Directed dimension-to-fact filtering reduces unnecessary propagation and ambiguity
- Global bidirectionality creates more filter paths and can harm performance
Explanation
Correct Answer
A:Disconnecting necessary dimensions breaks normal filtering and measure logic This specifically addresses the deployed or proposed alternative: Remove all product relationships and use disconnected tables.
Incorrect Answers
B:Additional fact-to-fact routes can multiply ambiguity rather than fixing it That limitation describes Add extra many-to-many relationships between facts, not the specified approach.
C:Directed dimension-to-fact filtering reduces unnecessary propagation and ambiguity This supports the recommended design but does not diagnose why the specified alternative fails.
D:Global bidirectionality creates more filter paths and can harm performance That limitation applies to a different alternative (Set all cross-filter directions to Both), not the one here.
Question 145
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 design reviewer proposes this alternative: Expand campaign memberships into the Product dimension and repeat ProductKey rows. Which objection BEST explains why it would not satisfy the stated requirement?
- Direct many-to-many without examining grain can create ambiguous or inflated results
- A bridge represents the many-to-many business membership without blindly joining the fact at a multiplied grain
- Repeating dimension keys breaks the one-side uniqueness needed for the normal star
- Text-label joining can duplicate rows and misattribute sales across campaign membership
Explanation
Correct Answer
C:Repeating dimension keys breaks the one-side uniqueness needed for the normal star This specifically addresses the deployed or proposed alternative: Expand campaign memberships into the Product dimension and repeat ProductKey rows.
Incorrect Answers
A: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.
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:Text-label joining can duplicate rows and misattribute sales across campaign membership That limitation applies to a different alternative (Join Campaign directly to each Sales line by a nonunique text label), not the one here.
Question 146
Inventory stock is a snapshot recorded daily and monthly totals must show the last available balance, not a sum of all daily balances. After the correct solution is implemented, which result provides the MOST DIRECT evidence that the requirement actually works?
- The field uses the expected numeric format, but no zero-denominator or date-boundary case was tested
- The monthly result equals the final valid day's inventory balance even when the last calendar day has no snapshot
- The measure changes after a slicer click, but the result has not been compared against known test rows
- The DAX expression parses and returns a number for one unfiltered report page
Explanation
Correct Answer
B:The monthly result equals the final valid day's inventory balance even when the last calendar day has no snapshot This exercises the requested business outcome and the necessary positive or negative boundary.
Incorrect Answers
A:Formatting and a normal case do not validate the edge condition the calculation is supposed to handle.
C:Reacting to a slicer does not establish the correct math or intended filter semantics.
D:A valid DAX expression may still evaluate the wrong period, denominator or context under filters.
Question 147
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. Which Power BI or Power Query action BEST meets the stated requirement?
- Set both-direction filtering on every relationship by default
- Set the relationship inactive and assume product slicers still filter Sales
- Use a many-to-many relationship because Sales repeats ProductKey
- Configure a one-to-many Product-to-Sales relationship with single-direction dimension-to-fact filtering
Explanation
Correct Answer
D:The unique Product dimension is the one side and its filter flows to repeated transaction rows This addresses the specific requirement: 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.
Incorrect Answers
A:Unneeded bidirectional filtering can create ambiguous paths and performance costs This alternative therefore fails an explicit scenario constraint.
B:An inactive relationship does not automatically propagate filters to the fact This alternative therefore fails an explicit scenario constraint.
C:Repeated fact keys are normal and do not make the dimension side nonunique This alternative therefore fails an explicit scenario constraint.
Question 148
A product manager wants the same quarter last year compared with the selected quarter this year using a contiguous marked date table. A design reviewer proposes this alternative: Use FIRSTDATE(Date[Date]) as the measure result. Which objection BEST explains why it would not satisfy the stated requirement?
- Year-to-date accumulation is not the comparable prior-year quarter
- The prior-year date-shift table evaluates revenue for corresponding dates one year earlier
- Removing all date filters does not shift to the preceding year
- The first date is not a revenue amount for last year's quarter
Explanation
Correct Answer
D:The first date is not a revenue amount for last year's quarter This specifically addresses the deployed or proposed alternative: Use FIRSTDATE(Date[Date]) as the measure result.
Incorrect Answers
A:Year-to-date accumulation is not the comparable prior-year quarter That limitation applies to a different alternative (Use TOTALYTD([Total Revenue], Date[Date])), not the one here.
B:The prior-year date-shift table evaluates revenue for corresponding dates one year earlier This supports the recommended design but does not diagnose why the specified alternative fails.
C:Removing all date filters does not shift to the preceding year That limitation describes Use ALL(Date) to erase current date filters, not the specified approach.
Question 149
A DAX measure recalculates the same expensive filtered expression three times inside nested IF branches. After the correct solution is implemented, which result provides the MOST DIRECT evidence that the requirement actually works?
- One visual renders faster, but the result totals have not been compared for correctness
- A developer reports the model feels faster, but no before-and-after query trace was collected
- The optimized measure returns the same totals and the targeted query shows reduced repeated computation
- The edited query saves, but the expected folding or model-size effect has not been measured
Explanation
Correct Answer
C:The optimized measure returns the same totals and the targeted query shows reduced repeated computation This exercises the requested business outcome and the necessary positive or negative boundary.
Incorrect Answers
A:An invalidly simplified calculation can be fast while returning wrong results.
B:Perceived speed without measurements cannot establish the claimed optimization.
D:Saving changes does not prove predicate pushdown or storage reduction occurred.
Question 150
A sales model needs an explicit Total Revenue measure that sums the existing numeric SalesAmount column under report filters. A pilot instead implemented the following proposed change: Use COUNTROWS(Sales) as revenue. The business requirement was not met. Which technical limitation MOST DIRECTLY explains the result?
- Distinct products are not the sum of sales amounts
- SUM over the numeric fact column respects report filter context for additive revenue
- Row count measures transactions, not their monetary values
- Maximum transaction value is not the sum of all filtered transactions
Explanation
Correct Answer
C:Row count measures transactions, not their monetary values This specifically addresses the deployed or proposed alternative: Use COUNTROWS(Sales) as revenue.
Incorrect Answers
A:Distinct products are not the sum of sales amounts That limitation applies to a different alternative (Use DISTINCTCOUNT(Sales[ProductKey]) as revenue), not the one here.
B:SUM over the numeric fact column respects report filter context for additive revenue This supports the recommended design but does not diagnose why the specified alternative fails.
D:Maximum transaction value is not the sum of all filtered transactions That limitation describes Create MAX(Sales[SalesAmount]) to represent total revenue, not the specified approach.