All questions
Question 1
An Excel workbook contains twelve worksheets named Jan through Dec. Each worksheet has the same columns and represents a different month. The worksheets do not contain keys that match records across months.
How should you connect these worksheets so that annual analysis uses one continuous set of rows?
- Create a relationship among the twelve worksheets using the month represented by each worksheet name.
- Create an inner join among the twelve worksheets using every column that the worksheets share.
- Create a union of the twelve worksheets so that their records are appended into one table. (correct answer)
- Create twelve separate data sources and blend them using a calculated field for month.
Explanation: When you encounter a question about combining similarly structured tables in Tableau, ask yourself: are you trying to match records side by side or stack records on top of each other? That distinction separates joins and relationships from unions, and it's the heart of this question.
Here, all twelve worksheets share identical columns but contain different rows — one month's worth of data each. To perform annual analysis across all rows, you need to append them vertically into one continuous table. That's exactly what a union does: it stacks rows from multiple tables that share the same structure, giving you a single dataset spanning all twelve months. Tableau even adds a "Sheet" field automatically, so you can still filter or group by month. C is the right move.
A is wrong because relationships (and joins) are designed to link tables horizontally using a common key field. The passage explicitly tells you the worksheets have no shared keys across months — and even if they did, a relationship wouldn't combine monthly records into one continuous set of rows.
B fails for the same structural reason: an inner join matches rows based on shared key values. Joining on every shared column here would either produce a Cartesian product or return no meaningful matches, not a clean annual dataset.
D is an overcomplicated workaround. Data blending is for combining sources that can't be unioned or joined — typically from different database types. Using twelve separate sources and blending them introduces unnecessary complexity and aggregation limitations.
Your takeaway: same structure + different rows = union. Whenever a question describes identically formatted tables (months, regions, departments) that need to be combined for aggregate analysis, union is almost always the answer.
Question 2
A regional system exports a text file in which fields are separated by semicolons and decimal values appear as 12,50. Tableau initially displays each row as one field, and the amount values are not recognized as numbers.
Which changes should you make while configuring the text-file connection?
- Set the field separator to a comma and change the amount field from a string to a number.
- Set the field separator to a semicolon and select a locale that recognizes comma decimal separators. (correct answer)
- Keep automatic text-file properties and split every imported row later with a calculated field.
- Set the field separator to a semicolon and replace every comma with a period in the source file.
Explanation: When connecting to a text file in Tableau, two separate problems can occur simultaneously: incorrect field delimiters and unrecognized number formats. You need to address both independently, and this question tests whether you understand that distinction.
The scenario describes two symptoms — rows not splitting into columns, and decimal values like "12,50" not recognized as numbers. The first symptom tells you Tableau doesn't know the separator is a semicolon; the second tells you Tableau is using a locale (like English) that expects a period as the decimal separator, not a comma. Answer B fixes both at the connection level: setting the field separator to a semicolon splits the columns correctly, and choosing a locale that uses comma decimals (such as French or German) tells Tableau how to interpret "12,50" as a number automatically. This is the cleanest, most complete solution.
Answer A fails because setting the separator to a comma would split fields on the wrong character, since the file uses semicolons — your columns would still be garbled. Manually changing the field type to a number also doesn't resolve the decimal format mismatch.
Answer C avoids solving the root problem. Splitting rows with a calculated field is a workaround for a different scenario and would be unnecessarily complex here — and it still wouldn't fix the decimal recognition issue.
Answer D requires modifying the source file itself, which is rarely acceptable in a business context and unnecessary when Tableau's locale settings can handle this natively.
The key takeaway: whenever a text file has two symptoms — wrong delimiters and unrecognized numbers — look for the answer that resolves both at the connection level using separator settings and locale, not downstream workarounds.
Question 3
A Tableau user successfully authenticates to a database and can select the intended database and schema. However, no tables appear in the connection pane. A database administrator confirms that the user has login permission but no object-level permissions.
Which change is required before the user can connect to the needed tables?
- Grant the user appropriate read access to the required tables or views, then refresh or reopen the connection. (correct answer)
- Convert the connection from live to an extract so Tableau can bypass database object-level permissions.
- Assign the user permission to save Tableau workbooks locally, then refresh the database metadata.
- Create a relationship with an Excel file so Tableau can discover the inaccessible database tables indirectly.
Explanation: When you see a question about a user who can authenticate and navigate to the right database but still can't see tables, you're being tested on the difference between authentication (proving who you are) and authorization (what you're allowed to access). These are two distinct layers of database security, and Tableau respects both fully.
The root cause here is missing object-level permissions — the user has login rights but no grants on the actual tables or views. The fix is straightforward: a database administrator must grant the appropriate read permissions (typically SELECT) on the required tables or views. Once those permissions exist at the database level, refreshing or reopening the connection in Tableau will make the tables visible. This is answer A, and it's correct because it directly resolves the actual problem.
Answer B is a common misconception — extracts do not bypass database permissions. An extract is generated by Tableau querying the database, so if the user can't read the tables live, they can't extract from them either. Answer C confuses local Tableau file permissions with database object permissions; saving workbooks locally has nothing to do with whether a database exposes its tables to a user. Answer D is simply not how Tableau works — joining an Excel file does not grant access to separate database tables that the user lacks permission to see.
Study tip: On Tableau exam questions, always separate the connection layer (credentials, server address) from the permission layer (object-level grants). If a user can log in but sees no objects, the answer almost always involves fixing permissions at the database level — not changing Tableau settings.
Question 4
A Tableau Desktop workbook uses the analyst's database credentials and works locally. It will be published with an extract that Tableau Server must refresh nightly. Tableau Server can reach the database, and the database supports a dedicated username and password.
Which configuration is most likely to allow the scheduled refresh to succeed securely?
- Remove all database credentials after publishing, because the extract permanently stores its data and never needs to query the source again.
- Keep the analyst's local login session active, because Tableau Server reuses open Tableau Desktop authentication tokens for scheduled jobs.
- Require each workbook viewer to enter their own database credentials, because scheduled refreshes pause until an interactive login is provided.
- Embed a dedicated least-privilege database account in the published connection so Tableau Server can authenticate without user interaction. (correct answer)
Explanation: When Tableau Server runs a scheduled extract refresh, it must authenticate to the source database without any human present. That's the central concept being tested here — unattended, automated credential management. The question is asking which approach lets the server log in on its own, securely, every night.
The right approach is D: embedding a dedicated, least-privilege database account directly in the published data source connection. When credentials are embedded, Tableau Server stores them (encrypted) and presents them automatically at refresh time. Using a dedicated service account — one with only the permissions needed to read the relevant data — follows the security principle of least privilege, limiting exposure if those credentials are ever compromised.
A is based on a fundamental misunderstanding. Extracts do store a snapshot of data, but that snapshot must be rebuilt nightly, which requires querying the source again. Removing credentials guarantees the refresh will fail.
B describes something that simply doesn't exist. Tableau Server does not borrow or reuse an analyst's local Desktop session or authentication tokens. These are completely separate systems, and scheduled jobs do not wait for someone to have Desktop open.
C confuses scheduled refreshes with interactive, user-driven connections. Prompted credentials only work when a live user is present to type them. A scheduled job runs silently in the background — there is no one to answer a prompt, so the refresh would never complete.
A good study habit here: whenever you see a Tableau question involving scheduled or automated processes, immediately ask yourself, "Who authenticates, and when?" If no user is present, embedded service-account credentials are almost always the right answer.
Question 5
Product quotas are stored in Excel, while transaction-level sales are stored in a supported SQL database. The analyst specifically needs one row-level table that contains selected quota columns alongside matching transaction rows, joined by Product ID.
How should the analyst configure the connection in Tableau?
- Create two independent data sources and blend their aggregated results by Product ID in each worksheet.
- Add both connections to one data source and create a cross-database physical join by Product ID. (correct answer)
- Union the Excel quota rows with the SQL transaction rows and rename columns until their structures match.
- Publish both sources separately and create matching data source filters based on Product ID values.
Explanation: When Tableau questions describe data from two different source types that need to be combined at the row level, you should immediately think about physical joins — not blending, not unions. The distinction matters enormously in practice.
Because the analyst needs a single row-level table with quota columns sitting alongside matching transaction rows, option B is the correct approach. Tableau allows you to add multiple connections — one to Excel, one to the SQL database — within a single data source. From there, you create a cross-database join on Product ID in the physical layer. This produces exactly one flat table where each transaction row carries its corresponding quota data, precisely what the analyst needs.
A is wrong because data blending works at the aggregated level, not row level. Blending happens in the worksheet and cannot produce a granular, row-by-row combination — it's a last resort when joining isn't possible, not a preferred tool for row-level analysis.
C is wrong because a union stacks rows vertically, appending rows from one table beneath another. That's useful when two tables share the same structure (like monthly sales files), but it doesn't join quota records to transactions side by side. Renaming columns doesn't solve a structural mismatch created by the wrong operation.
D is wrong because publishing sources separately and applying matching filters doesn't join anything — it just isolates data independently. Filters restrict rows; they don't combine columns across sources.
The key study pattern: join = columns side by side (row-level), blend = aggregated worksheet merge, union = rows stacked vertically. Memorize that triangle and you'll navigate most data-combination questions confidently.
Question 6
An Excel worksheet has a report title in the first row, two blank rows, merged header cells, and explanatory footnotes beneath the data. When connected normally, Tableau assigns generic field names and includes nondata rows.
What should you do first to create the most reliable connection without manually redesigning the workbook?
- Enable Data Interpreter and review the detected table to verify that headers and data boundaries are correct. (correct answer)
- Add a data source filter that removes null measures and then rename all generic fields manually.
- Write custom SQL that skips the first three rows and excludes records containing the footnote text.
- Join the worksheet to itself so one copy supplies headers and the other supplies data rows.
Explanation: When Tableau connects to a messy Excel file — one with report titles, blank rows, merged headers, or footnotes — it often misreads the structure, producing generic field names like "F1" and pulling in rows that aren't real data. The question is testing whether you know Tableau's built-in tool for handling exactly this situation before reaching for manual workarounds.
Tableau's Data Interpreter is designed specifically for this scenario. Enabling it (A) lets Tableau automatically detect the actual data table, strip out decorative rows, and promote real column headers — all without touching the original workbook. After enabling it, you're prompted to review the detected structure, which lets you verify that boundaries are correct before building anything downstream. This is the fastest, most reliable first step.
Choice B is backwards — renaming generic fields and filtering nulls treats the symptom after the fact, and doesn't fix the root problem of misidentified headers and boundaries. It also creates fragile connections that break if the source file changes.
Choice C introduces unnecessary complexity. Custom SQL can skip rows, but it requires hardcoding row numbers and footnote text, making the connection brittle and difficult to maintain if the Excel file is ever updated.
Choice D is a misuse of self-joins. Joining a worksheet to itself to separate headers from data is not a Tableau feature or best practice — it would create a convoluted, unreliable structure and wouldn't actually solve the parsing problem.
Study tip: On Tableau exam questions about messy Excel or text files, always think "Data Interpreter first." It's Tableau's purpose-built solution for structural problems, and reaching for it before manual fixes is the expected best practice.
Question 7
A developer can connect to a company database with another desktop application. In Tableau Desktop, the correct database connector is available, but selecting it produces a message that the required driver is not installed.
Which action is the most appropriate next step?
- Install the Tableau-supported driver for that connector and operating system, then restart Tableau and retry the connection. (correct answer)
- Create an extract before connecting so Tableau can read the database without using its native driver.
- Use the Microsoft Excel connector and enter the database server name as the workbook location.
- Change the database authentication method because a driver message normally indicates invalid user credentials.
Explanation: When Tableau Desktop displays a "driver not installed" message, it's telling you something very specific: the connector exists in Tableau, but the underlying software that allows Tableau to communicate with that database is missing from your machine. Understanding this distinction — between a connector (Tableau's interface) and a driver (the translation layer between Tableau and the database) — is the core concept being tested here.
The correct path is A: download and install the Tableau-supported driver for your connector and operating system, then restart Tableau and retry. Tableau's website maintains a "Driver Download" page listing exactly which drivers are needed for each connector. Since another desktop application already connects successfully, you know the database credentials and network access are fine — only the driver is missing.
B is wrong because extracts are created after a successful live connection is established. You cannot create an extract to bypass the driver requirement; Tableau still needs the driver to pull the data in the first place. C is wrong because the Excel connector is designed for spreadsheet files, not database servers — entering a server name there won't establish a database connection and will simply produce an error. D misidentifies the problem entirely. A driver error and a credentials error produce different messages; the scenario explicitly states a driver message, not an authentication failure, so changing credentials solves nothing.
For the Tableau exam, train yourself to read error messages literally — Tableau is usually precise about what went wrong. "Driver not installed" means install the driver, not reconfigure credentials or change connectors.
Question 8
A folder contains thirty CSV files with identical columns. Only files whose names begin with Sales_2026_ should be included. Additional matching files will be added before the data source is refreshed.
Which connection approach most efficiently creates the required data source?
- Connect to one CSV file and create a wildcard union whose matching pattern selects the Sales_2026_ files. (correct answer)
- Connect separately to every CSV file and relate the resulting logical tables using their shared column names.
- Connect to one CSV file and create a left join to each remaining file using the transaction identifier.
- Open the files in Excel, place each CSV in a worksheet, and connect to the combined workbook.
Explanation: When you see a question about combining multiple files with identical structures in Tableau, think about wildcard unions — they exist precisely for this scenario and are almost always the most efficient solution.
A wildcard union lets you connect to one file, then define a pattern (like $Sales_2026$_*) that automatically pulls in every matching file from the same folder. Crucially, any new files added later that match the pattern are automatically included on the next refresh — no manual reconfiguration needed. That future-proofing detail in the passage ("additional matching files will be added") is a direct signal pointing you toward A.
The wrong answers each represent a common inefficiency or misapplication. B describes relating logical tables, which is designed for combining tables with different granularities or structures — not stacking identical columns. Relating thirty separate connections would be unnecessarily complex and wouldn't auto-expand for new files. C uses joins, which combine data horizontally (adding columns), whereas you need to stack data vertically (adding rows). Joining thirty files one by one also requires manual updates whenever a new file arrives. D is a workflow anti-pattern — manually converting CSVs into Excel worksheets adds unnecessary steps, introduces human error risk, and still doesn't solve the auto-refresh problem.
The key pattern to remember: whenever a question describes multiple files with identical columns that need to be stacked into one dataset — especially when new files will arrive — a wildcard union is Tableau's purpose-built, lowest-effort solution. If the question mentions future file additions, that's your strongest hint.
Question 9
Several branch CSV files are combined through a wildcard union. The files have identical business columns, but none contains a branch field. The branch can be inferred from each source filename, and the analyst must identify the source of every unioned row.
Which approach should the analyst use after creating the union?
- Create a data source filter for each filename and use the filter caption as the branch identifier.
- Relate every unioned file to itself and use the relationship name as the branch identifier.
- Use Number of Records to assign a different branch value whenever the file's row count changes.
- Use the union-generated Table Name field and, if necessary, derive the branch from its filename value. (correct answer)
Explanation: When you union multiple files in Tableau — especially via wildcard union — Tableau automatically generates a metadata field called Table Name that records the source filename for every row. This is the built-in mechanism designed exactly for your scenario: files with identical columns but no explicit identifier field. The analyst should leverage this Table Name field directly, and if the branch name needs to be extracted from a longer filepath, a calculated field using string functions like REGEXP_EXTRACT or MID/FIND can parse out just the branch portion. That makes D the correct approach.
The distractors each represent a fundamental misunderstanding of how unions work. A is flawed because data source filters remove rows from the view — they're for restricting data, not labeling it. Filter captions are a UI element, not a field you can place on a viz to tag individual rows. B misapplies Tableau's Relationships feature, which joins data across tables at query time; relating a file to itself doesn't produce a branch label and isn't how relationships are intended to be used. C conflates row counts with row identity — the Number of Records measure tells you how many rows exist, not which file a given row came from. Row counts could easily be identical across branches, making this unreliable even in theory.
Your study tip: whenever a Tableau question involves a wildcard union and asks how to trace row origin, your first thought should be Table Name. It's Tableau's automatic, purpose-built solution for source tracking in unions, and it appears on the Tableau exam frequently in exactly this context.
Question 10
A workbook uses a live connection to an Excel file stored in a shared network folder. Colleagues must open the Tableau workbook and refresh it against the current shared Excel file. The analyst is considering saving the workbook as either a TWB or a packaged TWBX.
Which option best preserves the required connection behavior?
- Save a TWBX and delete the packaged Excel file, because Tableau will then locate the network original automatically.
- Save a TWBX with the Excel file included, because the packaged copy automatically synchronizes with the network original.
- Save a TWB that references the accessible network file, because a TWBX generally packages a separate copy of the file. (correct answer)
- Save a TWB and convert the connection to an extract, because extracts always read the network file when opened.
Explanation: When Tableau questions involve file connections and sharing, the core issue is almost always about where the data lives and who controls it. Ask yourself: does each user need to see the same, always-current source, or is a snapshot acceptable?
A TWB file is essentially a set of instructions — it stores your visualization logic and a pointer to the data source, but contains no data itself. A TWBX packages everything into a single archive, including a local copy of the data at the time of packaging. That distinction is everything here.
Option C is correct because saving a TWB preserves a live reference to the shared network Excel file. When colleagues open the workbook and refresh, Tableau follows that pointer to the original file, so everyone works from the same current data. No duplication, no drift.
Option A is a trap built on a misconception — deleting the packaged copy from a TWBX doesn't cause Tableau to "fall back" to a network original. It simply breaks the connection, leaving users with no data at all.
Option B describes a feature that doesn't exist. A TWBX's packaged copy is static; it does not automatically synchronize with any external file. The two copies immediately diverge the moment the original is updated.
Option D misrepresents how extracts work. An extract is itself a packaged snapshot (a .hyper file). It doesn't read the network file on open — it holds its own frozen copy until you explicitly trigger a refresh.
A useful rule of thumb: TWBX = portable snapshot, TWB = live pointer. Anytime a question requires shared, always-current data, TWB is almost always the right frame.