Tableau Quiz: Field Management
10 questions · exam conditions
0:00
Field ManagementQuestion 1 of 10

A workbook contains the fields Region, State, and City. The author places all three fields in a folder named Geography. A user then adds Region to a worksheet and expects a plus sign that expands the view to State and then City.

What additional field-management action is required?

Assign all three fields the same geographic role while leaving them in the folder.
Create aliases for the three field names that reflect their geographic levels.
Create a hierarchy ordered Region, State, and City; the folder alone does not define drilling.
Convert all three fields to discrete dimensions; the folder will then support drilling.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Field Management

Practice Field Management 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 Field Management, 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

A workbook contains the fields Region, State, and City. The author places all three fields in a folder named Geography. A user then adds Region to a worksheet and expects a plus sign that expands the view to State and then City.

What additional field-management action is required?

  1. Assign all three fields the same geographic role while leaving them in the folder.
  2. Create aliases for the three field names that reflect their geographic levels.
  3. Create a hierarchy ordered Region, State, and City; the folder alone does not define drilling. (correct answer)
  4. Convert all three fields to discrete dimensions; the folder will then support drilling.
Explanation: Tableau draws a sharp distinction between two organizational tools: folders and hierarchies. Folders are purely cosmetic — they group fields in the Data pane to reduce clutter, but they carry no structural meaning about how fields relate to one another. Hierarchies, on the other hand, explicitly define a drill-down path, which is what enables that familiar plus/minus toggle on a dimension header. When you create a hierarchy and order it Region → State → City, Tableau understands that City lives "inside" State, which lives "inside" Region. Dragging Region onto a shelf then gives you the plus sign that expands the view level by level. That behavior comes entirely from the hierarchy definition — not from any folder grouping. So C is correct: the folder alone does nothing to enable drilling; you must explicitly build the hierarchy. A is a trap because geographic roles help Tableau plot fields on a map (recognizing "California" as a state, for example), but they do not create a drill-down relationship between fields. B is wrong because aliases simply rename field values for display purposes (e.g., showing "East" instead of "E") — they have no effect on data structure or hierarchy. D is wrong on two counts: fields in Tableau are already dimensions by default if they are string-type, and making fields discrete dimensions still does nothing to enable drilling through a folder — only a hierarchy does that. A reliable study rule: whenever a question mentions drill-down, expand/collapse, or plus signs on dimension headers, your immediate instinct should be hierarchy, not folder, geographic role, or aliases.

Question 2

A workbook has two Tableau data sources, Orders - Analysis and Orders - Audit, that connect to the same physical database table. In Orders - Analysis, an author renames net_amt to Net Sales and places it in a Sales Metrics folder.

What should the author expect in Orders - Audit?

  1. The field is renamed and moved automatically because both data sources use the same physical table.
  2. The field keeps its existing metadata because renames and folders are managed separately for each Tableau data source. (correct answer)
  3. The field is renamed automatically, but folder membership remains specific to each worksheet using the data source.
  4. The field keeps its name automatically, but the folder appears because folders are stored with the database connection.
Explanation: When you see a question about multiple data sources connecting to the same database, the key concept being tested is metadata ownership. In Tableau, each data source maintains its own independent layer of metadata — including field names, aliases, folders, default formats, and descriptions — completely separate from the underlying database and from any other data source, even one pointing to the same table. This is exactly why B is correct. When the author renames net_amt to Net Sales and places it in a Sales Metrics folder inside Orders - Analysis, those changes live exclusively within that data source's metadata. Orders - Audit has its own metadata layer and remains untouched — net_amt stays net_amt, and no folder appears. A is wrong because Tableau does not sync metadata changes between data sources, even when they share a physical table. The database connection and the Tableau metadata layer are two different things — sharing one does not mean sharing the other. C incorrectly suggests that renaming propagates automatically across data sources while only folder membership stays local; in reality, neither change crosses data source boundaries. D gets it exactly backwards — folders are not stored with the database connection; they are stored within the individual Tableau data source, so they would appear in Orders - Analysis only, not Orders - Audit. A helpful rule of thumb: think of each Tableau data source as its own "presentation layer" sitting on top of the database. Cosmetic and organizational changes — names, folders, aliases — belong to that layer alone and never bleed into sibling data sources.

Question 3

An analyst connects Tableau Desktop to a governed database. The source column cust_rev_amt is used by several calculated fields and worksheets. To make the workbook easier to understand, the analyst renames the field Customer Revenue in the Data pane.

What is the expected result of this change?

  1. Tableau updates references in the workbook, while the database column remains named cust_rev_amt. (correct answer)
  2. Tableau updates worksheet labels, but existing calculated fields retain the name cust_rev_amt.
  3. Tableau renames the database column and updates every workbook that uses the same connection.
  4. Tableau creates a calculated field named Customer Revenue and hides cust_rev_amt.
