Tableau Quiz: Table Calculations Running Totals And Averages
15 questions · exam conditions
0:00
Table Calculations Running Totals And AveragesQuestion 1 of 15

The Running Total table calculation is set to Compute Using Cell. What does each cell show?

The original cell value
The grand total value
A running total down
A null or blank value
← Back to quizzes

Tableau Quiz

Tableau Quiz: Table Calculations Running Totals And Averages

Practice Table Calculations Running Totals And Averages 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 Table Calculations Running Totals And Averages, 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

The Running Total table calculation is set to Compute Using Cell. What does each cell show?

  1. The original cell value (correct answer)
  2. The grand total value
  3. A running total down
  4. A null or blank value
Explanation: With Compute Using Cell, Tableau treats each cell as its own independent partition, so there is nothing before it to accumulate. A running total of a single cell is just that cell's original value. The tempting wrong answer is a running total down, but that requires an ordered column of cells, which Cell mode does not use.

Question 2

Which formula gives a trailing 3-month moving average ending at the current month?

  1. RUNNING_AVG(SUM([Sales]))
  2. WINDOW_AVG(SUM([Sales]),-1,1)
  3. WINDOW_AVG(SUM([Sales]),-2,0) (correct answer)
  4. WINDOW_SUM(SUM([Sales]),-2,0)
Explanation: A WINDOW_AVG with offsets -2 and 0 averages the current month plus the two prior months, exactly a trailing 3-month average. The tempting WINDOW_AVG(SUM([Sales]),-1,1) also spans three rows, but includes the next month instead of ending at the current one, so it gives a centered average, not trailing. RUNNING_AVG would be cumulative from the first row.

Question 3

Percent of Total uses Table (Across) in Region-by-Month view; one of three Regions is filtered. What remains true?

  1. All remaining cells total 100%
  2. Each remaining row totals 100% (correct answer)
  3. Original percentages remain
  4. Calculation shows null values
Explanation: With Table (Across), each Region row is its own partition across months, so each cell is divided by that row's total. Removing one Region leaves the other rows' sums unchanged, so each remaining row still adds up to 100%. The common trap is expecting the whole visible table to total 100%; that would require an overall table calculation, not Table (Across).

Question 4

RUNNING_AVG(SUM([Profit])) at row 5 averages which rows?

  1. All rows in that partition
  2. Rows 3 to 5 in the partition
  3. Only row 5 in the partition
  4. Rows 1 to 5 in the partition (correct answer)
Explanation: At row 5, RUNNING_AVG computes the average of SUM(Profit) from the start of the partition through row 5. It is a cumulative calculation, so it includes rows 1 to 5. The tempting wrong answer is a fixed three-row window such as rows 3 to 5, but that is not what running average does.

Question 5

Months on Columns, Regions on Rows. To restart the running total per Region, check which Specific Dimensions boxes?

  1. Check Month only (correct answer)
  2. Check Region only
  3. Check both fields
  4. Check neither field
Explanation: Checking Month only makes Month the addressing dimension and Region the partitioning dimension. The running total resets whenever Region changes, so each region starts over across months. The tempting error is checking both fields, but that makes the calculation continue across Region too, so it won't restart per region.

Question 6

A view shows Furniture 4040, Office Supplies 3535, and Technology 2525 as Percent of Total across Category. Instead of filtering Category directly, the author places a table-calculation filter on the view that evaluates after the Percent of Total calculation and hides the Office Supplies mark.

After Office Supplies is hidden by the table-calculation filter, which result is expected for Furniture?

  1. Furniture remains 40%40\%, and the visible percentages sum to 65%65\%. (correct answer)
  2. Furniture becomes approximately 61.54%61.54\%, and the visible percentages sum to 100%100\%.
  3. Furniture becomes approximately 53.33%53.33\%, and the visible percentages sum to approximately 78.33%78.33\%.
  4. Furniture remains 40%40\%, and Technology automatically adjusts to 60%60\% to restore the total to 100%100\%.
