Tableau Quiz: Data Source Page
10 questions · exam conditions
0:00
Data Source PageQuestion 1 of 10

Several fields in a published workbook have been renamed in Tableau. An analyst must determine which database columns those fields still reference, but the current field names no longer resemble the source column names.

Which Data Source page approach most directly provides the required information?

Open the metadata grid and compare Field Name with Remote Field Name.
Scan the data preview and infer each source column from its displayed values.
Open a worksheet and compare the dimensions and measures in the Data pane.
Refresh the connection so Tableau replaces the customized names with source names.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Data Source Page

Practice Data Source Page 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 Data Source Page, 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

Several fields in a published workbook have been renamed in Tableau. An analyst must determine which database columns those fields still reference, but the current field names no longer resemble the source column names.

Which Data Source page approach most directly provides the required information?

  1. Open the metadata grid and compare Field Name with Remote Field Name. (correct answer)
  2. Scan the data preview and infer each source column from its displayed values.
  3. Open a worksheet and compare the dimensions and measures in the Data pane.
  4. Refresh the connection so Tableau replaces the customized names with source names.
Explanation: When you need to trace a renamed field back to its original database column in Tableau, think about where Tableau stores metadata — structural information about the data source itself — rather than the data values. This distinction is the core of what this question tests. The metadata grid on the Data Source page is exactly the right tool here. It displays two critical columns side by side: Field Name (what the field is currently called in Tableau, including any custom renames) and Remote Field Name (the original column name from the database). Comparing these two columns gives you a direct, unambiguous mapping — no guessing required. So A is correct. B is a trap because scanning the data preview shows you values, not column lineage. If a field named "Revenue Driver" contains numbers, you still can't tell whether it maps to sales_amt, gross_rev, or something else in the source schema. C misleads you into thinking the Data pane on a worksheet helps, but it only shows the Tableau-side field names — the renamed versions. It doesn't expose what the underlying source column is called. D is dangerous advice. Refreshing the connection does not revert custom field names. Tableau preserves renames across refreshes intentionally, so this action would change nothing and could create confusion. Study tip: On the Tableau exam, whenever a question involves the origin or structure of a field rather than its values, think metadata grid. Remember the pairing: Field Name = Tableau name, Remote Field Name = source column. That one mapping is the answer to this entire category of questions.

Question 2

A wide data source contains internal audit fields that workbook authors should not normally use. The fields must remain in the source system, and an administrator may need to make them available again later.

Which metadata action best satisfies these requirements?

  1. Delete the columns from the physical table on the Data Source page.
  2. Hide the fields in Tableau and unhide them later if they are needed. (correct answer)
  3. Rename the fields with an underscore so Tableau excludes them from worksheets.
  4. Convert the fields to String so they no longer appear as usable measures.
Explanation: When Tableau questions mention fields that need to be temporarily restricted from authors but preserved for future use, you're being tested on the difference between reversible metadata changes and destructive or misleading ones. The key constraint here is that the fields must stay in the source and remain recoverable. Hiding fields in Tableau (B) is the right move. When you hide a field on the Data Source page, it disappears from the field list that workbook authors see, but the underlying data is completely untouched. An administrator can simply right-click and unhide it at any time — no data loss, no schema changes, full reversibility. This is exactly the kind of lightweight, non-destructive metadata management Tableau is designed for. Choice A fails immediately because deleting a column from the physical table is a destructive, permanent action — you'd be altering the actual data source schema, which contradicts the requirement that fields remain in the source system. Choice C is a trap: renaming fields with an underscore is not a Tableau feature that hides or excludes fields from worksheets. Tableau doesn't treat underscored names specially; the fields would still appear, just with awkward names. Choice D is doubly wrong — converting a field to String doesn't hide it, it just changes how Tableau classifies it, and it still shows up in the field list as a usable dimension. A good study tip: on Tableau exam questions involving field management, always check whether the requirement is reversible and non-destructive. If a scenario says "may need it later," hiding is almost always the correct answer over renaming, deleting, or converting.

Question 3

A data source contains separate Orders and Returns logical tables connected by a relationship. The analyst selects Orders on the Data Source page and sees no return-status columns in its preview. The analyst concludes that the relationship is broken.

Which explanation is most accurate?

  1. The relationship is broken because every related field must appear in each logical table's preview.
  2. The relationship has become an inner join because unmatched fields are omitted from the preview.
  3. The relationship will work only after return-status fields are copied into the Orders metadata.
  4. The preview can show the selected logical table independently; relationships are resolved when fields are queried together. (correct answer)
