Tableau Quiz: Pivoting Data
15 questions · exam conditions
0:00
Pivoting DataQuestion 1 of 15

8-row table; 5 pivot columns; 2 all null, 3 with no nulls. After pivot, how many rows have non-null Pivot Field Values?

16 rows
40 rows
24 rows
8 rows
← Back to quizzes

Tableau Quiz

Tableau Quiz: Pivoting Data

Practice Pivoting Data 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 Pivoting Data, 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

8-row table; 5 pivot columns; 2 all null, 3 with no nulls. After pivot, how many rows have non-null Pivot Field Values?

  1. 16 rows
  2. 40 rows
  3. 24 rows (correct answer)
  4. 8 rows
Explanation: Each original row becomes one pivoted row for each of the 5 pivot columns, so 8 x 5 = 40 total rows. The 3 pivot columns with no nulls each supply a non-null Pivot Field Value for all 8 rows: 3 x 8 = 24. The 16 rows from the 2 all-null columns have null Pivot Field Values, so 40 total is tempting but 24 is the count you need.

Question 2

In a table with Order ID, Sales, Profit, you pivot Sales and Profit. What happens to Order ID?

  1. Repeats on each pivoted row (correct answer)
  2. It is removed with the pivot
  3. Averaged across pivot rows
  4. Renamed Pivot Field Names
Explanation: When you pivot Sales and Profit, those fields are transformed from columns into rows; Order ID stays as a dimension and repeats on each new row so each value can be matched to its order. The tempting mistake is thinking Order ID is renamed to Pivot Field Names, but that new field holds only the pivoted field names, not Order ID.

Question 3

After pivoting Jan-Dec columns with missing values, you filter Pivot Field Names. What values appear?

  1. Aggregated monthly totals
  2. Only the non-null months
  3. The original row values
  4. Every selected column name (correct answer)
Explanation: Pivot Field Names stores each selected original column header, while Pivot Field Values stores the corresponding cell data. So filtering Pivot Field Names keeps the column names you selected, such as Jan through Dec, regardless of whether cells are null. The tempting wrong answer is 'only the non-null months,' but missing values affect the value field, not the name field.

Question 4

On the Data Source page, pivot Jan and Feb in a table with Region, Manager, Jan, Feb. What is the schema?

  1. Only Region and Manager remain
  2. Region, Manager, Names, Values (correct answer)
  3. One new pivot column per month
  4. Jan and Feb remain as columns
Explanation: Selecting Jan and Feb and choosing Pivot reshapes those columns into two new columns: Names holds the month names (Jan, Feb), and Values holds the data from those cells. Jan and Feb are removed, while Region and Manager stay as columns. The tempting wrong answer is one new pivot column per month, but pivot doesn't create a column for each month; it creates one column of names and one column of values.

Question 5

A 12-row table has Year, Store, Q1-Q4. You pivot Q1-Q4. How many rows result?

  1. 48 rows; two pivot columns (correct answer)
  2. 12 rows; headers become values
  3. 4 rows; only one per quarter
  4. 48 rows; one pivot column
Explanation: Pivoting Q1-Q4 turns each quarter header into a value and stores its data in a second pivot column, so each original row becomes four rows: 12 x 4 = 48 rows. The tempting wrong answer is 48 rows but one pivot column; that misses the column holding the quarter name from the original headers.

Question 6

A text-file data source contains 120 source rows. Each row has Product ID, Region, Jan Sales, Feb Sales, Mar Sales, and Apr Sales. Twelve of the monthly sales cells are null. On the Data Source page, an analyst pivots the four monthly sales columns.

Assuming no filters or other transformations are applied, what is the resulting structure?

  1. There are 480 rows; Product ID and Region repeat, and the pivot value is null in 12 rows. (correct answer)
  2. There are 468 rows; Product ID and Region repeat, because rows containing null pivot values are omitted.
  3. There are 120 rows; four new pivot value fields replace the original four monthly sales fields.
  4. There are 480 rows; Product ID and Region are combined into the generated pivot field-names field.