Explanation: Whenever you see a question about table-calculation filters in Tableau, the critical concept to anchor on is when the filter fires relative to the underlying computation. Table calculations — like Percent of Total — run after data aggregation. A table-calculation filter then hides marks after those values are already computed, meaning the source numbers that fed the calculation remain untouched. Here, Percent of Total was computed using all three categories: Furniture 40%40\%, Office Supplies 35%35\%, Technology 25%25\%. When the table-calculation filter hides Office Supplies, it simply removes that mark from the display. Furniture's percentage was already locked in at 40%40\% based on the full dataset. Because the filter doesn't trigger a recalculation, the two visible marks still show 40%40\% and 25%25\%, summing to 65%65\%. That makes A correct — Furniture stays at 40%40\% and the visible total is 65%65\%. Choice B describes what would happen if you used a dimension filter instead, which removes Office Supplies before the Percent of Total calculation, forcing Tableau to redistribute values across only the remaining categories (4065≈61.54%\frac{40}{65} \approx 61.54\%). That's a fundamentally different filter type. Choice C presents a hybrid result with no logical basis in Tableau's architecture — the partial sum of roughly 78%78\% doesn't correspond to either filtering method. Choice D is pure fiction; Tableau has no mechanism that automatically redistributes one category's percentage to another when a mark is hidden. Your study takeaway: always ask when a filter executes in Tableau's order of operations. Dimension filters precede table calculations; table-calculation filters follow them — and that timing changes everything about the output you'll see.

Question 7

A view shows sales by Category: Furniture 4040, Office Supplies 3535, and Technology 2525. A quick table calculation displays Percent of Total across Category. A standard dimension filter then excludes Office Supplies.

Assuming no table-calculation filter or fixed denominator is used, what percent is displayed for Furniture?

  1. Furniture displays 40%40\% because the original denominator is retained.
  2. Furniture displays approximately 53.33%53.33\% after the category filter is applied.
  3. Furniture displays approximately 61.54%61.54\% after the denominator is recomputed. (correct answer)
  4. Furniture displays 65%65\% because that is the remaining sales total.
Explanation: Whenever you see a question combining table calculations with dimension filters in Tableau, the critical concept to understand is when each operation executes. Dimension filters are applied before table calculations in Tableau's order of operations. This means a Percent of Total calculation uses only the data that survives the filter — the denominator is recomputed, not preserved. Here's the math: the original values are Furniture 4040, Office Supplies 3535, Technology 2525, totaling 100100. After the dimension filter removes Office Supplies, only Furniture 4040 and Technology 2525 remain, giving a new total of 6565. The Percent of Total for Furniture is then recomputed as 4065≈61.54%\frac{40}{65} \approx 61.54\%, confirming C is correct. A is wrong because it assumes the original denominator of 100100 is retained. That would only be true if you used a fixed LOD expression or a table-calculation filter — neither of which applies here. B arrives at approximately 53.33%53.33\%, which corresponds to 4075\frac{40}{75}, as if Technology were excluded instead of Office Supplies — a miscalculation of which category was filtered. D states 65%65\%, confusing the remaining sales total (6565) with Furniture's share of that total — a classic mix-up between an absolute value and a percentage. As a study tip: always trace Tableau's order of operations — extract → filters → table calcs → formatting. Dimension filters gut the dataset before table calculations see it, so any ratio-based calc like Percent of Total will always reflect the filtered universe, not the original.

Question 8

A view contains products A, B, and C with sales of 3030, 5050, and 2020, respectively. The products are displayed in descending order of sales, and RUNNING_SUM(SUM([Sales])) computes down the displayed product marks.

What running-total value appears beside product A?

  1. It displays 3030 because A is first alphabetically.
  2. It displays 5050 because the preceding product alone is counted.
  3. It displays 100100 because every product is included in each mark.
  4. It displays 8080 because B precedes A in the displayed sort. (correct answer)
Explanation: Whenever you see a question involving RUNNING_SUM in Tableau, your first instinct should be to check the display order of the marks, not alphabetical order or any other implicit ordering. Table calculations like RUNNING_SUM operate on the visual table exactly as it appears — they follow the sorted sequence row by row. Here, the products are sorted descending by sales: B (5050), then A (3030), then C (2020). RUNNING_SUM(SUM([Sales])) accumulates as it moves down that sequence. At B (row 1), the running sum is 5050. At A (row 2), it adds A's sales to the prior total: 50+30=8050 + 30 = 80. At C (row 3), it reaches 50+30+20=10050 + 30 + 20 = 100. So the value displayed beside product A is 80\mathbf{80}, confirming D is correct. Choice A is wrong because RUNNING_SUM has nothing to do with alphabetical ordering — it strictly follows the visual sort applied to the view. Choice B describes a value of 5050, which would only make sense if the running sum showed only B's sales alone, ignoring accumulation entirely — that misunderstands what "running" means. Choice C gives 100100, which is the grand total appearing beside the last mark (C), not A — a student might pick this if they confuse running sum with a fixed total across all rows. A useful habit: before solving any table calculation problem, mentally write out the rows in their displayed order and simulate the calculation step by step. That single habit catches most traps on these questions.

