Microsoft Power BI Data Analyst PL-300 Practice Test 19
Question 180
A financial report needs dynamic Margin Percent that changes when users slice by company and quarter. A pilot instead implemented the following proposed change: Create a static calculated column for company-wide margin percent. The business requirement was not met. Which technical limitation MOST DIRECTLY explains the result?
- Formatting an amount cannot compute margin divided by revenue
- A measure recalculates under slicers, unlike a stored row value
- A stored calculated column will not recompute a company-wide ratio for changing slicer selections
- A query parameter is not a filter-context-aware report calculation
Explanation
Correct Answer
C:A stored calculated column will not recompute a company-wide ratio for changing slicer selections This specifically addresses the deployed or proposed alternative: Create a static calculated column for company-wide margin percent.
Incorrect Answers
A:Formatting an amount cannot compute margin divided by revenue That limitation describes Format the SalesAmount column as Percentage, not the specified approach.
B:A measure recalculates under slicers, unlike a stored row value This supports the recommended design but does not diagnose why the specified alternative fails.
D:A query parameter is not a filter-context-aware report calculation That limitation applies to a different alternative (Create a Power Query scalar parameter for the quarterly ratio), not the one here.
Question 181
An executive time intelligence report needs consistent full-year month comparisons across multiple fact tables, including months with no transactions. A design reviewer proposes this alternative: Use a Year text column without a true date field. Which objection BEST explains why it would not satisfy the stated requirement?
- Text years cannot independently provide daily date semantics for time intelligence
- A complete calendar provides consistent date granularity and supports time-intelligence semantics
- A fact date list can omit no-sales dates and cannot guarantee a contiguous calendar
- Different incomplete calendars can cause inconsistent period comparisons across facts
Explanation
Correct Answer
A:Text years cannot independently provide daily date semantics for time intelligence This specifically addresses the deployed or proposed alternative: Use a Year text column without a true date field.
Incorrect Answers
B:A complete calendar provides consistent date granularity and supports time-intelligence semantics This supports the recommended design but does not diagnose why the specified alternative fails.
C:A fact date list can omit no-sales dates and cannot guarantee a contiguous calendar That limitation applies to a different alternative (Use Sales transaction dates alone as the calendar), not the one here.
D:Different incomplete calendars can cause inconsistent period comparisons across facts That limitation describes Create a different partial date list for each fact table, not the specified approach.
Question 182
A measure must calculate revenue only for Internet sales while respecting an existing year slicer. A design reviewer proposes this alternative: Use FORMAT([Total Revenue], "Currency") to filter Channel. Which objection BEST explains why it would not satisfy the stated requirement?
- Removing all filters would lose the requested year selection
- CALCULATE modifies the Channel filter while other compatible filters such as Year continue to apply
- FORMAT changes presentation and returns text but does not filter sales rows
- Counting distinct channels is not a channel-specific revenue sum
Explanation
Correct Answer
C:FORMAT changes presentation and returns text but does not filter sales rows This specifically addresses the deployed or proposed alternative: Use FORMAT([Total Revenue], "Currency") to filter Channel.
Incorrect Answers
A:Removing all filters would lose the requested year selection That limitation applies to a different alternative (Use ALL(Sales) to remove every model filter), not the one here.
B:CALCULATE modifies the Channel filter while other compatible filters such as Year continue to apply This supports the recommended design but does not diagnose why the specified alternative fails.
D:Counting distinct channels is not a channel-specific revenue sum That limitation describes Use COUNTROWS(VALUES(Sales[Channel])) instead of revenue, not the specified approach.
Question 183
A report needs to count unique customers making purchases even if a customer places multiple orders. A design reviewer proposes this alternative: Use SUM(Sales[CustomerID]). Which objection BEST explains why it would not satisfy the stated requirement?
- Removing filters produces an unfiltered transaction count, not distinct customers
- A row per transaction can count one customer multiple times
- An identifier should not be summed to represent the number of customers
- Distinct customer counting prevents repeat orders from inflating the customer total
Explanation
Correct Answer
C:An identifier should not be summed to represent the number of customers This specifically addresses the deployed or proposed alternative: Use SUM(Sales[CustomerID]).
Incorrect Answers
A:Removing filters produces an unfiltered transaction count, not distinct customers That limitation describes Use COUNTROWS(ALL(Sales)), not the specified approach.
B:A row per transaction can count one customer multiple times That limitation applies to a different alternative (Use COUNTROWS(Sales) as the customer count), not the one here.
D:Distinct customer counting prevents repeat orders from inflating the customer total This supports the recommended design but does not diagnose why the specified alternative fails.
Question 184
A Category dimension contains duplicate CategoryKey values due to source errors, and Power BI refuses to create the intended one-to-many relationship to Sales. A design reviewer proposes this alternative: Change cardinality to many-to-many and ignore the defective category data. Which objection BEST explains why it would not satisfy the stated requirement?
- The one side of a relationship requires unique key values and a failed refresh can follow duplicates
- Filter direction does not make duplicate one-side keys unique
- A many-to-many relationship hides a bad dimension grain and can distort aggregations
- Fact records are allowed to share a dimension foreign key and should not be deleted
Explanation
Correct Answer
C:A many-to-many relationship hides a bad dimension grain and can distort aggregations This specifically addresses the deployed or proposed alternative: Change cardinality to many-to-many and ignore the defective category data.
Incorrect Answers
A:The one side of a relationship requires unique key values and a failed refresh can follow duplicates This supports the recommended design but does not diagnose why the specified alternative fails.
B:Filter direction does not make duplicate one-side keys unique That limitation describes Use bidirectional filtering to resolve duplicate dimension keys, not the specified approach.
D:Fact records are allowed to share a dimension foreign key and should not be deleted That limitation applies to a different alternative (Make CategoryKey unique by deleting repeated sales transaction lines), not the one here.
Question 185
A sales model needs an explicit Total Revenue measure that sums the existing numeric SalesAmount column under report filters. A design reviewer proposes this alternative: Use DISTINCTCOUNT(Sales[ProductKey]) as revenue. Which objection BEST explains why it would not satisfy the stated requirement?
- SUM over the numeric fact column respects report filter context for additive revenue
- Maximum transaction value is not the sum of all filtered transactions
- Distinct products are not the sum of sales amounts
- Row count measures transactions, not their monetary values
Explanation
Correct Answer
C:Distinct products are not the sum of sales amounts This specifically addresses the deployed or proposed alternative: Use DISTINCTCOUNT(Sales[ProductKey]) as revenue.
Incorrect Answers
A: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.
B: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.
D:Row count measures transactions, not their monetary values That limitation applies to a different alternative (Use COUNTROWS(Sales) as revenue), not the one here.
Question 186
Several measures need the same currency-selection logic and maintenance across report pages, while minimizing duplicated measure definitions. A pilot instead implemented the following proposed change: Copy the same DAX into each of dozens of measures. The business requirement was not met. Which technical limitation MOST DIRECTLY explains the result?
- Duplicating formulas increases maintenance and inconsistency risks
- Source query merging does not centralize calculation-item behavior across measures
- Titles do not transform underlying measure values
- A calculation group can centralize reusable DAX expression transformations over selected measures
Explanation
Correct Answer
A:Duplicating formulas increases maintenance and inconsistency risks This specifically addresses the deployed or proposed alternative: Copy the same DAX into each of dozens of measures.
Incorrect Answers
B:Source query merging does not centralize calculation-item behavior across measures That limitation describes Use a Power Query Merge unrelated to the selected-measure logic, not the specified approach.
C:Titles do not transform underlying measure values That limitation applies to a different alternative (Store the conversion in a static report title), not the one here.
D:A calculation group can centralize reusable DAX expression transformations over selected measures This supports the recommended design but does not diagnose why the specified alternative fails.
Question 187
A report stores one row per sales line but the analyst created a related Customer table with three rows per CustomerID; totals increase unexpectedly. Which Power BI or Power Query action BEST meets the stated requirement?
- Use CustomerName as a second many-to-many relationship key
- Set both-direction filtering to remove duplicated Customer rows
- Aggregate the Sales fact to one row per CustomerID and delete order detail
- Normalize Customer to one current member per key at the intended dimension grain
Explanation
Correct Answer
D:A one-row-per-customer dimension prevents join multiplication when facts link by CustomerID This addresses the specific requirement: a report stores one row per sales line but the analyst created a related Customer table with three rows per CustomerID; totals increase unexpectedly.
Incorrect Answers
A:Names are nonunique and an extra relationship does not repair customer grain This alternative therefore fails an explicit scenario constraint.
B:Cross-filter direction does not eliminate duplicated dimension members This alternative therefore fails an explicit scenario constraint.
C:Collapsing fact grain destroys required transaction-line analysis This alternative therefore fails an explicit scenario constraint.
Question 188
A DirectQuery report becomes slow because Power Query transformations cause large source tables to be processed locally before filtering. 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 traced source query contains the expected selective filter and visual latency improves
- The edited query saves, but the expected folding or model-size effect has not been measured
- A developer reports the model feels faster, but no before-and-after query trace was collected
Explanation
Correct Answer
B:A traced source query contains the expected selective filter and visual latency improves 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.
C:Saving changes does not prove predicate pushdown or storage reduction occurred.
D:Perceived speed without measurements cannot establish the claimed optimization.
Question 189
A report must calculate actual average item price across mixed sales quantities, weighted by units sold rather than average invoice price. A pilot instead implemented the following proposed change: Use AVERAGE(Sales[UnitPrice]) without quantity weights. The business requirement was not met. Which technical limitation MOST DIRECTLY explains the result?
- Row counts can differ from total units sold across order lines
- Summing price values is not dividing by total units
- Simple averaging weights a one-unit item equally with a thousand-unit item
- SUMX aggregates line value and DIVIDE uses the correct units denominator for a weighted average
Explanation
Correct Answer
C:Simple averaging weights a one-unit item equally with a thousand-unit item This specifically addresses the deployed or proposed alternative: Use AVERAGE(Sales[UnitPrice]) without quantity weights.
Incorrect Answers
A: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.
B:Summing price values is not dividing by total units That limitation applies to a different alternative (Use SUM(Sales[UnitPrice]) as average price), not the one here.
D: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.
Question 190
A legacy model contains Sales related bidirectionally to both Geography and Customer, plus another path between Geography and Customer, producing ambiguous filter results. A design reviewer proposes this alternative: Create multiple active alternate paths between the same tables. Which objection BEST explains why it would not satisfy the stated requirement?
- Competing active paths do not automatically resolve ambiguity or produce intended results
- Inactive paths break normal dimension filters rather than resolving the model design
- A clean star filter flow reduces ambiguous propagation paths and makes slicer behavior predictable
- Additional both-direction paths can increase ambiguity and affect performance
Explanation
Correct Answer
A:Competing active paths do not automatically resolve ambiguity or produce intended results This specifically addresses the deployed or proposed alternative: Create multiple active alternate paths between the same tables.
Incorrect Answers
B:Inactive paths break normal dimension filters rather than resolving the model design That limitation describes Turn every relationship inactive, not the specified approach.
C:A clean star filter flow reduces ambiguous propagation paths and makes slicer behavior predictable This supports the recommended design but does not diagnose why the specified alternative fails.
D:Additional both-direction paths can increase ambiguity and affect performance That limitation applies to a different alternative (Set every relationship to Both because more propagation always helps), not the one here.