Explanation: Whenever you see a question about Tableau's relationship model, remember the core principle: relationships are lazy. They don't resolve into joins until you actually drag fields from multiple tables into a view or query. Each logical table lives independently until that moment. This is exactly what's happening in the scenario. The analyst previews the Orders table on the Data Source page, and that preview shows only the Orders table's own columns — because no query has asked Tableau to combine Orders with Returns yet. The absence of return-status fields in that preview is completely expected behavior, not evidence of a broken relationship. Answer D captures this perfectly: the preview reflects the selected logical table in isolation, and the relationship activates dynamically when fields from both tables are used together. Answer A is wrong because fields don't need to appear in each table's preview for a relationship to be valid. Relationships intentionally keep tables separate until needed — that's their advantage over traditional joins. Answer B misdiagnoses the situation entirely; the preview isn't "becoming an inner join" or omitting unmatched rows — it's simply showing one table's schema with no join occurring at all. Answer C invents a requirement that doesn't exist in Tableau. You never need to copy fields between logical tables to make a relationship function; that would defeat the entire purpose of the relationship model. The study tip here: don't confuse the Data Source page preview with query results. The preview is a schema inspection tool, not a joined output. If you see a question where someone panics because a related table's fields aren't visible in another table's preview, the answer will almost always point back to how relationships are resolved at query time, not at preview time.

Question 4

To audit a data source, an analyst sorts the metadata grid by Remote Field Name. The analyst expects this operation to permanently reorder the database columns and change the field sequence shown to workbook authors.

What effect does sorting the metadata grid actually have?

  1. It rewrites the physical column order in the connected database table after the next refresh.
  2. It changes the default field sequence in every worksheet while preserving database column order.
  3. It reorganizes the metadata-grid display for inspection without reordering the source columns. (correct answer)
  4. It sorts the data records by that field and stores the resulting order in the connection.
Explanation: When working with Tableau's Data Source page, it helps to distinguish between display operations and structural operations. The metadata grid is an inspection tool — it lets you audit field names, data types, and remote column names. Any sorting you do there affects only how that grid is rendered on your screen. Sorting by Remote Field Name simply reorders the rows you see in the metadata grid for easier reading and auditing. It has zero effect on the underlying database, the physical column order in the source table, or how fields appear in worksheets. That's C, and it's correct precisely because the metadata grid is a read-only view of connection metadata, not a write interface to the source. A is wrong because Tableau never rewrites column order in a connected database — it has no mechanism to issue DDL commands against your source just from sorting a display grid. B is tempting because it sounds like a reasonable middle ground, but sorting the metadata grid doesn't alter the default field sequence in worksheets either; that sequence is determined separately and isn't linked to how you sort this grid. D conflates sorting metadata with sorting data records, which are entirely different concepts — the metadata grid shows field-level information, not individual rows of data, so no record ordering is stored anywhere. A useful pattern to remember: on Tableau exam questions, any answer that implies a permanent or structural change from a display/UI action is almost certainly a trap. Tableau's interface keeps presentation-layer changes separate from source-layer changes.

Question 5

The Data Source page preview displays 1,000 records from a table containing several million rows. Every displayed Order_ID is populated and unique. An analyst concludes that Order_ID can safely be treated as a complete unique key.

Which assessment of the analyst's conclusion is most accurate?

  1. The conclusion is valid because Tableau previews all distinct values even when it limits displayed rows.
  2. The conclusion is valid because the preview automatically prioritizes null and duplicate key values.
  3. The conclusion is unsupported because a limited preview cannot establish uniqueness or completeness for all rows. (correct answer)
  4. The conclusion is unsupported only if Order_ID is currently classified as a measure rather than a dimension.
Explanation: Whenever you see a question about data previews or sampling in Tableau, ask yourself: does what I see in a limited sample tell me anything definitive about the full dataset? That's the core issue being tested here. Tableau's Data Source page preview displays only 1,000 rows by default — a tiny fraction of a multi-million-row table. Even if every Order_ID in that preview is populated and unique, you have no visibility into the remaining millions of rows. Those unseen rows could contain nulls, duplicates, or other anomalies. Drawing a conclusion about uniqueness and completeness across the entire dataset from a 1,000-row sample is statistically unsound, which makes C the correct answer — the analyst's conclusion is genuinely unsupported by the available evidence. A is wrong because Tableau does not preview all distinct values when it limits displayed rows. The preview is a row-limited sample, not a comprehensive scan of unique values. This answer invents a feature that doesn't exist. B is wrong for a similar reason — Tableau doesn't automatically surface nulls or duplicates in the preview. There is no such prioritization logic. The 1,000 rows shown are not curated to expose data quality issues. D is a red herring. Whether Order_ID is classified as a measure or dimension affects how Tableau aggregates or displays it, but it has absolutely nothing to do with whether a 1,000-row preview can confirm uniqueness across millions of rows. As a study tip: on Tableau exam questions involving previews or samples, always flag that a sample cannot prove a dataset-wide property — it can only suggest or hint at it.