Explanation: When Tableau pivots multiple columns on the Data Source page, it reshapes data from wide format to long format. Each original row gets multiplied by the number of pivoted columns — so you should always start by multiplying: 120 rows×4 months=480 rows120 \text{ rows} \times 4 \text{ months} = 480 \text{ rows}. The pivot creates two new fields: a "Pivot Field Names" column (containing the month label) and a "Pivot Field Values" column (containing the sales figure). The non-pivoted columns — Product ID and Region — simply repeat for each new row. The critical insight here is how Tableau handles nulls during a pivot. Unlike some transformations that drop null rows, a standard Tableau pivot preserves them. If a monthly sales cell was null in the source, the pivoted row still exists — the Pivot Field Values cell is just null. That makes A correct: 480 total rows, with Product ID and Region repeating, and 12 of those rows containing a null pivot value. Choice B is a common trap — it assumes null pivot values cause rows to be omitted, dropping the count to 468. Tableau does not filter out nulls during a pivot unless you explicitly add a filter. Choice C misunderstands what pivoting does entirely; it describes a situation where the row count stays the same and the monthly fields are replaced in place, which is not how a long-format pivot works. Choice D incorrectly suggests that Product ID and Region get merged into the pivot field-names column — those non-pivoted fields remain separate and simply repeat. A good rule of thumb: for any pivot question, calculate rows first (original rows × number of pivoted columns), then remember that nulls survive unless a filter is explicitly applied.

Question 7

An analyst connects to a relational database that appears on the Data Source page as a logical table containing two joined physical tables. The columns Jan Budget through Dec Budget all belong to one physical table. Selecting the logical table does not expose the expected Pivot command.

What should the analyst do to perform the pivot in Tableau's data model?

  1. Open the logical table to access its physical layer, then pivot the monthly columns within their physical table. (correct answer)
  2. Convert the relationship to a data blend, then pivot the monthly columns from the secondary data source.
  3. Select fields from both physical tables simultaneously, then pivot them from the logical modeling canvas.
  4. Duplicate the connection, limit it to the monthly columns only, and then pivot those columns as a separate logical table.
Explanation: Tableau's data model has two layers: the logical layer (where you build relationships between tables) and the physical layer (where joins and unions live). This question tests whether you understand that certain data-shaping operations — like Pivot — are only available at the physical layer, not the logical layer. When you're working at the logical layer and select a logical table, Tableau treats it as a single abstract entity. The Pivot option won't appear there because Tableau can't determine which underlying physical table's columns to pivot. To unlock Pivot, you need to double-click into the logical table to open its physical layer, then select the monthly columns within their specific physical table. That's exactly what answer A describes, making it correct. Answer B is a red herring. Data blending is a connection strategy used to combine data from different sources — it has nothing to do with enabling the Pivot command and would unnecessarily complicate the workflow. Answer C is wrong because the logical canvas doesn't support multi-table column selection for pivoting; fields from different physical tables can't be simultaneously pivoted from that layer. Answer D introduces an unnecessary workaround — duplicating the connection creates redundancy and maintenance overhead when the real solution is simply navigating into the existing physical layer. A useful rule of thumb: whenever a data-shaping option (Pivot, Union, custom SQL) seems "missing" in Tableau, ask yourself which layer you're working in. Most granular transformations require dropping into the physical layer. Recognizing this two-layer architecture is a reliable signal for a whole category of Tableau exam questions.

Question 8

An analyst pivots Q1, Q2, Q3, and Q4 on the Data Source page, then determines that the workbook must return to the original wide structure. No extract or source file has been externally modified.

Which action most directly restores the original quarterly columns?

  1. Pivot the generated Pivot Field Names and Pivot Field Values fields to reverse the original transformation.
  2. Remove the pivot operation from the Data Source page, restoring the selected source columns to the grid. (correct answer)
  3. Hide Pivot Field Names and Pivot Field Values, allowing Tableau to redisplay Q1 through Q4 automatically.
  4. Delete Pivot Field Names and retain Pivot Field Values, which Tableau expands into the original columns.