Explanation: When working with Tableau's Data pane, it's important to distinguish between what lives inside the workbook versus what exists in the external data source. Renaming a field in the Data pane is a purely cosmetic, workbook-level operation — you're creating an alias that Tableau displays throughout your workbook while leaving the underlying database completely untouched. This is exactly why A is correct. When you rename cust_rev_amt to Customer Revenue, Tableau automatically updates all references within that workbook — calculated fields, worksheet labels, tooltips, and axis titles all reflect the new name. Meanwhile, the database column stays named cust_rev_amt on the server, and your database administrator never needs to intervene. B is incorrect because it suggests calculated fields are somehow exempt from the rename. They aren't — Tableau's rename operation propagates consistently across all workbook components, including calculated fields that reference the original field. C describes something fundamentally impossible through the Data pane. Tableau Desktop has no ability to alter database schema or column names on a governed server. That would require database-level permissions and tools entirely outside Tableau. D confuses renaming with creating a new calculated field. No new field is created, and cust_rev_amt is not hidden — it's simply displayed under its new alias. The original field reference is preserved internally; only the display name changes. A useful rule of thumb: anything you change in Tableau's Data pane stays in the workbook. If a question mentions renaming, aliases, or display changes, ask yourself whether the action touches the source or just the presentation layer — that distinction will guide you to the right answer almost every time.

Question 4

A dimension named Service Code contains the stored values P, S, and E. Dashboard users should see Premium, Standard, and Economy, but source-level calculations and matching logic must continue to use the original stored values.

Which metadata change best satisfies these requirements?

  1. Rename the field three times so that each stored code receives its corresponding business label.
  2. Assign aliases to the dimension members while leaving the underlying values and field name unchanged. (correct answer)
  3. Create a Service Code folder and rename each code within the folder to its business label.
  4. Change the field's data type to string so Tableau expands the codes into their business labels.
Explanation: When Tableau questions ask you to change how data appears without touching what's actually stored, you're in alias territory. Aliases are a metadata-only feature that lets you substitute a display label for a dimension member while the underlying value remains completely intact — exactly what this scenario demands. Option B is the right move here. Assigning aliases to P, S, and E means dashboard viewers see Premium, Standard, and Economy, but every calculated field, filter, and data source join continues referencing the original stored codes. Nothing breaks downstream because nothing actually changed at the data level — only the visual label did. The distractors each represent a different kind of mistake. A misunderstands how renaming works in Tableau — you rename a field, not individual members within it. Renaming the field "Premium" wouldn't relabel all three codes; it would just give the entire column a new header. C invents functionality that doesn't exist: folders in Tableau organize fields in the Data pane but don't let you rename individual dimension members within them. D conflates data types with data transformation — changing a field to string type does nothing to expand coded values into descriptive labels; P would still be P, just confirmed as a string. The study tip to remember: aliases are purely cosmetic and one-directional (display only). Any time an exam scenario says users need friendlier labels but backend logic must stay the same, aliases are almost always the answer. If the requirement involved permanently changing the values themselves, you'd reach for a calculated field instead.

Question 5

Whenever analysts add Unit Price to a new view, it should initially appear as an average formatted as currency with two decimal places. Analysts must still be able to change the aggregation or formatting for an individual view when needed.

Which configuration best supports this behavior?

  1. Rename the field AVG Unit Price ($) and convert it from a measure to a dimension.
  2. Create a folder named Average Currency and place Unit Price in that folder.
  3. Set the field's default aggregation to Average and its default number format to currency with two decimals. (correct answer)
  4. Assign currency aliases to the field's values and set its geographic role to None.
Explanation: When a question asks how to control how a field behaves by default while still allowing analysts to override it per view, you're being tested on field-level default properties in Tableau. The key phrase to catch is "initially appear" combined with "still be able to change" — that signals you need a default setting, not a permanent one. Default aggregation and default number format are exactly that: field-level properties you configure in the data pane that apply automatically whenever the field is dropped into a view, but which any analyst can freely override for that specific view. Setting Unit Price's default aggregation to Average and its default format to currency with two decimal places (option C) satisfies both requirements perfectly — consistent starting behavior, full flexibility afterward. Option A fails on two levels: renaming a field doesn't change how it aggregates or formats, and converting a measure to a dimension removes aggregation entirely, which is the opposite of what's needed. Option B is a folder, which is purely an organizational tool for grouping fields visually in the data pane — it has no effect on aggregation or formatting whatsoever. Option D introduces aliases and geographic roles, neither of which has anything to do with number formatting or aggregation; aliases rename individual values (like changing "1" to "East"), and geographic roles are for mapping. A useful pattern to remember: whenever a Tableau question mentions "default behavior" for a field, think default properties — default aggregation, default sort, and default number format are all configurable at the field level and are among the most commonly tested field-management concepts on this exam.