Question 9

A view shows sales by Segment: Consumer 120120, Corporate −20-20, and Home Office 100100. Percent of Total is computed down Segment using the ordinary signed sum.

Which result should Tableau display for Corporate, and what should the three displayed percentages sum to?

  1. Corporate is −20%-20\%, and the displayed percentages still sum to 100%100\%.
  2. Corporate is approximately −8.33%-8.33\%, and the percentages sum to approximately 83.33%83.33\%.
  3. Corporate is 0%0\%, and the displayed percentages are normalized to 100%100\%.
  4. Corporate is −10%-10\%, and the displayed percentages sum to 100%100\%. (correct answer)
Explanation: When Tableau computes Percent of Total down a dimension, it divides each member's value by the algebraic (signed) sum of all values in the partition — not by the sum of absolute values. That distinction is everything here. Start by finding the denominator: 120+(−20)+100=200120 + (-20) + 100 = 200. Each segment's percentage is simply its value divided by that total. Corporate's share is −20200=−10%\frac{-20}{200} = -10\%. Consumer gives 120200=60%\frac{120}{200} = 60\% and Home Office gives 100200=50%\frac{100}{200} = 50\%. Adding all three: 60%+(−10%)+50%=100%60\% + (-10\%) + 50\% = 100\%. That confirms D — Corporate displays as −10%-10\% and the percentages sum to exactly 100%100\%, which is the mathematical guarantee of this calculation method. A is wrong because −20%-20\% would only result if the denominator were 100100 (the absolute value of Corporate itself makes no sense as a base), not the true signed total of 200200. B is wrong because −8.33%-8.33\% comes from dividing by 240240 (the sum of absolute values: 120+20+100120 + 20 + 100). Tableau does not use absolute values in the denominator for standard Percent of Total, and using that base breaks the 100%100\% sum property. C is wrong because Tableau never coerces negative contributions to zero — it faithfully reflects the signed arithmetic. As a study tip, remember: whenever a partition contains mixed positive and negative values, the signed total can be smaller than individual members, producing percentages outside the [0%,100%][0\%, 100\%] range — but they will always sum to 100%100\%.

Question 10

A view places discrete Year and Month on Rows. Sales are December 2025 4040, January 2026 1010, and February 2026 2020. A running sum uses Specific Dimensions, with Month checked and Year unchecked.

What value does the running sum display for February 2026?

  1. It displays 2020 because each monthly mark forms a separate partition.
  2. It displays 3030 because the running sum restarts for each year. (correct answer)
  3. It displays 7070 because the running sum crosses the year boundary.
  4. It displays approximately 23.3323.33 because all visible marks are averaged.
Explanation: When working with Table Calculations in Tableau, the critical concept to master is partitioning vs. addressing. Partitioning defines where the calculation restarts, while addressing defines the direction it computes across. In "Specific Dimensions," any dimension you check becomes the addressing field (what the calculation moves along), and any dimension you leave unchecked becomes the partition (where it resets). Here, Month is checked (addressing) and Year is unchecked (partitioning). That means Year acts as the partition boundary — the running sum restarts every time the Year value changes. December 2025 runs alone in its partition: 4040. Then a new partition begins for 2026, where January gives 1010 and February accumulates 10+20=3010 + 20 = 30. So the running sum for February 2026 displays 3030, confirming B is correct. A misreads the setup entirely — if each month were its own partition, every mark would simply show its own sales value with no accumulation at all, giving 2020 for February. But Month is the addressing field, not the partition, so values do accumulate within a year. C would be correct only if Year were also checked as an addressing dimension, allowing the calculation to flow across the year boundary and total 40+10+20=7040 + 10 + 20 = 70. Since Year is unchecked, it partitions instead of addresses. D describes an Average table calculation, not a running sum — and averaging across all three marks yields 703≈23.33\frac{70}{3} \approx 23.33, which is a completely different computation type. A useful rule of thumb: unchecked = partition = restart. Memorize that phrase and you'll quickly decode any Specific Dimensions question on the exam.

Question 11

A view contains monthly sales marks of January 1212, February 1818, March 3030, and April 2424. The calculation WINDOW_AVG(SUM([Sales]), -2, 0) is computed across Month in ascending order.

What value does the calculation return for February?

  1. It returns 1515, averaging the two available marks. (correct answer)
  2. It returns 1010, treating the missing prior mark as zero.
  3. It returns 1818, because only the current mark is complete.
  4. It returns null, because the full window is unavailable.
