The answer is a hardcoded year value in the M code that does not match the year passed by the slicer. This error occurs because the Power Query M query uses a literal key—such as “2021”—in a table lookup or filter step, but when the user selects a different year from the slicer, the M code attempts to retrieve a row for that new key, which does not exist in the source table. On the PL-300 exam, this scenario tests your understanding of parameterization in Power Query: the trap is that the code runs successfully during development with a fixed value, but fails dynamically when the slicer changes the input. Remember that any M step referencing a hardcoded value instead of a dynamic parameter will break as soon as the slicer passes a different value. Memory tip: “Hardcoded keys break dynamic slicers—always parameterize your lookups.”
PL-300 Visualize and analyze the data Practice Question
This PL-300 practice question tests your understanding of visualize and analyze the data. The scenario asks you to isolate a root cause — eliminate options that address a different problem before choosing. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
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
```
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?
Clue words in this question
Noticing these words before you look at the options changes how you read each choice.
Clue: "most likely"
Why it matters: Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.
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
```
A
The table name Sales does not exist in the database
Why wrong: The code runs successfully initially, so the table exists.
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 is static and doesn't respond to slicer changes, leading to an error if the source doesn't have that year.
C
The ProductID column has duplicate values
Why wrong: Duplicates don't cause key errors in Table.Group.
D
The data type of the Year column is text instead of number
Why wrong: If data type mismatch, the filter would still return empty table, not a key error.
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The code hardcodes the year 2021, but the slicer passes a different year, causing the M code to fail when the source is queried
Option B is correct because the error 'The key did not match any rows in the table' occurs when a Power Query M query uses a hardcoded value (e.g., 2021) in a filter or lookup step, but the slicer passes a different year value to the report. When the slicer changes the parameter, the M code tries to retrieve data for that year, but the hardcoded key does not exist in the source table, causing the key lookup to fail. This is a classic parameterization issue where the M code should use a dynamic reference to the slicer value instead of a literal.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
✗
The table name Sales does not exist in the database
Why it's wrong here
The code runs successfully initially, so the table exists.
✓
The code hardcodes the year 2021, but the slicer passes a different year, causing the M code to fail when the source is queried
Why this is correct
The M code is static and doesn't respond to slicer changes, leading to an error if the source doesn't have that year.
Clue confirmation
The clue word "most likely" in the question point toward this answer.
Related concept
Read the scenario before looking for a memorised answer.
✗
The ProductID column has duplicate values
Why it's wrong here
Duplicates don't cause key errors in Table.Group.
✗
The data type of the Year column is text instead of number
Why it's wrong here
If data type mismatch, the filter would still return empty table, not a key error.
Common exam traps
Common exam trap: answer the scenario, not the keyword
The trap here is that candidates often confuse a key-not-found error with a data type mismatch or missing table error, but the specific phrasing 'key did not match any rows' points to a lookup or filter operation where the key value is not present in the source, not a structural or type issue.
Detailed technical explanation
How to think about this question
Under the hood, Power Query M uses the Table.SelectRows or Table.NestedJoin functions with key matching; when a hardcoded value is used in a filter predicate (e.g., Table.SelectRows(Sales, each [Year] = 2021)), changing the slicer to a different year causes the M code to re-evaluate with that new value, but if the source table does not contain that year, the filter returns an empty table, which then fails in a subsequent step that expects a match (e.g., Table.First or a merge). In real-world scenarios, this often happens when developers hardcode parameters in M instead of using a parameter table or a slicer-driven dynamic filter, leading to brittle queries that break when user selections change.
KKey Concepts to Remember
Read the scenario before looking for a memorised answer.
Find the constraint that changes the correct option.
Eliminate answers that are true in general but not in this case.
TExam Day Tips
→Watch for words such as best, first, most likely and least administrative effort.
→Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
How this comes up in practice
A cloud solutions architect for a retail company is evaluating services for a new workload. The correct answer here reflects best practice for the specific scenario described — not a general cloud recommendation. Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option. Cloud exam questions reward reading the constraint carefully: the same technology can be right or wrong depending on the use case.
What to study next
Got this wrong? Here's your next step.
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Visualize and analyze the data — This question tests Visualize and analyze the data — Read the scenario before looking for a memorised answer..
What is the correct answer to this question?
The correct answer is: The code hardcodes the year 2021, but the slicer passes a different year, causing the M code to fail when the source is queried — Option B is correct because the error 'The key did not match any rows in the table' occurs when a Power Query M query uses a hardcoded value (e.g., 2021) in a filter or lookup step, but the slicer passes a different year value to the report. When the slicer changes the parameter, the M code tries to retrieve data for that year, but the hardcoded key does not exist in the source table, causing the key lookup to fail. This is a classic parameterization issue where the M code should use a dynamic reference to the slicer value instead of a literal.
What should I do if I get this PL-300 question wrong?
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Are there clue words in this question I should notice?
Yes — watch for: "most likely". Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.
What is the key concept behind this question?
Read the scenario before looking for a memorised answer.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
This PL-300 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PL-300 exam.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.