Tableau Quiz: Filters And Aggregation Interaction
10 questions · exam conditions
0:00
Filters And Aggregation InteractionQuestion 1 of 10

A Product filter is configured to show the top two products by SUM([Sales]). Across all regions, total sales rank as Alpha 10001000, Beta 900900, Gamma 800800, and Delta 700700. Within East, their sales are Alpha 100100, Beta 800800, Gamma 700700, and Delta 650650. Region is then filtered to East using a standard dimension filter; it is not added to context.

Which products and values will the worksheet display?

Alpha at 100100 and Beta at 800800, because the top-two set is determined before the standard Region filter.
Beta at 800800 and Gamma at 700700, because the top-two set is recalculated within East automatically.
Alpha at 10001000 and Beta at 900900, because the Region filter changes labels but not aggregated values.
Beta at 800800 and Delta at 650650, because Alpha is removed after its East value falls below the others.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Filters And Aggregation Interaction

Practice Filters And Aggregation Interaction in Tableau with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Filters And Aggregation Interaction, giving you a quick way to practice the rules, question types, and explanations that matter most for Tableau.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A Product filter is configured to show the top two products by SUM([Sales]). Across all regions, total sales rank as Alpha 10001000, Beta 900900, Gamma 800800, and Delta 700700. Within East, their sales are Alpha 100100, Beta 800800, Gamma 700700, and Delta 650650. Region is then filtered to East using a standard dimension filter; it is not added to context.

Which products and values will the worksheet display?

  1. Alpha at 100100 and Beta at 800800, because the top-two set is determined before the standard Region filter. (correct answer)
  2. Beta at 800800 and Gamma at 700700, because the top-two set is recalculated within East automatically.
  3. Alpha at 10001000 and Beta at 900900, because the Region filter changes labels but not aggregated values.
  4. Beta at 800800 and Delta at 650650, because Alpha is removed after its East value falls below the others.
Explanation: Whenever you see a question mixing Top N filters with dimension filters in Tableau, the key is understanding filter order of operations. Tableau applies filters in a fixed sequence: context filters → sets/Top N filters → dimension filters → measure filters. This order determines what data each filter "sees." Because the Top N product filter executes before the standard Region dimension filter, it evaluates SUM([Sales]) across all data, not just East. At that stage, Alpha (10001000) and Beta (900900) rank highest globally and are locked into the view as the top-two set. Only after that selection does the Region filter narrow the data to East. The result: Alpha and Beta remain in the view, but their displayed values reflect only their East sales — 100100 and 800800 respectively. That makes A correct. Choice B is tempting but wrong — it assumes the Top N filter recalculates within East, which would only happen if Region were added to context first, promoting it above the Top N filter in execution order. Choice C confuses how filters work: the Region filter absolutely affects aggregated values (Alpha drops from 10001000 to 100100), it just doesn't re-rank which products qualify. Choice D invents a behavior where products are re-evaluated after both filters run — Tableau doesn't retroactively swap out set members based on post-filter rankings. Study tip: Anytime a question involves Top N filters plus a dimension filter, ask yourself: Is that dimension in context? If not, the Top N always evaluates globally first, and you'll see unexpected products paired with surprisingly low values.

Question 2

A worksheet has one mark per Customer and uses the aggregate calculation ATTR([Segment]). Customer A has two Consumer records. Customer B has one Consumer record and one Corporate record. Customer C has two Corporate records. A calculated filter keeps marks where ATTR([Segment]) = "Consumer".

Which customers remain after the filter is applied?

  1. Only Customer B remains because its records contain more than one Segment value.
  2. Customers A and B remain because each has at least one Consumer record.
  3. Only Customer A remains because all records underlying that mark have the Consumer value. (correct answer)
  4. Customers B and C remain because ATTR selects the last Segment value encountered.