Question 6

Tableau imports Account ID as a whole-number measure. Analysts use the values as categorical headers and filters, never in arithmetic. Existing calculations compare the IDs numerically, so the underlying data type should remain Number (whole).

Which metadata change best satisfies the requirement with the least disruption?

  1. Convert Account ID to a dimension while retaining its whole-number data type. (correct answer)
  2. Change Account ID to a string while retaining its role as a measure.
  3. Set the default aggregation of Account ID to minimum while keeping it as a measure.
  4. Assign Account ID an alias and place it in an identifier folder.
Explanation: When Tableau imports a field, it assigns both a data type (e.g., number, string, date) and a role (dimension or measure). These two properties are independent — you can change one without changing the other. Questions like this test whether you understand that distinction and can identify the minimum necessary change to meet a business requirement. Here, the requirement is simple: Account ID should behave as a categorical identifier (a dimension) rather than something you sum or average. The data type, however, must stay as Number (whole) because existing calculations depend on numeric comparisons. The cleanest solution is A — converting Account ID from a measure to a dimension while keeping its whole-number data type intact. This stops Tableau from treating it as an aggregatable metric, eliminates the SUM/AVG default behavior, and allows it to be used as a header or filter — all without touching the underlying data type that downstream calculations rely on. B fails because changing the data type to string would break any existing calculations that perform numeric comparisons on Account ID — exactly what the passage warns against. C misses the point entirely: setting a default aggregation to minimum still treats Account ID as a measure, so it would still aggregate in visualizations rather than acting as a categorical label. D is a distractor — aliases rename display values and folders are organizational tools; neither changes how Tableau aggregates or plots the field in a viz. The key study tip: on Tableau exam questions, always separate role (dimension vs. measure) from data type (number, string, date). Changing the role is often the least disruptive fix when the underlying data type must be preserved.

Question 7

Several similarly named measures appear in the Data pane. Authors need to know that Adjusted Margin excludes one-time restructuring costs. The clarification should be available while authors browse fields, but it should not alter the field name or values displayed in views.

Which field-management action is most appropriate?

  1. Add a description to Adjusted Margin explaining the exclusion and its intended use. (correct answer)
  2. Assign an alias to Adjusted Margin that contains the full calculation methodology.
  3. Rename Adjusted Margin to include the complete exclusion rule in the field name.
  4. Place Adjusted Margin in a folder whose name contains the complete methodology.
Explanation: When a question asks how to communicate metadata about a field without changing its name or values, you should immediately think about Tableau's field description feature — a tool specifically designed to store contextual information that authors can read while browsing the Data pane. Adding a description to Adjusted Margin, as option A suggests, is exactly right here. Descriptions appear as tooltips when you hover over a field in the Data pane, making the clarification visible during field selection without modifying the field name or affecting any values displayed in views. It satisfies every constraint the passage sets: available while browsing, non-intrusive, and display-neutral. Option B is a trap because aliases apply to dimension members (individual values like "East" or "West"), not to measures or field-level documentation. You cannot assign an alias to a measure field itself, so this option fundamentally misapplies the feature. Option C violates the passage's explicit requirement — renaming the field does alter the field name as it appears in views, which authors and end users would see everywhere the field is used. Option D repurposes folder names as documentation, which is an organizational workaround rather than a proper metadata solution. Folder names are meant for grouping related fields, not encoding calculation logic, and this approach clutters the Data pane organization without providing contextual tooltips. A useful study pattern: when Tableau questions mention providing context without altering display, think descriptions first. Aliases change labels for dimension members, renames change field labels everywhere, and folders organize — only descriptions add invisible-but-accessible metadata to a field.

Question 8

A data source contains 150 fields. An author wants fields such as Revenue, Cost, and Margin placed under a Finance heading in the Data pane. Users should still be able to add any of these fields independently, and no drill-down relationship is needed.

Which action best meets the requirement?

  1. Create a hierarchy named Finance and place the three measures in hierarchy order.
  2. Group the Data pane by folder and place the three fields in a Finance folder. (correct answer)
  3. Create a set named Finance containing the three fields as selectable members.
  4. Group the Data pane by data source table and rename the source table Finance.
