Tableau Quiz: Table Calc Compute Using

10 questions · exam conditions

0:00

Table Calc Compute UsingQuestion 1 of 10

A worksheet initially has Region on Rows and Month on Columns. A running total must always progress by Month and restart by Region. The author expects users to rearrange the view later by moving Month to Rows beneath Region.

Which configuration is most likely to preserve the intended addressing and partitioning after that rearrangement?

Use Table (Across), because Month begins on the Columns shelf

Use Table (Down), because Month will eventually be placed on Rows

Use Pane (Across), because Region always defines a visible pane

Use Specific Dimensions with Month selected and Region unselected

← Back to quizzes

Tableau Quiz

Tableau Quiz: Table Calc Compute Using

Practice Table Calc Compute Using 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 Calc Compute Using, 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

Which configuration is most likely to preserve the intended addressing and partitioning after that rearrangement?

Use Table (Across), because Month begins on the Columns shelf
Use Table (Down), because Month will eventually be placed on Rows
Use Pane (Across), because Region always defines a visible pane
Use Specific Dimensions with Month selected and Region unselected (correct answer)

Explanation: When a question asks about table calculations surviving a structural rearrangement of the view, you need to think about addressing stability. Relative addressing modes like "Table (Across)" or "Pane (Down)" are defined by the physical layout of the view — they recalculate based on wherever dimensions happen to sit at that moment. That makes them fragile when users move fields around. Specific Dimensions addressing is the right choice here because it locks the calculation to named fields, not shelf positions. By selecting Month as the addressing dimension and leaving Region unselected, you're telling Tableau: "always compute the running total along Month, and always restart when Region changes." That logic holds whether Month lives on Columns, on Rows beneath Region, or anywhere else — the calculation follows the fields, not the layout. Choice A fails because Table (Across) computes across whatever is physically in the column direction. Once Month moves to Rows, "Across" no longer captures Month's progression — it would follow a different dimension entirely. Choice B has the same structural problem in reverse: Table (Down) is defined by the current vertical layout, and that definition shifts whenever the view changes. Neither relative mode is anchored to a specific field. Choice C, Pane (Across), incorrectly assumes that Region always defines a visible pane boundary in the across direction — pane scope depends on shelf arrangement too, so it's equally vulnerable to rearrangement. The key study tip: whenever you see a question about calculations that must survive user-driven rearrangements, Specific Dimensions is almost always the answer. Relative modes (Table, Pane, Cell) describe positions; Specific Dimensions describes intent.

Question 2

A view lists Product within Region. East has Cedar sales of $90$ , Pine sales of $70$ , and Oak sales of $40$ . West has Cedar sales of $120$ , Pine sales of $60$ , and Oak sales of $80$ . A descending RANK(SUM([Sales])) calculation is configured to compute using Product only.

What ranks are displayed for Pine in East and Pine in West, respectively?

$4$ in East and $5$ in West
$1$ in East and $2$ in West
$2$ in East and $2$ in West
$2$ in East and $3$ in West (correct answer)

Explanation: When you see a RANK calculation configured to compute using Product, Tableau restarts the ranking within each partition defined by the remaining dimension — in this case, Region. This means East and West each get their own independent ranking, and within each region, all three products compete against one another. Let's work through it. In East, the sales are Cedar

90

, Pine

70

, Oak

40

. Ranked descending: Cedar is

1

st, Pine is

2

nd, Oak is

3

rd. In West, the sales are Cedar

120

, Pine

60

, Oak

80

. Ranked descending: Cedar is

1

st, Oak is

2

nd, Pine is

3

rd. So Pine receives rank

2

in East and rank

3

in West — confirming D is correct. A is wrong because ranks of

4

and

5

would only make sense if ranking were computed across all six rows globally, treating the entire table as one partition — that's not what "compute using Product" does. B suggests Pine ranks

1

st in both regions, which would require Pine to have the highest sales in each region — it doesn't. C gives Pine rank

2

in both regions, which is correct for East but ignores that West's data places Oak above Pine, pushing Pine to

3

rd. The key study tip: "Compute using" defines the partition — ranking resets for every group outside that field. Always re-rank the numbers independently for each partition and resist the assumption that the same product earns the same rank across different regions.

Question 3

A view lists Product within Region, with products sorted Alpha then Beta. East has Alpha sales of $100$ and Beta sales of $150$ . West has Alpha sales of $80$ and Beta sales of $120$ . The calculation LOOKUP(SUM([Sales]), -1) computes using Product only.

What results appear for West Alpha and West Beta, respectively?