Explanation: When you see ATTR() in Tableau, think of it as a strict unanimity check. ATTR([Segment]) evaluates all the underlying row-level values for a given mark and returns the value only if every single row agrees. If there's any disagreement, it returns an asterisk (*). This is the key concept being tested here. With that framework, walk through each customer. Customer A has two Consumer records — unanimous, so ATTR([Segment]) returns "Consumer". Customer B has one Consumer and one Corporate record — disagreement, so it returns *. Customer C has two Corporate records — unanimous, so it returns "Corporate". The filter ATTR([Segment]) = "Consumer" then keeps only marks where the result is exactly "Consumer". That's Customer A alone, making C the correct answer. Answer A is wrong because it misidentifies Customer B as the one that "remains" — in reality, mixed values cause ATTR to return *, which fails the filter, so Customer B is excluded, not kept. Answer B is wrong because it assumes ATTR behaves like a CONTAINS or OR check — it doesn't. Having at least one Consumer record is not enough; all records must match. Answer D is entirely fabricated — ATTR has no concept of "last value encountered." It is not a sequential or row-order function. A useful memory device: think of ATTR as "all-or-nothing." If all rows say the same thing, you get that value. If even one row disagrees, you get *. Whenever you see ATTR in a filter question, immediately ask yourself whether every row under that mark is unanimous.

Question 3

A worksheet initially has one mark per Category and uses a filter requiring SUM([Sales]) >= 500. Furniture contains Chairs sales of 300300 and Tables sales of 250250. Technology contains Phones sales of 450450 and Accessories sales of 100100. At the Category level, both categories pass the filter. Sub-Category is then added to the view while the filter remains unchanged.

What happens after Sub-Category is added?

  1. Both categories remain because each Category total still equals 550550.
  2. Only Technology remains because Phones is closest to the threshold.
  3. No marks remain because each Sub-Category aggregate is below 500500. (correct answer)
  4. Only Chairs and Phones remain because they are the largest members of their categories.
Explanation: When a filter like SUM([Sales]) >= 500 exists in Tableau, the level of detail at which that aggregation is computed depends entirely on the granularity of the current view. This is the core concept being tested: filters evaluate at the mark level, meaning the aggregation recalculates based on whatever dimensions are currently in the view. When only Category is in the view, each mark represents one Category. Furniture's SUM([Sales]) = 300+250=550300 + 250 = 550, and Technology's = 450+100=550450 + 100 = 550. Both pass the ≥500\geq 500 threshold. So far, so good. But once you add Sub-Category, the view now has one mark per Sub-Category within each Category. The filter re-evaluates at this finer grain: Chairs = 300300, Tables = 250250, Phones = 450450, Accessories = 100100. Every single one falls below 500500, so no marks survive the filter — confirming that C is correct. Choice A is the trap most students fall into. It assumes Tableau still uses the Category-level totals after Sub-Category is added, but the view's granularity has changed, so it doesn't. Choice B incorrectly assumes Tableau ranks or compares Sub-Categories against each other rather than applying the threshold filter independently to each mark. Choice D misunderstands the filter entirely — it treats the filter as a "top member" selector rather than an aggregate threshold. The key strategy to remember: whenever a question involves filters and changing dimensions, always ask yourself "at what granularity is this aggregate being computed right now?" The answer changes as the view changes.

Question 4

A worksheet displays SUM([Sales]) by Region. The underlying records are: East—Furniture sales of 200200 and Technology sales of 300300; West—Furniture sales of 500500 and two Technology sales records of 200200 and 250250. A user first filters Category to Technology and then applies a measure filter requiring SUM([Sales]) >= 350.

Which marks remain in the worksheet after both filters are applied?

  1. Only East remains, displayed with sales of 300300.
  2. Only West remains, displayed with sales of 450450. (correct answer)
  3. Both regions remain, displayed with sales of 500500 each.
  4. Both regions remain, displayed with their unfiltered regional totals.
Explanation: When a question involves multiple filters in Tableau, the critical concept to understand is filter order of operations: Dimension filters are applied before Measure filters. This means the data is first restricted by dimension, and then the aggregated values are computed and filtered. Here's how the logic unfolds. The Category filter (a dimension filter) runs first, removing all Furniture records. What remains is East's single Technology record of 300300 and West's two Technology records of 200200 and 250250. Tableau then aggregates these filtered records by Region: East shows SUM=300SUM = 300 and West shows SUM=200+250=450SUM = 200 + 250 = 450. Next, the measure filter SUM([Sales]) >= 350 is applied to those aggregated values. East's 300300 fails the threshold and is removed; West's 450450 passes. Only West survives, displaying 450450 — confirming B is correct. Answer A is wrong because East's Technology total is only 300300, which fails the >= 350 measure filter. Answer C is wrong on two counts: neither region shows 500500, and including East would require it to pass the measure filter, which it doesn't. Answer D is a common trap — it imagines the dimension filter never applied, as if you'd see the original unfiltered regional totals. That misunderstands how filter order works entirely. Your study tip: memorize Tableau's filter order — Extract → Data Source → Context → Dimension → Measure → Table Calc. Exam questions frequently test whether you know that dimension filters reshape the data before measure filters evaluate aggregations.