Explanation: When working with Tableau's pivot feature on the Data Source page, it helps to think of the pivot as a reversible transformation step — not a permanent restructuring of your data. The pivot wizard simply instructs Tableau to reshape columns into rows at connection time, and that instruction can be removed just as easily as it was added. Removing the pivot directly from the Data Source page is the most straightforward restoration path. When you select the pivoted columns and choose to remove the pivot, Tableau discards the transformation step entirely, and Q1, Q2, Q3, and Q4 reappear as independent columns in the grid — exactly as they existed before. No external file changes are needed because the source data was never altered; only Tableau's instructions for reading it changed. This makes B the correct answer. Choice A sounds plausible but reflects a misunderstanding: you cannot "reverse" a pivot by pivoting the generated fields. Pivoting Pivot Field Names and Pivot Field Values would create a new, differently shaped table — not restore the original wide format. Choice C is incorrect because hiding fields in Tableau only removes them from views; it does not change the underlying data structure or cause Tableau to regenerate the original columns. Hiding is a display-level action, not a schema-level one. Choice D describes a behavior that simply does not exist — deleting one generated field while retaining the other produces an incomplete dataset, and Tableau has no mechanism to "expand" a single values column back into multiple named columns automatically. As a study tip, remember that on Tableau's Data Source page, pivots are connection-level steps that can be undone without touching the source file — always look for the remove/undo option before assuming you need to manipulate the data externally.

Question 9

Two files, Forecast_2025 and Forecast_2026, each contain one row per product and the columns Product ID, Jan, Feb, and Mar. The analyst needs one long data source with a row for each product, year, and month.

Which sequence most appropriately restructures the files while retaining the distinction between years?

  1. Join the files on Product ID, then pivot all six month columns without preserving either file's year identity.
  2. Union the files, pivot the year-identifying field, and leave Jan, Feb, and Mar as separate measures.
  3. Pivot Product ID in each file, then join the resulting Pivot Field Values fields to determine the year.
  4. Union the files, retain or derive the source-file year, then pivot Jan, Feb, and Mar into monthly rows. (correct answer)
Explanation: When reshaping multi-file data in Tableau Prep or Tableau Desktop, your goal is to preserve all meaningful dimensions — in this case, both the year (which file the row came from) and the month (Jan, Feb, Mar). The cleanest workflow stacks the files first, then reshapes the columns. That's exactly what D describes. Unioning the two files stacks them vertically into one table, and because each file represents a different year, you can retain or derive a "Year" field from the source file name or a calculated field. Once year identity is preserved as its own column, you pivot Jan, Feb, and Mar — turning those three column headers into row values — giving you the final long format: one row per product, per year, per month. A goes wrong by joining on Product ID instead of unioning. A join creates wide data — you'd end up with six month columns side by side (Jan from 2025, Jan from 2026, etc.), and pivoting them loses the clean separation of years because they're now mixed across a single row per product. B is close but subtly wrong. After a union, there is no "year-identifying field" to pivot — the year isn't stored as column headers, it's a value you need to retain, not pivot. Pivoting a non-existent column structure leaves Jan, Feb, and Mar as separate wide measures rather than monthly rows. C is a red herring. Pivoting Product ID makes no logical sense — Product ID is an identifier, not a measure to be unpivoted. Joining on the resulting pivot fields would scramble the data entirely. Remember: Union stacks rows, Join adds columns. When combining files that represent the same structure across time, union is almost always the right first step.

Question 10

A source has Customer ID, Customer Name, Jan Units, Feb Units, and Mar Units. While selecting fields for a pivot, an analyst accidentally includes Customer ID with the three monthly unit columns but leaves Customer Name unselected.

