Tableau Quiz: Unions
15 questions · exam conditions
0:00
UnionsQuestion 1 of 15

Unioning two CSVs that contain the same 100 rows and share a primary key will:

Keep one row per key
Drop the duplicates
Include all 200 rows
Error on key conflict
← Back to quizzes

Tableau Quiz

Tableau Quiz: Unions

Practice Unions 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 Unions, 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

Unioning two CSVs that contain the same 100 rows and share a primary key will:

  1. Keep one row per key
  2. Drop the duplicates
  3. Include all 200 rows (correct answer)
  4. Error on key conflict
Explanation: A union stacks rows from both files, so every row appears even if the key matches. It does not compare keys or remove duplicates. The tempting mistake is to expect a join-style dedupe that keeps one row per key, but union is not a join.

Question 2

Wildcard union on Sales_*.csv; Sales_2022.csv is added.

  1. Included when data refreshes (correct answer)
  2. Requires editing the union
  3. Excluded unless pattern edited
  4. Skipped until union edited
Explanation: A wildcard union matches any CSV whose name starts with Sales_ and ends in .csv, so Sales_2022.csv is swept in automatically the next time the data refreshes. You don't need to edit the union. The tempting error is thinking you must manually add the new file, but the pattern already covers it.

Question 3

Unioning Table 1 (Customer) with Table 2 (Client) will:

  1. Separate Customer and Client (correct answer)
  2. Combine rows under Customer
  3. Match columns by position
  4. Prompt to rename a field
Explanation: Unions append rows and align columns by field name, not by position or table order. Because one table uses Customer and the other uses Client, those names do not match, so the union keeps both as separate columns, with nulls for rows from the table that lacks each field. It does not rename fields, prompt for a rename, or match columns by position.

Question 4

In a wildcard union on Sales_*.csv, the Table Name field holds:

  1. Row count from each file
  2. Pattern text Sales_*.csv
  3. Source column names only
  4. File name for every row (correct answer)
Explanation: When you use a wildcard union on Sales_.csv, Tableau adds a Table Name field that stores the actual source file name for each row, so you can tell which file a record came from. The tempting wrong answer is the pattern text Sales_.csv, but the field holds each matched file's real name, not the wildcard pattern itself.

Question 5

Table B lacks Region; Table A has it. Union result:

  1. Blank for Table A rows
  2. Null for Table B rows (correct answer)
  3. Region column is dropped
  4. The union fails to load
Explanation: When you union tables in Tableau, columns match by field name. Since Table B lacks Region, its rows get a Region column filled with null, while Table A rows keep their values. The tempting wrong answer is that the union fails to load or Region is dropped, but Tableau includes the column and marks missing data as null.

Question 6

A North table stores Customer ID as a string and includes identifiers such as A102. A South table stores Customer ID as a whole number. The analyst must append the rows and retain all identifiers in one dimension.

Which preparation best ensures valid schema alignment without losing the alphanumeric identifiers?

  1. Convert the North identifier to a number and use nulls for values such as A102.
  2. Rename the South identifier but leave its numeric data type unchanged before unioning.
  3. Convert the South identifier to a string and ensure both fields use the same name. (correct answer)
  4. Join the tables on customer identifier and keep the North field as the output.
Explanation: When you see a question about unioning tables in Tableau, focus on two requirements simultaneously: field name alignment and data type compatibility. A union appends rows vertically, so mismatched names or types will either split data into separate columns or force conversions that destroy information. Here, the core challenge is that one identifier column contains alphanumeric values like A102, which cannot survive conversion to a number — they become null. The only safe universal data type is string, because strings can represent both A102 and 102 without data loss. That's exactly what C does: converting the South table's numeric Customer ID to a string and giving both fields the same name ensures Tableau recognizes them as one unified field and preserves every identifier intact. A is the opposite approach — converting the North field to a number — which immediately destroys A102 and any other alphanumeric value, replacing them with nulls. You lose the very data you're trying to retain. B addresses the naming problem but ignores the type mismatch. When field names match but types don't, Tableau may still misalign data or produce unexpected nulls during the union. Renaming alone is insufficient. D describes a join, not a union. Joining on customer identifier combines columns side by side rather than appending rows, which is a fundamentally different operation and won't stack the two tables into one dimension. A useful rule of thumb: when unioning, always match both name and type, and when types conflict with alphanumeric data, string wins. Numeric types can never safely represent letters, but strings can represent numbers.

