- Which filtering approach satisfies both requirements?
Answer: Filter the percent-of-total table calculation, allowing Tableau to compute all percentages before hiding marks.
Whenever Tableau questions mention "percent of total" alongside filtering, the key tension is when filtering occurs relative to the table calculation. Tableau's order of operations places dimension filters before table calculations, which means filtering too early changes the denominator of your percentage — exactly what this question forbids.
The only approach that lets Tableau compute every category's share of the full total first, then hide marks afterward, is filtering on the table calculation result itself. When you drag the percent-of-total pill to the Filters shelf, Tableau evaluates that filter after the calculation completes. Every category contributes to the 100% denominator, and only the display is trimmed to categories exceeding 10%. That's why D is correct.
A fails immediately: a data source filter removes rows before Tableau even builds the view, so the denominator shrinks to include only the surviving categories, corrupting every percentage.
B makes the same logical mistake at a different stage. An ordinary dimension filter on Category executes before table calculations, so the percent of total recalculates over the filtered subset — the denominator no longer represents all categories.
C is a common trap. Context filters are often presented as a "deeper" filter, but they still execute before table calculations. Making Category a context filter removes non-qualifying categories from the partition the table calculation sees, again altering the denominator.
Study tip: Memorize Tableau's order of operations — Extract → Data Source Filters → Context Filters → Dimension Filters → Measure Filters → Table Calculations. Any filter placed before table calculations in that chain will corrupt a percent-of-total. When the denominator must stay fixed, filter on the calculated field itself. - Assuming no other filters affect the view, what result should be expected?
Answer: Only 3 products remain because the measure filter removes two products without rerunning or backfilling the Top filter.
Whenever you see a question combining a Top N filter with a measure filter in Tableau, your first instinct should be to recall Tableau's order of operations (also called the filter pipeline). Filters execute in a fixed sequence: Top N filters run first, and then measure filters (condition-based filters on aggregates) run afterward on the already-reduced dataset.
Here's how the logic plays out in this scenario: Tableau first applies the Top filter, selecting the top 5 products by SUM(Sales). That gives you a pool of exactly 5 products. Next, the measure filter — requiring SUM(Profit) > 0 — runs against those 5 products and eliminates the two with negative profit. Crucially, Tableau does not loop back and refill the list with replacements. The Top filter already completed its job, and the pipeline moves forward. You're left with 5−2=3 products, making C the correct answer.
A is wrong because the measure filter does not execute before the Top filter — it executes after. There is no "override" mechanism working in reverse here. B describes a backfilling behavior that Tableau simply does not perform; once the Top filter has run, its result is locked, and no substitution occurs. D fabricates a conflict that doesn't exist — filters don't "cancel each other out" just because they reference different measures; they simply execute sequentially and independently.
A useful rule of thumb: memorize Tableau's filter order as Extract → Data Source → Context → Top/Sets → Dimension → Measure → Table Calc. On exam questions mixing filter types, always ask yourself which filter runs first and whether the pipeline cycles back — it never does. - From which records does Tableau determine the top 3 products?
Answer: Records satisfying both East and Consumer, because multiple context filters form an intersected context.
When you see a question about filter order of operations in Tableau, the key concept to anchor on is how context filters work together. A context filter creates a temporary, restricted dataset that all subsequent filters operate against. When you add multiple context filters, they don't work independently — they compound. Each context filter further narrows the same working dataset, so the result is the intersection of all context filter conditions.
In this scenario, the first context filter restricts records to Region = East, and the second context filter then restricts that already-filtered set to Segment = Consumer. By the time Tableau evaluates the Top N filter on Product Name, it's working against only records where both conditions are true simultaneously: East and Consumer. From that intersected pool, Tableau identifies the top 3 products by SUM(Sales). That makes D the correct answer.
A is wrong because context filters don't have a recency-based priority — all active context filters apply together regardless of the order they were added. B describes a union (OR logic), but context filters use AND logic by default; each one narrows the dataset further rather than expanding it with alternatives. C gets the order of operations exactly backwards — Top N filters are downstream from context filters, not upstream, meaning they are calculated after the context has already been established.
A useful rule of thumb: think of context filters as a funnel. Each one you add makes the opening smaller. Whatever comes out the bottom — that's the data your downstream filters, including Top N, actually see. - Which filter retains Customer A and excludes Customer B based on total sales of at least 100?
Answer: Apply a measure filter requiring SUM(Sales) to be at least 100 in the current view.
When filtering in Tableau, you need to distinguish between row-level filters (which evaluate each individual row of data) and measure filters (which evaluate aggregated values after grouping). This question tests exactly that distinction.
Customer A has two rows of $60 each, so their total is 60+60=$120, which meets the ≥$100 threshold. Customer B has one row of $90, which falls short. To make this determination, Tableau must first aggregate the data by customer, then apply the filter — that's precisely what a measure filter on SUM(Sales) does. Choice A is correct because it filters on the aggregated SUM(Sales) per customer, keeping Customer A ($120) and removing Customer B ($90).
Choice B fails because a row-level Boolean filter evaluates each transaction individually. Neither of Customer A's $60 rows meets the $100 threshold, so Customer A would actually be excluded — the opposite of the desired result. Choice C describes a dimension filter on individual Sales values, which doesn't aggregate anything and would simply show or hide specific raw values, not customer totals. Choice D uses AVG(Sales) instead of SUM. Customer A's average is 260+60=$60, which fails the $100 threshold — so this filter would incorrectly exclude Customer A.
A useful rule of thumb: whenever a question asks you to filter based on a total or summary across rows, reach for a measure filter on an aggregate, not a row-level filter. - What sales records contribute to each customer's FIXED value?
Answer: Current-fiscal-year records from all regions, because the data source filter precedes FIXED but the ordinary Region filter follows it.
Whenever you see a question involving LOD expressions in Tableau, your first instinct should be to recall the order of operations: Data Source Filters → Extract Filters → FIXED LODs → Dimension Filters (Context, then ordinary) → Measure Filters. This hierarchy determines exactly which records each filter type "sees."
Because data source filters sit above FIXED LODs in the order of operations, they restrict the underlying data before the FIXED expression ever runs. In this scenario, the data source filter limits records to the current fiscal year — so { FIXED [Customer Name] : SUM([Sales]) } only has access to current-fiscal-year records. Ordinary dimension filters, however, sit below FIXED LODs, meaning the Region filter is applied after the FIXED value is already computed. The FIXED expression therefore aggregates across all regions within the fiscal year, not just West. The Region filter then narrows which customers are displayed, but doesn't change what was computed. This makes C the correct answer: current-fiscal-year records from all regions feed the FIXED calculation.
A is wrong because it inverts both relationships — ordinary filters do not precede FIXED, and data source filters do not follow it. B is wrong because it assumes the ordinary Region filter runs before the FIXED expression, which contradicts Tableau's order of operations; ordinary dimension filters come after FIXED. D is wrong because FIXED expressions do not ignore data source filters — that's a common misconception. Only context filters and ordinary dimension filters are bypassed by FIXED; data source filters always apply first.
A handy study tip: memorize the phrase "Data Source → FIXED → Dimension" as your anchor. Any filter above FIXED restricts it; any filter below it is ignored by it.
- Without changing the calculation, which action will make the selected Region affect the FIXED result?
Answer: Add the Region filter to context so it is applied before the FIXED level-of-detail calculation.
Whenever you see a question about FIXED level-of-detail (LOD) expressions in Tableau, you need to think about the order of operations. Tableau evaluates filters in a specific sequence: context filters → FIXED LODs → dimension filters → measure filters. This hierarchy is the key to understanding why Region isn't working.
Because { FIXED [Customer Name] : SUM([Sales]) } is a FIXED LOD, it executes after context filters but before ordinary dimension filters. This means a Region filter sitting on the Filters shelf as a normal dimension filter has no effect on the LOD — the calculation has already locked in its values for every customer across all regions before Region gets a chance to filter the data.
The fix is A: promoting Region to a context filter forces Tableau to apply it first, narrowing the underlying data before the FIXED LOD computes. Now the calculation only sees records within the selected Region, so customer sales values update as expected.
B is wrong because filter shelf order doesn't change when Tableau evaluates filters relative to LOD calculations — only context promotion does that. Reordering pills on the shelf has no effect on the execution sequence.
C is wrong because "show only relevant values" controls what appears in the filter dropdown UI — it's a display setting, not a data processing instruction, and has no impact on LOD evaluation.
D is wrong because discrete vs. continuous is a visual/formatting property controlling how pills are displayed. It has absolutely no bearing on calculation order.
Your study tip: memorize Tableau's filter order of operations — context → FIXED → dimension — and recognize that "promote to context" is almost always the solution when a FIXED LOD ignores a dimension filter.
- Which change will make the customer condition evaluate using Furniture records only?
Answer: Add the Category filter to context so it restricts the data before the conditional customer filter.
Whenever you see a question about Tableau filters producing unexpected results, think about filter order of operations. By default, dimension filters and conditional filters operate on the full dataset independently — they don't automatically restrict each other unless you use context.
Context filters run first, essentially creating a temporary filtered table that all subsequent filters evaluate against. When you add the Category filter to context (choice A), Tableau processes it before the conditional Customer Name filter. This means when Tableau calculates SUM(Sales) for each customer to check the $10,000 threshold, it only sees Furniture records — exactly the behavior users expect. That's why A is correct.
Choice B has the logic backwards. Adding the conditional Customer Name filter to context would force it to run first, meaning it still evaluates against all categories before Category is even applied. Context helps downstream filters, not the filter placed in context itself.
Choice C — setting Category to show only "relevant values" — controls what appears in the filter dropdown for interactivity purposes. It affects the filter UI, not the underlying data that the customer condition evaluates. This is a common trap: "relevant values" is about display, not computation scope.
Choice D is perhaps the most tempting distractor. Filter shelf order looks like execution order, but it isn't. Tableau doesn't process filters top-to-bottom on the shelf; it follows a fixed order of operations (context → sets → fixed LODs → dimension filters → measure filters). Rearranging the shelf changes nothing about when the condition runs.
Study tip: Memorize Tableau's filter order of operations. "Context first" is one of the most frequently tested concepts — whenever a filter needs to restrict the data that another filter sees, context is the tool. - Which statement correctly describes their conceptual evaluation order?
Answer: The Region dimension filter is evaluated before the SUM(Sales) measure filter, regardless of their pill colors.
Whenever you see a question about Tableau's filter evaluation order, anchor yourself to one core principle: Tableau processes filters in a fixed conceptual sequence based on what type of field is being filtered, not visual styling or shelf position.
The standard order is: Extract filters → Data Source filters → Context filters → Dimension filters → Measure filters → Table Calculation filters. Dimension filters (which filter on discrete categorical fields like Region) are always evaluated before measure filters (which filter on aggregated values like SUM(Sales)). This makes logical sense — Tableau needs to know which rows belong to which dimension members before it can aggregate and filter on those measures. So B is correct: Region, as a dimension filter, is evaluated first, and SUM(Sales), as a measure filter, is evaluated second, regardless of pill color.
Answer A is wrong because "continuous" vs. "discrete" (green vs. blue) does not determine evaluation priority — that distinction relates to how values are visualized, not when they're filtered. A green continuous field still follows the same filter-order rules as its field type dictates. Answer C is wrong on two counts: not all green pills are measures (dates and numeric dimensions can also be continuous/green), and the filter stage is determined by field role, not pill color. Answer D is wrong because Tableau's filter evaluation order is governed by the filter hierarchy described above — vertical position on the Filters shelf has no effect on when filters are applied.
Your study tip: memorize the filter order acronym E-DS-C-D-M-TC (Extract, Data Source, Context, Dimension, Measure, Table Calculation). On exam questions involving filter interactions, this sequence will reliably guide you to the right answer.
- Which change makes the worksheet display the top 5 customers within the selected region?
Answer: Add the Region filter to context so the Top filter evaluates only records from the selected region.
Whenever you see a question about Tableau filters producing unexpected results, think about filter order of operations. By default, Tableau evaluates filters in this sequence: Extract → Data Source → Context → Top N / Condition → Dimension → Measure. The key insight is that Top N filters run before standard dimension filters, which is exactly why this scenario breaks.
Here's what's happening: the Top filter first identifies the 5 highest-spending customers across all regions, then the Region filter trims that list down to only those who happen to be in West — leaving you with just 2. To fix this, you need the Region filter to run first, so the Top filter only "sees" West customers when it calculates the top 5. That's precisely what adding the Region filter to context accomplishes. Context filters execute before Top N filters, so Tableau first isolates West records, then finds the top 5 within that subset. Option A is correct.
Option B is wrong because converting a filter to a measure filter changes when it runs relative to aggregation, not relative to the Top N filter — it doesn't solve the ordering problem described. Option C is wrong because "Show only relevant values" is a dropdown display setting that controls which values appear in the filter card UI; it has no effect on filter evaluation order or Top N logic. Option D is wrong because adding Customer Name to context would place the customer list before the Region filter, which is the opposite of what you need — it doesn't give the Top filter a region-scoped dataset.
A reliable study tip: whenever a Top N filter is returning results from the wrong scope, your first instinct should be to push the scoping filter into context.
- What does this behavior imply about filtering and interactivity?
Answer: The control's available City values are restricted interactively, while the final data still satisfies both ordinary dimension filters.
When working with Tableau filters, it helps to distinguish between how values appear in a filter control and how the underlying query executes. These are two separate mechanisms, and confusing them is exactly what this question tests.
The scenario describes a City filter set to "Only Relevant Values." This is a display-level setting — it narrows which cities appear in the dropdown based on what the State filter has selected. Crucially, this does not change the filter type or execution order. Both State and City remain ordinary dimension filters, and when a view is rendered, Tableau applies both simultaneously to the data. The City control simply hides irrelevant options to improve usability, while the final result still reflects both filters working together. That's precisely what B captures: interactive restriction of the displayed domain, with the underlying data still satisfying both filters.
A is wrong because "Only Relevant Values" does not promote the State filter to a context filter. Context filters are explicitly configured by right-clicking and selecting "Add to Context" — they change the query execution pipeline. Relevant values filtering is purely a UI convenience.
C is wrong because the City filter's classification (dimension vs. measure) is determined by the field type, not by whether its displayed values depend on another filter. It remains a dimension filter regardless.
D is wrong because the State selection is not cosmetic — it actively filters the data in the view. Choosing California immediately restricts the rows Tableau queries.
Study tip: On Tableau questions, always ask yourself whether a behavior affects the query pipeline or just the control's appearance. "Only Relevant Values" touches the display layer only — keep that boundary clear.