What is the most important consequence, and what correction should the analyst make?

  1. Customer ID becomes a duplicated dimension beside Customer Name; hide the duplicate and keep the existing pivot.
  2. Customer ID remains an identifier because Tableau detects unique fields; rename Pivot Field Values to Customer ID.
  3. Customer ID becomes one member of Pivot Field Names; remove the pivot and repivot only the three monthly columns. (correct answer)
  4. Customer ID is silently excluded because Tableau only pivots numeric fields; no correction is needed.
Explanation: When working with Tableau's pivot feature, the key concept to understand is that pivoting is a structural transformation — Tableau treats every selected field as data to be unpivoted into rows, regardless of whether it's numeric or a text-based identifier. This question tests whether you understand what happens when a non-measure field gets swept into a pivot accidentally. When Customer ID is included alongside Jan Units, Feb Units, and Mar Units, Tableau has no way to distinguish intent — it simply pivots all four fields. Customer ID becomes just another member listed under Pivot Field Names (alongside "Jan Units," "Feb Units," "Mar Units"), and its corresponding values appear in Pivot Field Values. Your data loses its row identifier entirely, making the pivot structurally broken and analytically useless. The only real fix is to undo the pivot and redo it with only the three monthly columns selected. That makes C correct. Choice A is wrong because Customer ID doesn't persist as a separate dimension column — it gets absorbed into the pivot structure, not duplicated beside another field. Choice B reflects a fictional Tableau behavior; the software has no mechanism to detect "unique fields" and preserve them as identifiers automatically. Choice D is the most tempting trap — many people assume Tableau only pivots numeric fields, but that's false. Tableau pivots whatever you select, including strings and IDs, which is precisely why the accidental inclusion causes a real problem. The study tip here: always double-check your field selection before pivoting. Any field included in the pivot selection becomes pivot data — Tableau won't protect identifiers for you.

Question 11

A worksheet source has one row per store and contains Store ID, City, State, Sales 2024, Sales 2025, and Sales 2026. The required analysis needs Year as a row-level field and Sales as a single measure while preserving each store's identity.

Which fields should the analyst select before choosing Pivot on the Data Source page?

  1. Store ID, City, and State, because these fields define the level of detail of each source row.
  2. Sales 2024, Sales 2025, and Sales 2026, leaving the store-identifying fields outside the pivot. (correct answer)
  3. State and the three sales fields, because State must be included to preserve geographic grouping.
  4. All six fields, because every source column must participate in a wide-to-long pivot operation.
Explanation: When Tableau performs a pivot on the Data Source page, it transforms selected columns into two new fields: a "Pivot Field Names" column and a "Pivot Field Values" column. The critical concept here is that only the columns you select get collapsed — everything left unselected becomes a repeating identifier that anchors each new row. Your job is to select exactly the columns you want unpivoted. Because you want Year and Sales as row-level fields, you should select Sales 2024, Sales 2025, and Sales 2026 — answer B. Tableau will collapse those three columns into one "Pivot Field Names" column (your Year) and one "Pivot Field Values" column (your Sales). Store ID, City, and State are left outside the selection, so Tableau automatically repeats them across each new row, preserving every store's identity at the correct level of detail. Answer A fails because selecting Store ID, City, and State — the identifier columns — would pivot those into names and values, which is the opposite of what you need. Your store context would be destroyed. Answer C makes the mistake of including State inside the pivot selection. State is a store attribute, not a measure to be unpivoted; including it would mangle the geographic data rather than preserve it. Answer D is a common misconception: a wide-to-long pivot never requires all columns. Pivoting all six fields would collapse your identifiers alongside your measures, producing meaningless output. A useful rule of thumb: select only the columns that share the same semantic meaning across different time periods or categories (here, "sales in a given year"). Everything that uniquely identifies a row stays outside the selection.

Question 12

After pivoting the columns Revenue FY23, Revenue FY24, and Revenue FY25, Tableau creates Pivot Field Names and Pivot Field Values. The analyst renames these generated fields to Fiscal Year and Revenue.