Question 7

A folder initially contains Orders_Jan.csv, Orders_Feb.csv, and Returns_Feb.csv. An analyst creates a wildcard union using the filename pattern Orders_*.csv. The files have aligned schemas. Later, Orders_Mar.csv is added to the same searched folder.

What should the analyst expect when the data source is refreshed?

  1. The March file will be included automatically, while the returns file remains excluded by the pattern. (correct answer)
  2. The March file will remain excluded until it is manually dragged into the existing union.
  3. Both March orders and February returns will be included because they are CSV files.
  4. Only the March file will remain because wildcard refresh replaces previously matched files.
Explanation: Wildcard unions in Tableau are designed to be dynamic — when you define a pattern like Orders_*.csv, you're not just capturing a static list of files, you're telling Tableau to match any file that fits that pattern within the specified folder. This distinction is central to what's being tested here. Because the wildcard pattern Orders_*.csv uses an asterisk as a placeholder for any characters, Orders_Mar.csv automatically satisfies the pattern the moment it appears in the folder. When the data source is refreshed, Tableau re-scans the folder, finds the new match, and includes it — no manual intervention required. Meanwhile, Returns_Feb.csv never matched Orders_*.csv to begin with, so it continues to be excluded. This makes A correct: the March file is pulled in automatically, and the returns file stays out. B is wrong because it confuses wildcard unions with manual unions. Manual unions require you to drag files in yourself, but wildcard unions handle new matches automatically on refresh — that's their entire advantage. C is wrong because the wildcard pattern doesn't simply match all CSVs in the folder; the Orders_ prefix explicitly restricts matches to files starting with that string, which Returns_Feb.csv does not. D describes behavior that doesn't exist in Tableau — wildcard refresh is additive and cumulative, not a replacement operation that drops previously matched files. A useful way to remember this: think of a wildcard union as a standing rule, not a one-time selection. Any file that earns membership in the future joins automatically on refresh.

Question 8

A legacy orders table contains Order ID, Sales, and Discount. A newer orders table contains Order ID and Sales but has no discount field. Both tables are included in a union, and all other field names and types align.

How should the analyst interpret the resulting Discount values for rows from the newer table?

  1. The newer rows will be rejected because every union table requires identical columns.
  2. They will be zero because Tableau fills absent numeric fields with a default value.
  3. They will repeat the latest legacy discount because unions carry values forward by field.
  4. They will be null because the newer source has no corresponding field for those rows. (correct answer)
Explanation: When working with unions in Tableau, the core concept to understand is how the tool handles mismatched columns across sources. A union stacks rows from multiple tables vertically, matching fields by name and type. When a field exists in one source but not another, Tableau still includes that column in the result — it simply has no value to populate for the rows where the field was absent. That's exactly what happens here with Discount. The legacy table has it; the newer table doesn't. For every row originating from the newer table, Tableau cannot pull a Discount value because none was ever recorded in that source. The result is null — not zero, not carried forward, just absent. D is correct. A is wrong because Tableau does not reject unions due to mismatched columns. Mismatched fields are a normal, expected scenario — Tableau resolves them gracefully by padding missing values with null rather than throwing an error. B is a tempting trap. You might assume numeric fields default to zero, but Tableau does not infer or substitute a default numeric value. Null and zero are meaningfully different in Tableau calculations, and the tool preserves that distinction by using null when no value exists. C describes behavior similar to a time-series "carry-forward" fill, which is a separate analytical technique you'd apply intentionally (e.g., with a LOD or table calculation). Unions do not automatically propagate values across rows. Study tip: Remember the union mantra — same name, same type, stacked rows. Any column not present in a source gets null for that source's rows, never a fabricated value.

Question 9

In Tableau's logical data model, an analyst has a logical table named Current Orders. Dragging Archived Orders next to it creates a relationship, but the requirement is to append archived records beneath current records.