Question 6

A database column is named cust_seg_cd. In Tableau, an analyst wants the field header to appear as Customer Segment in every worksheet without changing the database schema or replacing the displayed member values.

Which action should the analyst take on the Data Source page?

  1. Create aliases for the members and leave the Tableau field name as cust_seg_cd.
  2. Edit the remote database column name directly from the preview grid.
  3. Rename the Tableau field to Customer Segment while retaining its remote field mapping. (correct answer)
  4. Change the field's data type to String so that the header automatically adopts the new type label.
Explanation: When working with Tableau's Data Source page, it's important to distinguish between what lives in the database versus what Tableau displays to users. Tableau lets you customize field metadata — like display names — entirely within the workbook, without touching the underlying schema. The action you want here is renaming the Tableau field, which is exactly what C describes. Right-clicking a field in the Data Source page and selecting "Rename" changes the header label that appears in every worksheet to "Customer Segment," while the remote field mapping to cust_seg_cd remains intact. The database sees the original column name; Tableau shows your friendly label. This is a workbook-level change — persistent, clean, and schema-safe. A is wrong because aliases apply to member values (the individual data points inside a field, like "Seg1" → "Segment One"), not to the field header itself. Leaving the field name as cust_seg_cd means the column header stays ugly across every worksheet. B is wrong because the preview grid in Tableau is read-only — you cannot edit the remote database column name from there, nor would you want to, since the question explicitly forbids changing the database schema. D is wrong because changing a field's data type to String has no effect on the header label. Data type and display name are completely independent properties in Tableau. A helpful pattern to remember: in Tableau, aliases = member values, rename = field header. Exam questions that mention "header" or "field name" are almost always pointing you toward renaming, not aliasing.

Question 7

A data source has 180 fields. After reviewing their names and source mappings, an analyst identifies 25 unused staging columns that should be hidden. The underlying database must not be changed.

Which method is the most efficient on the Data Source page?

  1. Open each field's context menu individually and choose Hide one field at a time.
  2. Select the staging-column rows in the metadata grid and apply Hide to the selection. (correct answer)
  3. Change the staging columns to Boolean type and move them to a separate logical table.
  4. Rename the staging columns with a common prefix, then refresh the database connection.
Explanation: When working with large data sources in Tableau, the Data Source page's metadata grid is your most powerful tool for bulk field management. Questions like this test whether you know how to work efficiently across many fields at once rather than one by one. The metadata grid lets you select multiple rows simultaneously — just like selecting files in a folder — using Shift-click or Ctrl/Cmd-click. Once your 25 staging columns are selected, a single right-click opens a context menu where you can hide all of them in one action. The underlying database remains completely untouched; hiding in Tableau is purely a presentation-layer change. That makes B the correct and most efficient method. A is the trap answer for anyone who knows how to hide a field but hasn't learned about multi-select. Hiding 25 fields one at a time is technically valid but wildly inefficient — exactly what the question warns against with the word "most efficient." C is a distractor that confuses field management with data modeling. Changing data types to Boolean and reorganizing logical tables doesn't hide fields; it restructures your data model unnecessarily and could break downstream calculations. D misunderstands what a connection refresh does. Renaming columns at the Tableau layer and refreshing won't hide them — a refresh pulls updated schema information from the source but has no effect on field visibility. As a study tip, watch for Tableau questions that emphasize scale (25 fields, 180 fields, etc.) — they're usually signaling that a bulk or batch operation is the intended answer, not a repeated single-field action.

Question 8

A text-file connection contains a field named Postal_Code. Tableau infers the field as a whole number, and the preview shows values such as 2138 and 90210. The source file actually stores five-character U.S. ZIP codes, including values with leading zeros.

Which change on the Data Source page best preserves the source values and prepares the field for mapping?

  1. Assign the ZIP Code geographic role while retaining the whole-number data type.
  2. Change the data type to String, then assign the ZIP Code geographic role. (correct answer)
  3. Change the data type to Date, then assign the State/Province geographic role.
  4. Create numeric aliases that add leading zeros, then retain the whole-number data type.