Explanation: When you encounter Tableau table calculation questions, focus on how the window boundaries behave when a mark sits near the beginning of the partition — specifically, whether Tableau shrinks the window or substitutes a default value. WINDOW_AVG(SUM([Sales]), -2, 0) defines a relative window from two marks before the current mark to the current mark. For February (the second mark), looking back two steps would require a mark at position zero (before January), which doesn't exist. Tableau handles this gracefully: it simply averages whatever marks are available within the valid portion of the window. For February, that means January (1212) and February (1818) — two marks — giving 12+182=15\frac{12 + 18}{2} = 15. Answer A is correct. Answer B is wrong because Tableau does not pad missing window positions with zeros. Treating the absent prior mark as 00 would give 0+12+183=10\frac{0 + 12 + 18}{3} = 10, but that reflects a misunderstanding of how the engine handles boundary conditions. Answer C is wrong because February is not isolated to just its own value; January is fully available and falls within the valid window range. Returning 1818 alone would only occur if the window were defined as (0, 0). Answer D is wrong because Tableau does not return null simply because the theoretical full window can't be constructed — it computes the average over all available marks within bounds, which is perfectly valid here. A good rule of thumb: in Tableau, WINDOW_AVG (and similar functions) shrink gracefully at partition edges rather than failing or zero-filling. Watch for distractors that assume stricter, SQL-like null-propagation behavior.

Question 12

A monthly view uses RUNNING_AVG(SUM([Sales])). January has two orders of 4040 and 6060, February has one order of 300300, and March has three orders of 3030, 7070, and 200200. The calculation addresses Month in ascending order.

What value is displayed for March?

  1. It displays approximately 116.67116.67 by averaging all six individual order values across every month.
  2. It displays approximately 233.33233.33 by averaging the three aggregated monthly SUM values. (correct answer)
  3. It displays 300300 by averaging only the February and March monthly totals.
  4. It displays 700700 by accumulating all three monthly SUM values as a running total.
Explanation: When you see RUNNING_AVG combined with an aggregation like SUM, the key question to ask is: what exactly is being averaged? Tableau first computes the aggregate for each partition (here, each month), then the table calculation runs across those aggregated values — not across individual rows. Let's walk through it. January's SUM is 40+60=10040 + 60 = 100. February's SUM is 300300. March's SUM is 30+70+200=30030 + 70 + 200 = 300. The running average for March averages all monthly totals seen so far: 100+300+3003=7003≈233.33\frac{100 + 300 + 300}{3} = \frac{700}{3} \approx 233.33. That confirms B is correct. Choice A is a classic trap — it treats the six individual order values as the inputs, averaging them as 40+60+300+30+70+2006≈116.67\frac{40+60+300+30+70+200}{6} \approx 116.67. But SUM([Sales]) collapses each month into one value before RUNNING_AVG ever touches the data. The table calculation never sees individual rows. Choice C averages only February and March (300+300)/2=300(300 + 300) / 2 = 300, incorrectly omitting January — a running average is cumulative from the start, not a rolling two-period window. Choice D confuses RUNNING_AVG with RUNNING_SUM; summing 100+300+300=700100 + 300 + 300 = 700 would be the running total, not the running average. As a study habit, always mentally separate the two layers in Tableau table calculations: the inner aggregation (what SUM, AVG, etc. does per partition) and the outer table calculation (what RUNNING_AVG does across those results). Mixing these two layers is the most common source of errors on these questions.

Question 13

A monthly view contains marks only for January 100100, March 200200, and April 300300. February has no record, and Show Missing Values is not enabled. The calculation WINDOW_AVG(SUM([Sales]), -2, 0) is computed across Month.

What value is displayed for April?

  1. The value is 200200 because the calculation averages the three existing marks. (correct answer)
  2. The value is 250250 because only March and April fall in the calendar window.
  3. The value is approximately 166.67166.67 because February is treated as zero.
  4. The value is 300300 because the missing month resets the calculation.