What should the analyst do instead?

  1. Open the logical table's physical layer and create a union of the two physical tables. (correct answer)
  2. Keep the relationship and change its referential-integrity setting to append all records.
  3. Create an inner join in the logical layer using Order ID as the matching field.
  4. Add both tables as separate logical tables and hide every duplicated dimension field.
Explanation: Whenever you see a question about combining tables in Tableau, your first instinct should be to distinguish between the type of combination needed: are you matching rows side-by-side (join/relationship), or stacking rows on top of each other (union)? That distinction is everything here. The requirement is to append archived records beneath current records — meaning you want every row from both tables in one continuous dataset, with no row-matching logic involved. That's the definition of a union. The correct move is A: open the physical layer of the logical table and create a union there. In Tableau's data model, unions live in the physical layer, where you drag one physical table on top of another to stack their rows. This produces a single logical table containing all records from both sources. Choice B is a trap because referential integrity settings control how Tableau handles unmatched rows in a relationship — they don't convert a relationship into a union. No referential-integrity option appends records in the way the question describes. Choice C describes an inner join, which would only return rows where Order ID exists in both tables. That's the opposite of what you want — you'd lose records unique to either table, not combine everything. Choice D is a workaround that creates two separate logical tables, which means Tableau treats them as independent sources requiring a relationship between them. Hiding duplicate fields doesn't merge the row data into one flat dataset. As a study tip, remember: relationships and joins combine columns; unions stack rows. Any time a question mentions "append," "stack," or "combine records beneath," think union — and in Tableau, unions are built in the physical layer.

Question 10

A workbook unions two monthly tables. January contains Order ID, Sales, and Region. February contains Order ID, Revenue, and Region. After the union, the data source contains separate Sales and Revenue fields, with source-dependent nulls.

What should the analyst do to create one measure containing values from both months?

  1. Rename the resulting Revenue field to Sales in the unioned data source.
  2. Merge Sales and Revenue as mismatched fields after confirming compatible data types. (correct answer)
  3. Create a relationship between January and February using Order ID as the key.
  4. Convert the union to a join and match January to February by Region.
Explanation: When a union combines tables with differently named fields that represent the same measure — like "Sales" from January and "Revenue" from February — Tableau keeps them as separate columns and fills the opposite month's rows with nulls. Your goal is to collapse those two columns into one clean measure, and Tableau's merge mismatched fields feature does exactly that. By selecting both fields in the data source editor and merging them, Tableau consolidates the non-null values into a single column, preserving all data from both months. This is the right tool when fields are semantically identical but named differently across unioned sources — which is precisely what option B describes. Option A is tempting but incomplete. Renaming "Revenue" to "Sales" doesn't merge the columns — you'd still have two separate fields, now with a naming conflict, and the nulls would remain. Renaming alone doesn't tell Tableau to combine the values. Option C misunderstands the scenario. A relationship connects separate logical tables for querying purposes, but January and February already exist in a single unioned table. Adding a relationship wouldn't consolidate the mismatched columns. Option D replaces the union with a join, which is the wrong direction entirely. A join on Region would multiply rows across months rather than stack them, destroying the month-level granularity and creating a Cartesian mess. A good rule of thumb: whenever a union produces two columns that should be one — same data type, different names — reach for merge mismatched fields, not renaming, relationships, or joins. That's the Tableau-specific solution this scenario is testing.

Question 11

Before creating a union, an East table has 720720 rows and a West table has 480480 rows. After unioning them, Tableau reports 1,1701{,}170 rows. Using the generated Table Name field, the analyst finds 720720 East rows and 450450 West rows.

Which conclusion is best supported by this validation?

  1. Tableau removed 3030 duplicate records because unions apply distinct-record processing.
  2. A field-name mismatch caused 3030 West records to become null and disappear.
  3. The union retained East correctly, but 3030 expected West rows were excluded upstream. (correct answer)
  4. The difference is expected because the first table determines the union's row count.