$150$ for West Alpha and $80$ for West Beta, because the lookup crosses the Region boundary from East Beta into West Alpha
Null for West Alpha and $80$ for West Beta, because each Region is a separate partition and West Alpha has no preceding mark within its partition (correct answer)
Null for West Alpha and $100$ for West Beta, because the lookup references the East Alpha value rather than West Alpha
$80$ for West Alpha and $120$ for West Beta, because the lookup returns each mark's own current sales value

Explanation: Whenever you see LOOKUP() in Tableau, the first question to ask is: what is the partition, and what is the addressing? The partition defines where the table calculation resets, while the addressing defines the direction it moves. Here, the calculation is scoped to Product only, meaning Product is the addressing field and Region acts as the partition. This means the offset restarts independently within each Region — East and West are completely isolated from one another. Within the West partition, the marks are West Alpha and West Beta (in that order). LOOKUP(SUM([Sales]), -1) asks: what is the value one row back? For West Alpha, there is no preceding mark within the West partition — it's the first row — so the result is Null. For West Beta, the preceding mark is West Alpha, which has sales of

80

, so the result is $80$ . That makes B correct. A is wrong because it assumes the lookup crosses the Region boundary, treating East Beta as the row preceding West Alpha. But partitions are walls — the calculation never crosses them. C is wrong for a similar reason: East Alpha's value of

100

is irrelevant to the West partition entirely. D confuses LOOKUP with SUM itself; LOOKUP(..., 0) would return the current row's value, not an offset of

-1

. A useful habit: whenever you see a table calculation, immediately identify the partition and addressing before evaluating any offset. The partition boundary is always a hard reset — no value from another partition ever bleeds through.

Question 4

A worksheet places Category on Rows. On Columns, Region is the outer discrete dimension and Month is nested inside Region. A running total is applied to monthly sales. The analyst wants the total to restart when the view moves from one Region pane to the next, while continuing across the months within each pane.

Which Compute Using option most directly implements this behavior?

Pane (Across), because it addresses months within each Region pane (correct answer)
Table (Across), because it addresses every column in the row
Pane (Down), because it partitions the calculation by Region
Table (Across then Down), because it traverses each pane in sequence

Explanation: When you see a question about running totals in Tableau, your first instinct should be to ask two things: what direction should the calculation move, and where should it reset? Those two questions map directly onto Tableau's "Compute Using" options. A running total that resets at each Region pane but continues across months within that pane is moving horizontally through the columns of a single pane — that's exactly what Pane (Across) does. It treats each Region pane as its own independent universe, computing across the months inside it and then starting fresh when the next Region pane begins. Answer A is correct precisely because the word "pane" gives you the reset boundary (Region), and "across" gives you the direction of traversal (month columns). B is wrong because Table (Across) computes across every column in the entire row — it crosses Region boundaries and never resets, giving you one continuous running total from the first month of the first Region to the last month of the last Region. That's the opposite of what's needed. C is wrong because Pane (Down) moves vertically through rows within a pane, not horizontally across columns. With Category on Rows, this would traverse categories, not months — completely the wrong axis. D is wrong because Table (Across then Down) also ignores pane boundaries, sweeping across the full table and then wrapping to the next row. It doesn't reset at Region panes. A handy tip: in Tableau addressing, "pane" always means reset at pane boundaries, and the direction word — across vs. down — tells you how it moves within that boundary. Memorize that pairing and these questions become straightforward.

Question 5

A worksheet contains four marks arranged conceptually as two rows and two columns. In reading order, the values are top-left $2$ , top-right $3$ , bottom-left $5$ , and bottom-right $7$ . A running total is configured as Table (Across then Down).

What running-total value appears at the bottom-left mark?

$5$ , because the calculation restarts at the beginning of each row
$7$ , because the calculation first moves down the left column
$10$ , because both top-row marks precede the bottom-left mark (correct answer)
$17$ , because the full-table total is repeated on every mark

Explanation: When you see a question about running totals in Tableau, your first move should be identifying the traversal order the calculation uses — because that order determines which marks "come before" any given mark in the accumulation. Table (Across then Down) means Tableau reads left-to-right across an entire row before dropping down to the next row — exactly like reading a page of text. So the order for your four marks is: top-left

(2)

, top-right

(3)

, bottom-left

(5)

, bottom-right

(7)

. A running total accumulates every preceding value in that sequence. By the time you reach the bottom-left mark, two marks have already been visited:

2 + 3 = 5

, and then the bottom-left mark itself contributes

5

, giving a running total of

2 + 3 + 5 = 10

. That confirms C is correct. A describes a "Across" partition that restarts each row — that would apply to Table (Across) only, not Across then Down. With Across then Down, the entire table is one continuous sequence; no row restart occurs. B reflects a confusion with Table (Down then Across), which would traverse the left column first