Question 5

A worksheet displays Customer and the calculation { FIXED [Customer] : SUM([Sales]) }. Customer X has East sales of 100100 and West sales of 300300. Customer Y has East sales of 200200 and no West sales. Region is filtered to East with a standard dimension filter, not a context filter.

What values appear for the customers that remain visible?

  1. Customer X displays 100100, and Customer Y displays 200200.
  2. Customer X displays 400400, and Customer Y displays 200200. (correct answer)
  3. Customer X displays 300300, and Customer Y is removed entirely.
  4. Customer X displays 400400, and Customer Y displays 300300.
Explanation: Whenever you see a FIXED LOD expression on a Tableau exam, ask yourself one critical question: what level of granularity does this calculation lock onto, and does the active filter respect that lock? FIXED LOD expressions compute before standard dimension filters are applied. That means { FIXED [Customer] : SUM([Sales]) } sums all sales per customer across every region — East, West, or otherwise — before the Region filter ever runs. The filter then removes rows from the view, but the FIXED value is already baked in. For Customer X: 100+300=400100 + 300 = 400. For Customer Y: 200+0=200200 + 0 = 200. The Region = East filter hides the West row for Customer X from the view, but since FIXED already computed 400400, that's what appears. Customer Y has only East data, so they remain visible with 200200. This confirms B is correct. A is wrong because it reflects what you'd see if the calculation were a regular SUM([Sales]) aggregation — that would respect the filter and show only East sales (100100 for X, 200200 for Y). The trap here is confusing FIXED with a normal aggregate. C is wrong on both counts: Customer X's FIXED value is 400400, not 300300, and Customer Y isn't removed — they have East sales, so they remain visible. D is wrong because Customer Y has no West sales, so there's nothing extra to add; 200200 is the correct FIXED value, not 300300. Your study tip: memorize the filter order of operations — Context → FIXED → Standard Dimension Filters → INCLUDE/EXCLUDE → Table Calcs. FIXED sitting above standard filters is one of Tableau's most tested concepts.

Question 6

A worksheet has one mark per Customer and displays SUM([Sales]). Customer A has sales records of 300300 and 250250; Customer B has one sales record of 450450; Customer C has sales records of 200200 and 400400. A filter keeps marks where SUM([Sales]) >= 500.

Which statement correctly describes the filtered worksheet?

  1. Customers A and C remain, and all of each customer's sales records contribute to the displayed totals. (correct answer)
  2. Customers A and C remain, but only their individual sales records of at least 500500 contribute.
  3. Only Customer C remains because Customer A has no individual sales record reaching 500500.
  4. All three customers remain because the combined sales across customers exceed the filter threshold.
Explanation: Whenever you see a question about filters in Tableau, ask yourself: at what level of aggregation does this filter operate? A dimension filter on the view works on individual marks, but a measure filter — one applied to an aggregated expression like SUM([Sales]) — evaluates the aggregation after all underlying records have been rolled up for each mark. Here, each mark represents one customer, so SUM([Sales]) is computed per customer before the filter is checked. Customer A totals 300+250=550300 + 250 = 550, Customer B totals 450450, and Customer C totals 200+400=600200 + 400 = 600. The filter SUM([Sales]) >= 500 then compares each customer's already-aggregated total against the threshold. Customers A (550550) and C (600600) pass; Customer B (450450) does not. Crucially, all of each qualifying customer's underlying records contributed to that aggregate — none were excluded individually. This makes A correct. B describes a row-level filter behavior, where only records individually meeting ≥500\geq 500 would count. That's not how aggregate measure filters work — the filter never touches individual rows. C assumes the filter evaluates each sales record separately, which would mean Customer A's records of 300300 and 250250 never reach 500500 alone. Again, this confuses row-level filtering with aggregate filtering. D conflates the filter threshold with a grand total across all customers, which is not how Tableau applies per-mark filters. A useful rule of thumb: if the filter expression contains an aggregate function (like SUM, AVG, or COUNT), it operates on the mark-level aggregate, not on individual data rows.