Explanation: When validating a union in Tableau, your go-to move is comparing the expected row counts against what the Table Name field actually reports for each source. This tells you precisely where any discrepancy originates. Here's the math: 720+480=1,200720 + 480 = 1{,}200 expected rows, but the union produced 1,1701{,}170 — a difference of 3030 rows. When you break the result down by Table Name, you see 720720 East rows (exactly correct) and only 450450 West rows instead of 480480. The shortfall lives entirely in the West source. This means the East data loaded cleanly, and the 3030 missing West rows were never present in the union to begin with — they were excluded somewhere upstream, likely at the data source, extract, or connection level before Tableau even performed the union. That's exactly what C describes. A is wrong because Tableau unions do not apply automatic deduplication. A union is a straight vertical stack of rows — it does not remove duplicates unless you explicitly add a distinct step afterward. B is a tempting trap: field-name mismatches in a union create null-filled columns, not disappearing rows. The row count would still reflect all 1,2001{,}200 rows; they'd just have nulls in mismatched fields. Null values don't cause rows to vanish. D is simply false — the first table has no special authority over the total row count. A union includes every row from every source table. Study tip: On union questions, always validate per-source row counts using the Table Name field. If the total is off, Table Name tells you exactly which source to investigate upstream.

Question 12

A workbook has one live connection to a SQL Server order database and a separate live connection to an Oracle archive database. Both contain tables with aligned order schemas. The analyst attempts to place the two tables in one manual union in Tableau Desktop.

Which approach correctly addresses this requirement?

  1. Create the union directly, because matching field names allow unions across any workbook connections.
  2. Create a cross-database relationship between the two tables, which combines their rows into one set.
  3. Consolidate both tables into one connection, or use Tableau Prep to union inputs from separate sources. (correct answer)
  4. Create a cross-database join with no join clause, which effectively appends all order rows.
Explanation: When you see a question about combining data from multiple separate connections in Tableau Desktop, the key concept to focus on is union scope: manual unions in Tableau Desktop are restricted to tables within the same connection. You cannot drag tables from two different connections into a single union pane, regardless of how well their schemas align. That's exactly why C is correct. When your order data lives in two separate connections (SQL Server and Oracle), you have two valid paths: consolidate both tables under one connection (if the database type and access allow it), or bring both sources into Tableau Prep, which is specifically designed to union, join, and blend data across heterogeneous sources before it reaches your workbook. A is wrong because matching field names are necessary for a clean union, but they are not sufficient to enable one across connections. Tableau Desktop's union tool simply doesn't support cross-connection unions, full stop. B confuses union logic with relationship logic. A cross-database relationship in Tableau links tables conceptually for querying purposes — it does not append rows the way a union does. Relationships are about defining how tables relate, not stacking them vertically. D misrepresents how cross-database joins work. A join without a join clause would produce a Cartesian product (every row matched with every other row), not a row-appending union. The behavior and the result are entirely different from what a union accomplishes. As a study tip, remember the hierarchy: unions stack rows, joins match rows, and relationships define context. Knowing which tool applies to which scenario — and where each tool's boundaries are — is a recurring theme on the Tableau exam.

Question 13

A historical orders table contains 800800 rows, and a current orders table contains 600600 rows. Exactly 5050 records appear identically in both tables because the extraction periods overlap.

Assuming no source filters, how many rows should a Tableau union produce, and why?

  1. 1,3501{,}350 rows, because a union automatically removes the 5050 duplicate records.
  2. 1,4001{,}400 rows, because a union appends records without automatically removing duplicates. (correct answer)
  3. 800800 rows, because matching current records replace corresponding historical records.
  4. 600600 rows, because the most recently added table determines the retained records.
Explanation: Whenever you see a question about Tableau unions, anchor yourself to one core principle: a union is a vertical append, not a merge or deduplication operation. Tableau simply stacks one table on top of another, combining all rows from both sources into a single dataset. That's exactly what happens here. The historical table contributes 800800 rows and the current table contributes 600600 rows, giving you 800+600=1,400800 + 600 = 1{,}400 total rows — making B correct. The 5050 overlapping records are included twice, once from each table, because Tableau does not inspect row content to eliminate matches during a union. The result is a longer table with potential duplicates, not a cleaner one. A describes the behavior of a join or a manual deduplication step, not a union. Automatically removing the 5050 duplicates would yield 1,3501{,}350 rows, but Tableau's union makes no such comparison — it just appends. C describes something closer to an update or replace operation, where newer records overwrite older ones. That logic doesn't apply to unions at all. D similarly invents a rule that doesn't exist — the row count of any single source table never "wins" in a union; both contribute fully. A practical study tip: remember that deduplication after a union is your responsibility as the analyst. If you need to remove overlapping records, you must add a subsequent step — such as a calculated field filter or a FIXED LOD expression — to handle it. Unions themselves are intentionally dumb stackers.

