- In a table with Order ID, Sales, Profit, you pivot Sales and Profit. What happens to Order ID?
Answer: Repeats on each pivoted row
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.
- Which fields should the analyst select before choosing Pivot on the Data Source page?
Answer: Sales 2024, Sales 2025, and Sales 2026, leaving the store-identifying fields outside the pivot.
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.
- What is the most important consequence, and what correction should the analyst make?
Answer: Customer ID becomes one member of Pivot Field Names; remove the pivot and repivot only the three monthly columns.
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.
- Which redesign best reproduces a three-month total for each product after the pivot?
Answer: Sum Pivot Field Values by Product, with Pivot Field Names filtered to the three desired monthly members.
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.
- 8-row table; 5 pivot columns; 2 all null, 3 with no nulls. After pivot, how many rows have non-null Pivot Field Values?
Answer: 24 rows
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.
- Why can the displayed annual-target total become twice the expected amount?
Answer: The physical join repeats each customer's annual target on both post-pivot month rows before the sum is calculated.
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.
- Assuming no filters or other transformations are applied, what is the resulting structure?
Answer: There are 480 rows; Product ID and Region repeat, and the pivot value is null in 12 rows.
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 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. - After pivoting Jan-Dec columns with missing values, you filter Pivot Field Names. What values appear?
Answer: Every selected column name
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.
- Which pivot configuration best satisfies the requirement, assuming the connector supports this feature?
Answer: Create a wildcard pivot matching Sales_ so newly added columns with that pattern enter the pivot.
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.
- What values should the analyst expect in the renamed Fiscal Year field immediately after renaming it?
Answer: Revenue FY23, Revenue FY24, and Revenue FY25, because renaming changes the field name, not its members.
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.
- What should the analyst do to perform the pivot in Tableau's data model?
Answer: Open the logical table to access its physical layer, then pivot the monthly columns within their physical table.
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.
- A 12-row table has Year, Store, Q1-Q4. You pivot Q1-Q4. How many rows result?
Answer: 48 rows; two pivot columns
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.
- Which action most directly restores the original quarterly columns?
Answer: Remove the pivot operation from the Data Source page, restoring the selected source columns to the grid.
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.
- On the Data Source page, pivot Jan and Feb in a table with Region, Manager, Jan, Feb. What is the schema?
Answer: Region, Manager, Names, Values
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.
- Which sequence most appropriately restructures the files while retaining the distinction between years?
Answer: Union the files, retain or derive the source-file year, then pivot Jan, Feb, and Mar into monthly rows.
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.