(2 \to 5)

before moving right. Under that scope, the bottom-left value would be

2 + 5 = 7

— a real result, just from the wrong direction. D would only be true if you selected a Total or Percent of Total quick table calculation across the full table — not a running total. As a study tip, memorize Tableau's four traversal directions as compass paths: Across, Down, Across then Down, and Down then Across. Drawing the arrow sequence on scratch paper during the exam will prevent order-of-operations errors.

Question 6

A view contains Product on Rows with sales of A $10$ , B $30$ , and C $20$ . A running total computes using Product. The analyst then sorts Product in descending order by sales, producing the displayed order B, C, A.

After the sort, what running-total value is shown for Product A?

$10$ , because Product A retains its original calculation position
$30$ , because only A and C precede the original position
$60$ , because the calculation follows the displayed product order (correct answer)
$40$ , because Product B begins a separate sorted partition

Explanation: Whenever you see a question about table calculations in Tableau — especially running totals — the critical concept to internalize is that table calculations respect the current display order, not the original data order. The sort changes what Tableau "sees" when marching through the partition. Here's the logic: after sorting by descending sales, the displayed order becomes B (

30

), C (

20

), A (

10

). A running total accumulates left-to-right (or top-to-bottom) along that new sequence. So Tableau computes: B =

30

, C =

30 + 20 = 50

, A =

50 + 10 = 60

. Product A, appearing last in the sorted view, receives the grand total of

60

. That confirms C is correct. Choice A is the most tempting trap — it assumes the running total is "locked in" to the original order where A appeared first and held a value of

10

. This misunderstands how table calculations work; they are dynamic and recompute whenever addressing or display order changes. Choice B (

30

) doesn't correspond to any coherent calculation path in either the original or sorted order — it seems to confuse A's position with B's raw sales value. Choice D invents a concept called a "sorted partition," which doesn't exist; sorting does not create new partitions or reset accumulation mid-sequence. Study tip: On the Tableau exam, treat sorts, filters, and axis changes as potential triggers that recompute table calculations. Ask yourself: in what order is Tableau now traversing the marks? That traversal order is always your running total's foundation.

Question 7

Four marks have sales values of $10$ , $20$ , $30$ , and $40$ . The analyst applies Percent of Total and changes Compute Using to Cell.

What result should the analyst expect?

The marks display $10$ percent, $20$ percent, $30$ percent, and $40$ percent.
Every mark displays $100$ percent because each cell is its own partition. (correct answer)
The marks display $33.3$ percent, $66.7$ percent, $42.9$ percent, and $57.1$ percent.
Every mark displays $25$ percent because the view contains four displayed marks.

Explanation: When you see a question about Percent of Total with a custom Compute Using setting, your first instinct should be to ask: what is the partition? Table calculations in Tableau compute relative to a defined scope — change that scope, and the result changes entirely. Compute Using: Cell tells Tableau to treat each individual cell as its own self-contained partition. When a mark is the only value in its own partition, it represents

\frac{\text{itself}}{\text{itself}} = 1.0

, or

100\%

. So every mark — whether its raw value is

10

20

30

, or

40

— will display

100\%

. That confirms B is correct. A is tempting because the raw values look like percentages (

10, 20, 30, 40

), but Percent of Total is never just "pass the number through." That answer confuses the underlying data values with a computed result — a classic distractor. C describes percentages that would appear if marks were partitioned into two groups (e.g.,

\frac{10}{30}

and

\frac{20}{30}

for one pair,

\frac{30}{70}

and

\frac{40}{70}

for another), which might reflect a Pane-level computation — not Cell. D reflects what you'd expect from Compute Using: Table (Across) with four equal marks, where each contributes

25\%

of the grand total. That's a different addressing scope entirely. Your study tip: memorize the three main scopes — Table, Pane, and Cell — and what partition each creates. Cell is always the smallest possible partition: one mark, one hundred percent.

Question 8

A worksheet places Region and then Product on Rows and Month on Columns. Each Region-Product combination has one mark per month. The analyst wants a running total that progresses through months but restarts for every Region-Product combination.

When Specific Dimensions is selected for the running total, which configuration produces the intended result?

Select Region, Product, and Month as addressing dimensions.
Select Month only, leaving Region and Product unselected. (correct answer)
Select Region and Product, leaving Month unselected.
Select Product and Month, leaving Region unselected.