Explanation: Whenever Tableau reads a text file, it infers data types automatically — and that inference can silently destroy data. This question tests whether you understand how leading zeros interact with numeric data types and how geographic roles depend on correct typing. The core problem here is that Tableau has cast Postal_Code as a whole number, so a ZIP code like "02138" becomes 2138 — the leading zero is gone permanently as long as the field stays numeric. To recover those leading zeros, you must change the data type to String first, which treats each value as text and preserves every character exactly as stored. Once the field is a String, you can assign the ZIP Code geographic role, which tells Tableau to interpret those string values as geographic identifiers for mapping. That's exactly what option B does, making it the correct answer. Option A fails because retaining the whole-number type means leading zeros remain stripped. Assigning a geographic role on top of a broken numeric field doesn't fix the underlying data — Tableau still can't match "2138" to the ZIP code "02138." Option C is a category error entirely: changing a ZIP code to the Date type is nonsensical, and State/Province is the wrong geographic role for a postal code field regardless. Option D is a workaround that doesn't actually work. Aliases in Tableau are display labels, not data transformations — they don't fix the underlying numeric value or enable accurate geographic mapping. As a study tip, remember this pairing: leading zeros → String type → then geographic role. On the Tableau exam, any time a question involves ZIP codes, phone numbers, or IDs that look numeric but contain meaningful leading zeros, String is always your first move.

Question 9

An Excel worksheet begins with a report title and two blank rows. The actual column headers appear on the fourth row, and a footnote appears below the data. Tableau's initial preview treats the title area as part of the table and assigns unhelpful field names.

What should the analyst try first on the Data Source page?

  1. Enable Data Interpreter, then verify the detected headers and data region in the preview. (correct answer)
  2. Convert every generated field to String, then promote the first displayed row manually.
  3. Hide the title and footnote fields, then use aliases to replace the generated field names.
  4. Create a union of the worksheet with itself, then filter out the title and footnote rows.
Explanation: When Tableau encounters a messy Excel file — one with titles, blank rows, or footnotes mixed into the data — it often misreads the structure and generates unhelpful field names like "F1" or "F2." The question is testing whether you know the right first tool to reach for in this situation. Tableau's Data Interpreter is purpose-built for exactly this scenario. When you enable it on the Data Source page, it analyzes the workbook, strips out extraneous content like report titles and footnotes, and correctly identifies the real header row and data region. You then verify the result in the preview to confirm it detected everything accurately. That's answer A, and it's the correct first step because it's the most direct, automated solution designed for this problem. Answer B is a manual workaround that misunderstands the root issue — converting fields to String doesn't fix misidentified headers, and "promoting" a row only works when the structure is already clean enough to interpret correctly. Answer C mistakes symptom-treating for problem-solving; hiding fields and writing aliases doesn't remove the structural confusion — it just cosmetically patches it, leaving the underlying misread data region intact. Answer D is a creative but completely inappropriate use of unions. Unioning a worksheet with itself doubles your data rows and has no mechanism for correcting header detection — it would make the problem worse, not better. A good study habit here: whenever a Tableau question describes an Excel file with non-data rows (titles, subtotals, footnotes), think Data Interpreter first. It's always the recommended starting point before manual cleanup.

Question 10

A field imported as String contains the values 2026-01-15, 2026-02-20, and pending. An analyst changes its data type to Date on the Data Source page. The preview then shows valid dates for the first two values and a null for pending.

What is the best interpretation of this result?

  1. Tableau replaced pending with a database null in the underlying source column.
  2. Tableau filtered the pending record out of both the preview and future worksheets.
  3. Tableau successfully converted pending to an unknown date member stored in the source.
  4. Tableau could not interpret pending as a date, but the source value itself remains unchanged. (correct answer)
Explanation: When Tableau changes a field's data type on the Data Source page, it's important to understand what actually happens under the hood: Tableau applies a type-casting layer on top of the source data — it does not rewrite, delete, or alter the original values in your data source. This distinction is the heart of what this question is testing. When Tableau encounters "pending" while casting to Date, it simply cannot parse that string as a valid date, so it displays a null in the preview. But that null is purely a display-level conversion result — the word "pending" still sits untouched in your source file or database. This makes D the correct interpretation. Here's why the other choices miss the mark. A is wrong because Tableau has no write access to your underlying source during a data type change on the Data Source page — it cannot and does not modify source column values. B is wrong because the record containing "pending" is not filtered out; it still appears in your data, just with a null date value. Filtering and null-conversion are two very different behaviors. C is wrong because Tableau doesn't store an "unknown date member" — it simply represents the unconvertible value as null, which is the standard behavior for any failed type cast. A useful rule of thumb: data type changes in Tableau are interpretive, not destructive. Tableau is telling you how it reads the value, not changing what's written in the source. On the exam, any answer suggesting Tableau alters source data during a type conversion should be treated with immediate suspicion.