Question 14

Two regional order tables have the same three fields and compatible data types. The East table stores the columns as Order ID, Order Date, Sales. The West table stores them as Sales, Order ID, Order Date.

What will happen when the tables are unioned in Tableau?

  1. The fields will align by field name, despite appearing in different source-column positions. (correct answer)
  2. The fields will align by column position, causing Sales to populate Order ID.
  3. The union will fail until both tables use the identical physical column order.
  4. The union will append the rows but create three duplicate pairs of output fields.
Explanation: When you see a question about unions in Tableau, the key concept to anchor on is how Tableau matches fields across tables — by name or by position. Tableau unions align fields using field names, not column order. So when the East table (Order ID, Order Date, Sales) and West table (Sales, Order ID, Order Date) are unioned, Tableau reads the headers, matches "Order ID" to "Order ID," "Sales" to "Sales," and so on — regardless of where those columns physically sit. The result is a clean, correctly structured union with rows from both tables appended accurately. That makes A the correct answer. B describes how SQL or spreadsheet tools behave when matching by position rather than by name — a common misconception students carry over from other tools. In Tableau, column order is irrelevant to union matching, so Sales would never populate Order ID. C is simply false; Tableau does not require identical physical column order to perform a union, and no such failure condition exists. D describes what happens when Tableau cannot match field names and creates null-padded duplicate columns instead — but that only occurs when field names differ between tables, not when they simply appear in a different order. A useful study tip: think of Tableau unions as name-driven, not position-driven. The trap on this exam is assuming Tableau behaves like a raw file concatenation. It doesn't — it's smarter than that. If field names match, the union works cleanly. Duplicate output columns only appear when names genuinely differ.

Question 15

A budget table contains one row per month with Period, Amount, and Scenario. An actuals table contains one row per day with Date, Amount, and Scenario. The goal is a unioned data set for comparing monthly budget with monthly actuals.

Which workflow best validates both structural and semantic alignment before the union?

  1. Rename Period to Date and union immediately, because matching field names guarantee comparable rows.
  2. Aggregate actuals to the monthly grain, align the date field names and data types, then union the resulting rows. (correct answer)
  3. Join daily actuals to monthly budgets on exact dates, retaining only records where dates match precisely.
  4. Convert both date fields to strings, union all rows, then remove any records with equal amounts afterward.
Explanation: When preparing data for a union in Tableau, you need to think about two distinct layers of alignment: structural (do the fields match in name and data type?) and semantic (do the rows represent the same unit of meaning?). A union stacks rows vertically, so mismatched granularity is just as dangerous as mismatched field names. Answer B is correct because it addresses both layers in the right order. Aggregating actuals from daily to monthly grain first ensures every row in both tables represents one month — the same semantic unit as the budget rows. Only then do you align field names and data types before unioning. This sequence prevents you from mixing a single budget month against potentially 28–31 actuals rows, which would inflate counts and distort any comparison. Answer A is tempting because Tableau does use field names to align union columns, but renaming Period to Date only solves the structural problem. The daily actuals still carry daily rows, so each monthly budget record would be compared against dozens of actuals rows — a semantic mismatch that naming alone cannot fix. Answer C describes a join, not a union, and an exact date join between daily and monthly data would drop nearly all records (monthly budget periods rarely align with individual daily dates), destroying most of your data in the process. Answer D converts fields to strings to force a union, which discards proper date sorting and filtering capabilities. Removing records with equal amounts afterward is also logically unrelated to fixing structural or semantic alignment. Study tip: On Tableau exam questions about combining data, always ask yourself two things before choosing a method: Are the grains the same? and Do the field types and names match? If either answer is no, prep work is required before the union.