What values should the analyst expect in the renamed Fiscal Year field immediately after renaming it?

  1. FY23, FY24, and FY25, because renaming the field automatically removes the shared Revenue prefix.
  2. 2023, 2024, and 2025, because Tableau converts recognizable year text into numeric year values.
  3. Revenue FY23, Revenue FY24, and Revenue FY25, because renaming changes the field name, not its members. (correct answer)
  4. Revenue, Revenue, and Revenue, because Tableau retains the shared portion of each original column name.
Explanation: When working with Tableau's pivot feature, it's essential to distinguish between a field's name and its members (the values stored inside it). These are two completely separate things, and this question tests whether you understand that distinction. When you pivot columns like Revenue FY23, Revenue FY24, and Revenue FY25, Tableau creates a field called Pivot Field Names, which stores the original column headers as row-level values — meaning the strings "Revenue FY23," "Revenue FY24," and "Revenue FY25" become the actual data inside that field. When you rename Pivot Field Names to "Fiscal Year," you are only changing what the field is called in your data pane. The values already written into that field remain exactly as Tableau generated them. So C is correct: you should expect to see Revenue FY23, Revenue FY24, and Revenue FY25 as the members of the Fiscal Year field. Choice A describes a behavior that doesn't exist — Tableau has no automatic mechanism that strips shared prefixes when you rename a field. Choice B is similarly fabricated; Tableau treats those original column headers as plain text strings and does not parse or convert them into numeric year values. Choice D misreads how pivoting works entirely — Tableau doesn't extract or repeat only the shared portion of column names; it preserves each full original header as a distinct value. A helpful rule of thumb: renaming never transforms data, it only relabels the container. If you want to clean up the values inside Fiscal Year (e.g., extract just "FY23"), you'd need a separate calculated field or a data source filter — renaming alone won't do it.

Question 13

A Customer Forecast table has one row per customer with Jan Forecast and Feb Forecast. A Customer Target table has one row per customer with one annual target. The forecast columns are pivoted, producing two rows per customer, and the target table is then physically joined using Customer ID. A view sums Annual Target.

Why can the displayed annual-target total become twice the expected amount?

  1. Pivoting divides each annual target between Jan and Feb, and the physical join then sums both fractions incorrectly.
  2. Pivot Field Values automatically includes the annual target, causing it to be added once for each forecast field.
  3. Pivot Field Names is numeric by default, causing Tableau to aggregate Jan and Feb as duplicate year values.
  4. The physical join repeats each customer's annual target on both post-pivot month rows before the sum is calculated. (correct answer)
Explanation: When you pivot data in Tableau's physical layer, you need to think carefully about what happens to non-pivoted columns during that transformation — because the pivot multiplies rows, and any joined data multiplies right along with it. Here's the core mechanics: a pivot on Jan Forecast and Feb Forecast turns one row per customer into two rows per customer. When you then physically join the Customer Target table on Customer ID, Tableau matches each of those two rows to the same single target record. The result is that each customer's annual target now appears twice in the dataset — once on the January row and once on the February row. When your view sums Annual Target, it adds both copies, doubling the expected total. That's exactly what D describes, and it's the correct answer. A is wrong because the pivot doesn't split or divide the annual target — it doesn't touch that column at all during the pivot operation. The target value remains whole; the problem is repetition, not fractions. B is wrong because Pivot Field Values only captures the values from the columns you selected to pivot (the forecast figures), not unrelated columns like annual target. Annual Target isn't automatically included in the pivot output. C is wrong because Pivot Field Names generates a string column containing label names like "Jan Forecast" and "Feb Forecast" — it has no interaction with numeric aggregation of the target column whatsoever. As a study tip, whenever you see a pivot followed by a join in Tableau, ask yourself: how many times will each joined row appear after the pivot expands my row count? Fan-out duplication is one of the most common data integrity traps in Tableau's physical layer.

Question 14

Before restructuring a source, an analyst uses a calculation equivalent to the row-level sum of Jan Sales, Feb Sales, and Mar Sales. The three monthly columns are then pivoted, so each product-month becomes a separate row.