Question 7

A worksheet contains Region and Category and displays { EXCLUDE [Category] : SUM([Sales]) }. East has Furniture sales of 100100 and Technology sales of 300300. West has Furniture sales of 200200 and Technology sales of 400400. Category is filtered to Furniture with a standard dimension filter.

Which values does the EXCLUDE calculation display after filtering?

  1. East displays 400400, and West displays 600600, because EXCLUDE ignores the standard dimension filter and aggregates all records at the Region level.
  2. East displays 100100 and 300300, and West displays 200200 and 400400, because EXCLUDE surfaces each category's contribution separately.
  3. East displays 300300, and West displays 400400, because EXCLUDE retains only the filtered-out category's values.
  4. East displays 100100, and West displays 200200, because the dimension filter removes Technology records before EXCLUDE aggregates the remaining records at the Region level. (correct answer)
Explanation: Whenever you see a Tableau question involving LOD expressions and filters, the key is understanding where each filter type sits in the order of operations. Standard dimension filters are applied before EXCLUDE LOD expressions are evaluated — meaning they restrict the underlying data first, and then the LOD calculation runs on whatever records remain. Here's how that plays out in this scenario. The Category filter is set to Furniture, so Technology records are removed from the dataset entirely before any calculation occurs. With only Furniture records remaining, { EXCLUDE [Category] : SUM([Sales]) } drops Category from the view's level of detail and aggregates Sales at the Region level. East has only $100\$100 in Furniture sales left, so it displays $100\$100. West has only $200\$200, so it displays $200\$200. That confirms D is correct. A is the most tempting trap — it assumes EXCLUDE can "see through" dimension filters the way it can ignore dimensions in the view. It cannot. EXCLUDE only removes view dimensions from its grouping scope; it does not override context filters or standard dimension filters, which have already trimmed the data upstream. B misunderstands what EXCLUDE does altogether — it doesn't surface per-category breakdowns; it collapses them. C invents a behavior where EXCLUDE somehow retrieves only the filtered-out records, which has no basis in how LOD expressions work. A reliable study tip: memorize Tableau's order of operations. Standard dimension filters sit above LOD expressions, so they always restrict data before EXCLUDE, INCLUDE, or FIXED runs. If you need an LOD to override a filter, you must use a context filter or a FIXED expression instead.

Question 8

A worksheet displays COUNTD([Customer]) by Region. East contains Customer A in both Office Supplies and Technology, Customer B in Technology, and Customer C in Office Supplies. West contains Customer A in Office Supplies and Customer D in both Office Supplies and Technology. Category is filtered to Office Supplies.

What distinct-customer counts are displayed after the filter?

  1. East displays 33, and West displays 22.
  2. East displays 22, and West displays 22. (correct answer)
  3. East displays 22, and West displays 33.
  4. East displays 11, and West displays 11.
Explanation: When you see COUNTD() combined with a dimension filter in Tableau, the key question to ask is: after the filter is applied, which distinct values remain in each partition? Here, the Category filter to Office Supplies removes any rows where Category = Technology. That means only Office Supplies transactions survive. Now evaluate each region independently:
  • East: Customer A appears in Office Supplies ✓, Customer B appears only in Technology ✗ (filtered out), Customer C appears in Office Supplies ✓. That leaves 2 distinct customers: A and C.
  • West: Customer A appears in Office Supplies ✓, Customer D appears in Office Supplies ✓. That leaves 2 distinct customers: A and D.
So both regions display 22, making B the correct answer. A is wrong because it credits East with 33 — that would be the pre-filter count including Customer B, who only purchased Technology and is excluded once the filter is applied. C makes the same category of error for West, inflating it to 33 with no basis — West never had three customers even before filtering. D would only be correct if COUNTD were counting something else entirely (like a single overlap value), which misunderstands how distinct counts work across separate regions. Study tip: Always mentally "run the filter first, then aggregate." Filters eliminate rows before COUNTD evaluates them, so any customer who exists only in the filtered-out category disappears completely from the count — they don't contribute a partial value.