Explanation: Whenever you see a question about table calculations in Tableau, the key concept to internalize is the difference between addressing and partitioning. Addressing dimensions define how the calculation moves — the direction it travels across marks. Partitioning dimensions define where it restarts — the boundaries that scope each independent calculation. With "Specific Dimensions" selected, the dimensions you check become the addressing dimensions (the path the running total follows), and the dimensions you leave unchecked become the partitioning dimensions (the restart boundaries). This is the critical inversion that trips up many students. In this scenario, you want the running total to move across months and restart for each Region-Product combination. That means Month should be the addressing dimension — it defines the direction of travel — and Region and Product should be the partitioning dimensions, creating a separate calculation for each unique combination. Option B does exactly this: checking only Month tells Tableau to compute the running total along months, while Region and Product (left unchecked) partition the view, causing the total to restart with each new Region-Product pair. Option A is wrong because selecting all three dimensions — including Region and Product — as addressing dimensions means the calculation traverses across those fields too, eliminating the restart boundaries you need. Option C inverts the logic entirely: checking Region and Product makes them the addressing dimensions, so the calculation moves across products and regions rather than months. Option D partially corrects this by unchecking Region, but leaving Month unchecked means months become a partition boundary, not the direction of travel. A useful mental shorthand: checked = movement, unchecked = restart. When you want a calculation to restart on a field, leave it unchecked.

Question 9

A text view displays one product with Region as the outer column dimension and Month nested inside it. The marks appear in this order: East January $10$ , East February $20$ , West January $5$ , and West February $15$ . For a running total, both Region and Month are selected under Specific Dimensions.

Assuming the displayed order determines the addressing sequence, what value appears at West February?

$15$ , because each Region-Month combination forms a separate partition
$20$ , because the running total restarts when Region changes
$35$ , because West January is excluded from the accumulation
$50$ , because Region and Month are both addressed dimensions (correct answer)

Explanation: When working with table calculations in Tableau, the key distinction is between addressing and partitioning. Addressed dimensions define the sequence across which the calculation moves (what gets accumulated); partitioned dimensions restart the calculation. When you select both Region and Month under Specific Dimensions, both become addressing dimensions — meaning the running total treats every mark as part of one continuous sequence with no restarts. With Region and Month both addressed, Tableau accumulates across all four marks in display order: East January

10

, East February

10 + 20 = 30

, West January

30 + 5 = 35

, West February

35 + 15 = 50

. So the value at West February is

50

, confirming D. Choice A describes a scenario where both dimensions are partitioned, not addressed — each combination would be isolated, showing only its own raw value. Choice B describes addressing only Month while partitioning on Region, which would restart the running total when Region changes, giving West February a value of

5 + 15 = 20

within the West partition alone. Choice C arrives at

35

by computing the running total only through West January, as if West February were the third mark — but West February is the fourth mark, so the full accumulation continues one step further to

50

. A useful study tip: always ask yourself "what restarts the calculation?" If a dimension is addressed, it does not restart — it advances. If a dimension is partitioned, it does restart. Selecting more dimensions as addressed means fewer restarts and a longer, uninterrupted accumulation path.

Question 10

A monthly view displays January sales of $10$ , March sales of $30$ , and April sales of $50$ ; February has no displayed mark. A moving average uses WINDOW_AVG(SUM([Sales]), -1, 0) and computes using Month.

What value is displayed for April, assuming Tableau has not generated a February mark?

$40$ , averaging the current mark with the preceding addressed mark (correct answer)
$30$ , averaging all three displayed months in the partition
$25$ , treating the missing February month as a zero-valued mark
$50$ , because each displayed month automatically forms a partition

Explanation: Whenever you see a question involving WINDOW_AVG with relative offsets, focus on what marks actually exist in the partition — Tableau only operates on marks it has rendered, not on calendar gaps. WINDOW_AVG(SUM([Sales]), -1, 0) tells Tableau to average from one mark before the current mark to the current mark — a two-mark window. The key word is "before," meaning the previous displayed mark, not the previous calendar month. Since February has no mark, the displayed sequence is January

(10)

, March

(30)

, April

(50)

. For April, the current mark is April

(50)

and the one preceding displayed mark is March

(30)

. The average is

\frac{30 + 50}{2} = 40

, making A correct. B is wrong because WINDOW_AVG with offsets (-1, 0) does not span the entire partition — it explicitly restricts the window to two marks. Averaging all three displayed values would require offsets like (-2, 0) or (FIRST(), LAST()). C is wrong because Tableau does not impute a zero for missing calendar dates. If no February mark exists, Tableau simply skips it — there is no phantom zero inserted into the window. D is wrong because each mark does not form its own isolated partition. The partition is defined by the Compute Using dimension (Month), and the offset window slides across that shared partition. As a study tip: always distinguish between calendar positions and mark positions in Tableau window functions — offsets count existing marks, not time intervals.