Explanation: Whenever you see a question involving WINDOW_AVG (or any window function) in Tableau, the critical concept to anchor on is what counts as a mark. Window functions operate over the marks that actually exist in the view — not over calendar time or theoretical date gaps. Here, Show Missing Values is disabled, so February never appears as a mark. The view contains exactly three marks: January, March, and April. When WINDOW_AVG(SUM([Sales]), -2, 0) is computed for April, it looks back two marks and includes the current mark — meaning it considers the three marks at positions −2-2, −1-1, and 00 relative to April: January (100)(100), March (200)(200), and April (300)(300). The average is 100+200+3003=200\frac{100 + 200 + 300}{3} = 200, making A correct. B is wrong because it assumes the window is calendar-based, including only March and April as if February occupied a real slot. The offsets −2,0-2, 0 count marks, not months. C is wrong because it assumes February is treated as a zero-value mark. Without Show Missing Values enabled, February doesn't exist in the partition at all — it contributes nothing, not even a zero. D is wrong and invents behavior that doesn't exist. Missing months don't "reset" window calculations in Tableau; the function simply skips them. Study tip: Always ask yourself whether a missing date exists as a mark in the view. If Show Missing Values is off, those dates are invisible to window functions — the offsets jump straight from one existing mark to the next.

Question 14

A text view places Region and Product on Rows and Month on Columns. For East–Chairs, sales are January 1010, February 1515, and March 55. For East–Tables, sales are January 100100, February 2020, and March 1010. RUNNING_SUM(SUM([Sales])) uses Table (Across).

What running-total value appears for East–Chairs in March?

  1. The value is 55 because only the March mark is used.
  2. The value is 2020 because February and March are accumulated.
  3. The value is 3030 because the Chairs row is accumulated across months. (correct answer)
  4. The value is 160160 because all East products are accumulated together.
Explanation: When you see a question about RUNNING_SUM in Tableau, the most important thing to identify is the compute using direction, because that determines which marks get accumulated together and which start fresh. Table (Across) means the running sum restarts for each row and accumulates left to right across the columns (months). So for the East–Chairs row, Tableau calculates: January =10= 10, February =10+15=25= 10 + 15 = 25, March =25+5=30= 25 + 5 = 30. The March cell for East–Chairs therefore shows 3030, making C correct. A is wrong because it describes no accumulation at all — that would be the raw SUM([Sales]) value, not a running sum. The whole point of RUNNING_SUM is to aggregate progressively. B is wrong because it only adds February and March (15+5=2015 + 5 = 20), skipping January. A running sum always includes every prior mark in the compute direction — it never drops the earlier values. D is wrong because it confuses Table (Across) with a direction that crosses rows, such as Table (Down) or Table (Across then Down). With Table (Across), each row is its own independent partition. East–Tables' values (100,20,10100, 20, 10) are never mixed into the East–Chairs accumulation. Study tip: Memorize the two things that define any table calculation — the compute using direction (what accumulates) and the restart boundary (what separates partitions). On the Tableau exam, distractors almost always swap these two concepts, so always ask yourself: "What direction am I moving, and where does the calculation reset?"

Question 15

A view places Category on Rows and Region on Columns. East sales are Furniture 3030, Office Supplies 2020, and Technology 5050. West sales are Furniture 6060, Office Supplies 3030, and Technology 1010. Percent of Total is configured as Table (Down).

What percentage is displayed for Technology in the East column?

  1. It displays 25%25\% using all regional sales as the denominator.
  2. It displays 30%30\% using Technology sales across both regions.
  3. It displays 50%50\% using total East sales as the denominator. (correct answer)
  4. It displays approximately 83.33%83.33\% using the Technology row as the denominator.
Explanation: When working with Percent of Total in Tableau, the direction setting — Table (Across), Table (Down), or others — determines what counts as the denominator. "Table (Down)" means Tableau calculates percentages within each column, traveling downward through the rows. So for each region column, all the category values within that column sum to 100%. For the East column, the sales are: Furniture 3030, Office Supplies 2020, and Technology 5050, giving a column total of 30+20+50=10030 + 20 + 50 = 100. Technology's share is therefore 50100=50%\frac{50}{100} = 50\%, confirming that C is correct. Here's why each distractor fails. A describes a denominator built from all regional sales combined (30+20+50+60+30+10=20030+20+50+60+30+10 = 200), which would be a Table (Across the entire table) calculation, not Table (Down). B uses only the Technology row across both regions (50+10=6050+10 = 60) as the denominator — that logic corresponds to Table (Across), which computes percentages horizontally across a row, not vertically down a column. D applies 5060≈83.33%\frac{50}{60} \approx 83.33\%, again using only the Technology row total as the denominator — another Table (Across) pattern, just mislabeled as Table (Down). The key study tip: memorize the axis that each direction "travels." Table (Down) moves vertically, so the denominator is the column total. Table (Across) moves horizontally, so the denominator is the row total. Exam questions will frequently swap these directions to test whether you can identify the correct denominator.