Question 9

A worksheet displays the calculated measure SUM([Profit]) / SUM([Sales]) by Region. East has Technology sales of 100100 with profit of 2020 and Furniture sales of 300300 with profit of 3030. West has Technology sales of 200200 with profit of 1010 and Furniture sales of 100100 with profit of 2020. Category is filtered to Technology.

What profit ratios are displayed after the filter?

  1. East displays 12.5%12.5\% and West displays 15%15\%, because the filter averages the two category ratios for each region.
  2. East displays 20%20\% and West displays 20%20\%, because the filter retains only Technology and both regions have the same Technology profit margin.
  3. East displays 12.5%12.5\% and West displays 10%10\%, because both categories' profits and sales are retained in the regional totals.
  4. East displays 20%20\% and West displays 5%5\%, because the filter removes Furniture records before profit and sales are summed for each region. (correct answer)
Explanation: When a dimension filter is applied in Tableau, it removes rows from the underlying dataset before any aggregations are calculated. This means SUM([Profit]) and SUM([Sales]) only accumulate values from the rows that survive the filter — Tableau doesn't pre-compute category-level ratios and then combine them. With Category filtered to Technology only, East's calculation becomes 20/100=20%20 / 100 = 20\%, and West's becomes 10/200=5%10 / 200 = 5\%. That confirms D as the correct answer: Furniture records are excluded entirely, so only Technology profit and sales feed into each region's aggregation. A is wrong because Tableau doesn't average pre-computed ratios across categories. Ratio measures like this are calculated on the aggregated totals, not as averages of sub-group ratios — a classic weighted vs. simple average trap. B is partially right that only Technology is retained, but wrong about the outcome. East has 20/100=20%20/100 = 20\% and West has 10/200=5%10/200 = 5\% — these are not equal. The distractor tricks you into thinking both regions must share the same margin just because they share the same filtered category. C describes a scenario where the filter doesn't work, as if both Furniture and Technology data remain in the totals. This would only be possible if Context Filters or table calculations were involved — not a standard dimension filter on a worksheet. A useful rule of thumb: in Tableau, dimension filters act like a WHERE clause in SQL — they strip rows first, then aggregations run on what's left. Always trace the data flow in that order.

Question 10

A worksheet shows regional sales and a Percent of Total table calculation. Sales are East 5050, West 3030, and South 2020. A table-calculation filter then retains marks whose calculated Percent of Total is at least 25%25\%.

After the filter is applied, what percentages are displayed for the visible regions?

  1. East displays 50%50\% and West displays 30%30\%. (correct answer)
  2. East displays 62.5%62.5\% and West displays 37.5%37.5\%.
  3. East displays 50%50\%, West displays 30%30\%, and South displays 20%20\%.
  4. Only East displays 100%100\% because it has the largest original percentage.
Explanation: When working with table calculations and filters in Tableau, the critical concept to understand is when each filter type executes. Table calculation filters are applied after the underlying aggregation is complete, but crucially, they hide marks without recalculating the table calculation across only the visible data. Here's the logic: the original Percent of Total values are East 50%50\%, West 30%30\%, South 20%20\%. The filter removes South (since 20%<25%20\% < 25\%), but the remaining percentages — East 50%50\% and West 30%30\% — stay exactly as computed from all three regions. The table calculation already "saw" all the data; filtering just hides South's mark from view. So answer A is correct: East shows 50%50\% and West shows 30%30\%, which don't sum to 100%100\%. Answer B describes what would happen if the percentages recomputed after filtering — 5080=62.5%\frac{50}{80} = 62.5\% and 3080=37.5%\frac{30}{80} = 37.5\% — but table calculation filters do not trigger recomputation. That behavior would occur with a regular dimension filter, not a table calculation filter. Answer C is wrong because South is correctly excluded by the filter (its 20%20\% falls below the 25%25\% threshold). Answer D invents behavior that doesn't exist; no normalization to 100%100\% occurs, and East's dominance doesn't collapse the other values. A useful rule of thumb: table calculation filters hide, they don't recompute. On the Tableau exam, whenever you see a question combining table calculations with filters, ask yourself whether the filter type recalculates the underlying math or simply suppresses marks from view.