Which redesign best reproduces a three-month total for each product after the pivot?

  1. Sum Pivot Field Values by Product, with Pivot Field Names filtered to the three desired monthly members. (correct answer)
  2. Reference Pivot Field Names in the original row-level formula so the three removed monthly fields remain available.
  3. Count Pivot Field Values by Product, because the pivot creates exactly three monthly records per product.
  4. Use the maximum of Pivot Field Values by Product, because the pivot consolidates all monthly values into one field.
Explanation: When you pivot columns in Tableau, multiple fields collapse into two new fields: Pivot Field Names (holding the original column headers, like "Jan Sales") and Pivot Field Values (holding the corresponding numeric values). Your original row-level sum formula no longer works directly because those three separate monthly columns no longer exist as fields. The question tests whether you understand how to reconstruct an aggregation across pivoted data. The correct approach is A: after the pivot, each product has three rows — one per month. Summing Pivot Field Values grouped by Product gives you the three-month total, and filtering Pivot Field Names to only the three monthly members ensures you're not accidentally including unrelated pivoted columns if the source contains others. This directly mirrors the original [Jan Sales] + [Feb Sales] + [Mar Sales] logic, now expressed as an aggregation across rows rather than across columns. B is wrong because once columns are pivoted away, they no longer exist as individual fields in the data source — you cannot reference them in a formula. The pivot replaces them entirely. C is wrong because COUNT counts the number of records, not their numeric values. Even if there are exactly three rows per product, counting them gives you 3 for every product regardless of sales amounts — that's not a total. D is wrong because MAX returns only the single highest monthly value, discarding the other two months entirely. That's not a sum. As a study tip: whenever a question involves a pivot, mentally picture the before/after — columns become rows, so column-level math becomes row-level aggregation filtered by the name field.

Question 15

A supported file-based source initially contains monthly columns named Sales_Jan through Sales_Jun. New monthly columns will be appended to the source throughout the year. The workbook should include new Sales_ columns after refresh without manually editing the pivot each month.

Which pivot configuration best satisfies the requirement, assuming the connector supports this feature?

  1. Create a standard pivot of the six existing columns and rely on refresh to append every new numeric field.
  2. Create a wildcard pivot matching Sales_ so newly added columns with that pattern enter the pivot. (correct answer)
  3. Pivot all current fields, including identifiers, and filter Pivot Field Names to values beginning with Sales_.
  4. Rename Pivot Field Values to Sales_, causing refresh to locate source columns with the same prefix.
Explanation: When working with pivots in Tableau's data source editor, the key concept being tested here is wildcard pivots — a feature that lets you define a pattern rather than a fixed list of columns. This is critical whenever your source data is expected to grow with predictably named fields over time. The feature that solves this problem is the wildcard pivot, which allows you to specify a text pattern (like Sales_) so that any column matching that prefix is automatically included in the pivot upon refresh. This means when Sales_Jul, Sales_Aug, and beyond are added to the source file, they join the pivot without any manual intervention — exactly what the requirement demands. Answer B correctly describes this approach. Answer A fails because a standard pivot locks in only the columns you explicitly select at creation time. Refresh does not automatically expand a standard pivot to include newly added fields — you would need to manually add each new column, which defeats the entire purpose. Answer C pivots all fields indiscriminately and then tries to compensate with a filter on field names. This is backwards: you're still pivoting a static selection of columns, and filtering the output doesn't cause new source columns to enter the pivot automatically. It also risks distorting your data model by pivoting identifier fields. Answer D reflects a fundamental misunderstanding — renaming a pivot output field (Pivot Field Values) has no bearing on how Tableau discovers or maps source columns. Column detection is driven by source structure, not by the names you assign to pivot output fields. As a study tip: whenever a question involves dynamic, auto-expanding pivots, think wildcard pivot with a prefix pattern — that's Tableau's built-in solution for schema growth.