Explanation: When organizing a large Data pane in Tableau, the key question to ask is: what organizational tool preserves field independence while grouping fields visually? That distinction separates folders from other Tableau features that fundamentally change how fields behave. Folders are exactly the right tool here. By switching the Data pane to "Group by Folder" mode and creating a folder named Finance, you can place Revenue, Cost, and Margin under that heading. Each field remains a fully independent measure — users drag any one of them onto a view without affecting the others. This directly satisfies all three requirements: visual grouping, independent use, and no enforced drill-down. Answer B is correct. Answer A fails because a hierarchy in Tableau creates an explicit drill-down relationship between fields (e.g., Year → Quarter → Month). Placing measures like Revenue and Cost inside a hierarchy implies they have a parent-child traversal order, which the question explicitly says is not needed. Hierarchies also require users to interact with the expand/collapse structure. Answer C confuses organizational tools with analytical ones. A set in Tableau represents a subset of data members (rows) within a single dimension — it doesn't group fields in the Data pane at all. Sets cannot contain multiple different measures. Answer D misuses table grouping. Renaming a source table affects how Tableau reads the underlying connection and applies to all fields from that table — it's a blunt instrument that doesn't let you selectively place only three specific fields under a custom heading. Study tip: On Tableau exam questions, whenever you see "organize fields visually without changing behavior," think folders. Hierarchies = drill-down structure; sets = row-level subsets; folders = pure organization.

Question 9

Before publishing a data source, an author wants to remove clutter from the Data pane and reduce an extract by excluding technical columns that are not used in any worksheet, calculation, filter, set, or other workbook object. The columns may need to be restored later.

Which sequence is most appropriate?

  1. Create the extract first, and then place all technical columns in a folder named Unused; the folder suppresses those columns from the extract automatically.
  2. Delete the technical columns from the database, and then refresh the Tableau data source to reflect the schema change.
  3. Rename the technical columns with a leading underscore prefix, and then collapse their folder so they are excluded from the published extract.
  4. Hide all unused fields before creating the extract, and unhide specific fields later from the data source if they are required. (correct answer)
Explanation: When working with Tableau extracts and published data sources, the key concept being tested here is field visibility versus permanent deletion — specifically, how hiding fields affects extract size and Data pane clutter while preserving the ability to recover those fields later. Hiding unused fields before creating an extract is the correct workflow because Tableau excludes hidden fields from the extract itself, reducing its size. If those fields are needed later, you can simply unhide them from the data source and refresh — no data is permanently lost. This makes option D the most appropriate sequence: it satisfies all three requirements stated in the passage (declutter the Data pane, reduce the extract, and allow restoration later). Option A is wrong because placing columns in a folder does absolutely nothing to the extract. Folders are purely organizational within the Data pane — they have no effect on what data gets included in an extract file. Option B is wrong for a more serious reason: deleting columns directly from the database is a destructive, irreversible action at the source level. The passage explicitly states the columns may need to be restored, making this approach completely inappropriate regardless of technical correctness. Option C is wrong because renaming fields with a prefix and collapsing their folder is just cosmetic organization. Like folders, a naming convention or collapsed view does not exclude fields from an extract. The fields would still be pulled into the extract file. As a study tip, remember this pattern: on Tableau questions involving data reduction and reversibility, hide is almost always preferred over delete or rename. "Hide" is Tableau's built-in, non-destructive tool for exactly this scenario.

Question 10

A source column named Sales is used in many calculations, filters, and worksheets. The database team replaces it with a new column named Net Sales. After the data source is refreshed, Tableau shows the old field as invalid and the new field as a separate field. Both fields represent the same business measure.

Which action most directly repairs the workbook while preserving existing uses of the old field?

  1. Rename the invalid Sales field to Net Sales, and then hide the newly detected field.
  2. Create a folder containing both fields so Tableau resolves their shared business meaning.
  3. Duplicate every affected worksheet and replace the invalid pills with Net Sales manually.
  4. Use Replace References to replace the invalid Sales field with the valid Net Sales field. (correct answer)
Explanation: When a database renames a column that your workbook already depends on, Tableau can't automatically match the old field to the new one — it simply marks the old field as invalid and surfaces the new column separately. Your goal is to reconnect all existing references (calculations, filters, worksheets) to the valid field in one clean operation, which is exactly what Replace References is designed to do. Right-clicking the invalid Sales field and selecting Replace References, then pointing to Net Sales, tells Tableau to swap every use of the old field across the entire workbook simultaneously. No pill goes unaddressed, no calculation breaks, and you haven't manually hunted through dozens of worksheets. That makes D the most direct and complete repair. A is tempting but wrong. Renaming the invalid field to "Net Sales" only changes a label — it doesn't reconnect the field to the actual database column, so it remains invalid. Hiding the newly detected field just obscures the problem rather than solving it. B is a misunderstanding of folders. Folders are purely a visual organization tool in the Data pane; they carry no logic that would merge or resolve two fields into one business measure. C would technically work eventually, but it's the most labor-intensive path possible. Duplicating worksheets and manually swapping pills is error-prone and ignores the built-in tool that exists precisely to avoid this work. For the Tableau exam, whenever a question involves a broken or renamed source field affecting multiple locations in a workbook, think Replace References first — it's the workbook-wide, single-action fix Tableau built specifically for this scenario.