Tableau Quiz: Geographic Roles
10 questions · exam conditions
0:00
Geographic RolesQuestion 1 of 10

A U.S. postal-code field was imported as a number. A record from Cambridge, Massachusetts, appears as 2138 rather than 02138. Changing the field's data type directly to String produces "2138," which Tableau does not recognize as the intended postal code.

What should you do before validating the locations on a map?

Assign the numeric field the Area Code role and set Massachusetts as the default state.
Create a five-character, zero-padded string field and assign it the Postal Code role.
Convert the numeric field to a date string and assign it the Postal Code role.
Assign the original field the Postal Code role and increase its default number format to five digits.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Geographic Roles

Practice Geographic Roles 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 Geographic Roles, 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 U.S. postal-code field was imported as a number. A record from Cambridge, Massachusetts, appears as 2138 rather than 02138. Changing the field's data type directly to String produces "2138," which Tableau does not recognize as the intended postal code.

What should you do before validating the locations on a map?

  1. Assign the numeric field the Area Code role and set Massachusetts as the default state.
  2. Create a five-character, zero-padded string field and assign it the Postal Code role. (correct answer)
  3. Convert the numeric field to a date string and assign it the Postal Code role.
  4. Assign the original field the Postal Code role and increase its default number format to five digits.
Explanation: Whenever you see a question about geographic data in Tableau, think about two separate problems: data formatting and role assignment. Both must be correct for Tableau to map locations accurately. The core issue here is that importing ZIP codes as numbers silently strips leading zeros — "02138" becomes "2138," a fundamentally different string. Simply changing the data type to String preserves that broken value. The real fix requires you to reconstruct the full five-character format first, then tell Tableau what the field represents. You do this by creating a calculated field using STR(INT([ZipCode])) padded with ZN or a LEFT("00000", 5 - LEN(...)) pattern to restore the leading zero, producing "02138." Once that calculated field exists as a proper string, you assign it the Postal Code geographic role so Tableau can geocode it correctly. That's exactly what B describes. A is wrong because "Area Code" is a telephone-related role, not a postal role — assigning it won't enable ZIP-code geocoding, and setting a default state doesn't fix the missing leading zero. C is wrong because converting a numeric field to a date string is logically nonsensical for postal codes, and would corrupt the values entirely rather than restore them. D is wrong because formatting a number to display five digits (e.g., using a custom number format) changes only the visual display in a worksheet — Tableau still treats the underlying value as numeric 2138, not the string "02138," so the geographic role won't resolve correctly. Remember this pattern: fix the data before assigning the role. Format first, geocode second.

Question 2

A U.S. data set contains County and State fields. County includes repeated names such as Washington, Jefferson, and Franklin in several states. Mapping County alone produces locations, but a sample comparison shows that some marks were assigned to the wrong state.

Which change best resolves the ambiguity while preserving county-level analysis?

  1. Assign County the County role and State the State/Province role, then include State as geographic context in the view. (correct answer)
  2. Assign County the City role and State the Country/Region role, then combine them using Measure Names.
  3. Assign both County and State the County role, then hide the State header after Tableau generates the map.
  4. Assign County the County role alone, then choose one default state for all records in Edit Locations.
Explanation: When mapping county-level data in Tableau, ambiguity arises because hundreds of counties share the same name across different states. Tableau resolves this by using geographic role hierarchies — assigning both the county field and a higher-level context field their proper roles so Tableau can triangulate the correct location. The right approach is A: assign County the County geographic role and State the State/Province role, then include State in the view as geographic context. When Tableau sees both fields together, it narrows down which "Washington County" belongs to which state, placing every mark correctly. This preserves county-level granularity while eliminating the misassignment problem. B is wrong because assigning County the City role misrepresents the data type — Tableau's geocoding database treats cities and counties as distinct entity types, so you'd introduce new geocoding errors. Measure Names is also irrelevant here; it's for blending measure labels, not resolving geographic hierarchy. C is wrong because assigning State the County role doesn't give Tableau the hierarchical context it needs. Hiding the State header afterward doesn't fix the underlying geocoding logic — it just conceals the State dimension visually while the ambiguity remains unresolved. D is wrong because Edit Locations lets you manually fix individual records, but forcing a single default state onto all records would incorrectly reassign every county in other states to that one state — the opposite of what you want. Study tip: On geographic questions, think in terms of hierarchy. Whenever a lower-level field (city, county, zip) appears ambiguous, the fix is almost always pairing it with a properly-roled higher-level field, not editing records manually or misassigning roles.

Question 3

A Country field contains "United States," "USA," "U.S.A.," and "Untied States." After the Country/Region role is assigned, some variants remain unknown. Analysts must preserve the original field for auditing and apply the correction automatically after each data refresh.

Which preparation method is most appropriate?

  1. Change the original field to a measure and use COUNTD to combine all country-name variants.
  2. Create a calculated field that standardizes the variants, then assign it the Country/Region role. (correct answer)
  3. Assign the original field the City role first, then nest it beneath a generated country hierarchy.
  4. Filter all unknown variants from the map and retain the original field as the geographic dimension.
Explanation: When you see a question involving inconsistent geographic data and audit requirements, think about two goals simultaneously: data integrity (preserving the original) and data usability (making values recognizable to Tableau's geographic engine). The best solutions address both without destroying the source record. A calculated field is the right tool here. By writing a formula that maps "USA," "U.S.A.," and "Untied States" to "United States," you create a clean, standardized field that sits alongside the original — leaving the raw data untouched for auditing. Assigning the Country/Region geographic role to that calculated field then lets Tableau resolve locations correctly on maps. Because calculated fields recompute automatically on every data refresh, the correction applies consistently without manual intervention. That's exactly what the scenario requires, making B the correct answer. A is wrong because converting a field to a measure and using COUNTD aggregates records into a count — it doesn't standardize text values or enable geographic mapping. You'd lose dimensional context entirely. C is wrong because assigning a Country field the City role actively misleads Tableau's geographic engine. Nesting it under a generated hierarchy doesn't fix the underlying misclassification; it compounds it. D is wrong because filtering unknown variants removes them from analysis rather than correcting them. The scenario explicitly requires preserving and correcting the data, not discarding problem records. A useful pattern to remember: whenever a scenario mentions auditing + automatic correction, think calculated field layered over the original. Tableau's geographic roles work on whatever field you assign them to — so build a clean field, then assign the role there.

Question 4

After assigning the City geographic role and creating a map, Tableau displays an unknown-locations indicator. Most records are correctly plotted, but the source contains the city value "St. Louiis." The source system cannot be changed immediately.

Which workflow best validates and corrects this issue within the workbook while retaining the record?

  1. Select the unknown-locations indicator, open Edit Locations, and match the misspelled value to St. Louis. (correct answer)
  2. Select the unknown-locations indicator and choose Filter Data so the map contains only recognized cities.
  3. Change the field's role from City to State/Province so Tableau searches a broader location database.
  4. Convert the city field to a measure and use ATTR so the misspelled value is aggregated.
Explanation: When Tableau can't geocode a location value, it flags it with an unknown-locations indicator — a small icon on the map that signals one or more values didn't match Tableau's internal geographic database. Your goal in that situation is to investigate and fix the mismatch without losing any data, which is exactly what this question tests. The right move is A: clicking the unknown-locations indicator opens the Edit Locations dialog, where Tableau lists every unrecognized value. From there, you can manually map "St. Louiis" to the correct entry, "St. Louis," in Tableau's geocoding database. The record stays in your dataset, the pin appears on the map, and you haven't touched the source system — a clean, non-destructive fix entirely within the workbook. B is a trap because filtering out unrecognized locations removes the affected records from the view entirely. You'd "solve" the map problem by silently discarding data, which defeats the goal of retaining the record. C is logically flawed — switching the geographic role to State/Province doesn't fix a typo; it changes what Tableau is trying to match the field against, and "St. Louiis" still won't resolve correctly as a state name. D is a misuse of aggregation. ATTR() is used to display a dimension value when all rows in a partition share the same value — it has nothing to do with geocoding or correcting location mismatches. A helpful pattern to remember: whenever a question mentions unknown locations on a map, your first instinct should be Edit Locations. It's Tableau's dedicated tool for geocoding corrections and is almost always the right answer in these scenarios.

Question 5

A data source contains the fields City and Nation. City includes values such as "Cambridge," "Richmond," and "Victoria," while Nation identifies the country for each record. After City is assigned the City geographic role, several marks appear in the wrong country.

Which action most directly uses the available data to resolve the ambiguous city locations?

  1. Assign Nation the Country/Region role, then use Nation as the country context for City in Edit Locations. (correct answer)
  2. Assign Nation the State/Province role, then place it on Color to separate cities by national boundary.
  3. Convert City to a measure, then aggregate it by Nation before recreating the map.
  4. Keep only City on Detail, then select a single default country for every city in Edit Locations.
Explanation: When a city name exists in multiple countries — like "Cambridge" appearing in both England and the United States — Tableau can't determine the correct location on its own. This is the classic geographic ambiguity problem, and the solution lies in providing Tableau with hierarchical context: telling it which country a city belongs to before it plots the point. The most direct fix is answer A. By assigning Nation the Country/Region geographic role and then referencing it as the country context for City inside Edit Locations, you're giving Tableau a field-level disambiguation signal. Tableau's Edit Locations dialog explicitly lets you set a "country" context field so each city resolves within the correct national boundary — using data that already exists in your source. Answer B is tempting but wrong. Assigning Nation a State/Province role misrepresents the data's actual geographic level, and placing it on Color only separates marks visually — it doesn't fix where the marks are plotted. The underlying geocoding error remains. Answer C is a misunderstanding of Tableau's data types. Converting a geographic dimension to a measure doesn't interact with geocoding at all; aggregating text by Nation produces nonsensical results and cannot regenerate accurate map coordinates. Answer D partially uses Edit Locations but takes the wrong approach. Forcing a single default country onto every city ignores the Nation field entirely and would incorrectly assign cities from other countries to that one default — making the problem worse, not better. Study tip: When you see geographic ambiguity questions, think hierarchy first — country → state → city. Tableau resolves ambiguous places when you assign and connect the appropriate higher-level geographic role through Edit Locations.

Question 6

A field called Region contains the values Georgia, Washington, Oregon, and Nevada. Tableau initially assigns no geographic role. All records represent U.S. states, although "Georgia" could also refer to a country.

Which configuration most accurately communicates the field's meaning and reduces ambiguity?

  1. Assign Region the Country/Region role because Georgia is a recognized sovereign country.
  2. Assign Region the City role and set the United States as the default country.
  3. Assign Region the State/Province role and establish the United States as its country context. (correct answer)
  4. Assign Region the County role and place a generated State field on Detail.
Explanation: When you see a question about geographic roles in Tableau, ask yourself two things: what level of geography do the values actually represent, and what additional context eliminates ambiguity? The goal is precision — the right role should match the data's true granularity while resolving any conflicts Tableau might encounter. Here, the values Georgia, Washington, Oregon, and Nevada are all U.S. states. Assigning the State/Province role tells Tableau exactly what level of geography these values occupy. Pairing that role with a United States country context is the critical second step — it disambiguates "Georgia," which Tableau might otherwise interpret as the country in Eastern Europe. Together, these settings give Tableau an unambiguous geocoding path. That's why C is correct. A is tempting because Georgia is a country, but that's precisely the trap. The other three values — Washington, Oregon, and Nevada — are unambiguously U.S. states, not countries. Assigning a Country/Region role misrepresents the entire field just to accommodate one possible interpretation of a single value. B goes in the wrong direction entirely. City is a finer level of geography than what the data represents. Washington, Oregon, and Nevada are not cities, so this role would produce geocoding errors across most records. D is overcomplicated and conceptually wrong. County is a sub-state level, which is too granular. Adding a generated State field on Detail doesn't fix the mismatch — it just layers more confusion on top of an incorrect foundation. Your takeaway: when a field contains ambiguous geographic names, the right fix is selecting the correct geographic level and setting a country context — not upgrading or downgrading the role to avoid the conflict.

Question 7

A data set contains numeric fields named Y_Coord and X_Coord. Documentation confirms that Y_Coord stores latitude and X_Coord stores longitude in decimal degrees. Tableau currently treats both fields as ordinary numbers.

Which configuration correctly prepares a point map from these fields?

  1. Assign Y_Coord the Longitude role and X_Coord the Latitude role; place X_Coord on Rows and Y_Coord on Columns.
  2. Assign both fields the City role; place X_Coord on Detail and Y_Coord on Rows.
  3. Assign Y_Coord the Latitude role and X_Coord the Longitude role; place X_Coord on Columns and Y_Coord on Rows. (correct answer)
  4. Leave both as ordinary measures without geographic roles; place Y_Coord on Columns and X_Coord on Rows.
Explanation: When working with custom geographic coordinates in Tableau, two things must be correct simultaneously: the geographic role assigned to each field, and which shelf each field lives on. Getting either one wrong produces a broken or misplotted map. Latitude and longitude have specific, fixed meanings. Latitude measures north-south position and maps to the vertical axis (Rows shelf). Longitude measures east-west position and maps to the horizontal axis (Columns shelf). Tableau's map engine is built around this convention — it won't compensate if you swap them. Since Y_Coord stores latitude and X_Coord stores longitude, answer C is correct: assign Y_Coord the Latitude role and X_Coord the Longitude role, then place X_Coord on Columns and Y_Coord on Rows. This tells Tableau both what the numbers mean and where to plot them. Answer A swaps the roles entirely — assigning longitude to Y_Coord and latitude to X_Coord — and also reverses the shelf placement, compounding the error. Your points would plot in the wrong locations. Answer B assigns both fields a "City" geographic role, which is meaningless for raw decimal-degree coordinates; Tableau's City role expects text names it can geocode, not numeric values. Answer D skips assigning geographic roles altogether, so Tableau renders a standard scatter plot instead of a map, and placing Y_Coord (latitude) on Columns further violates the axis convention. A useful memory device: Y = vertical = Rows = Latitude; X = horizontal = Columns = Longitude. On the exam, whenever you see coordinate fields, check both the role assignment and the shelf placement — exam distractors almost always get one of the two wrong.

Question 8

A file contains two coordinate fields, Coord_A and Coord_B. Most Coord_A values range from 95 to 125, while most Coord_B values range from 25 to 49. The records represent locations in the contiguous United States, but the fields are undocumented.

Which interpretation should you test first, and how should you validate it?

  1. Treat Coord_A as latitude and Coord_B as longitude, then confirm that Tableau reports no null measures.
  2. Treat Coord_A as longitude and Coord_B as latitude, then verify plotted sample points against known locations. (correct answer)
  3. Treat both fields as latitude because both value ranges are positive, then aggregate them using AVG.
  4. Treat both fields as longitude because neither contains city or state names, then rely on generated latitude.
Explanation: When working with undocumented coordinate fields, your first move is to apply geographic knowledge to narrow down which field is which. For the contiguous United States, latitude values fall roughly between 24°N and 49°N, and longitude values fall between about 67°W and 125°W (stored as negative numbers in most systems, but sometimes as positive raw values). Notice that Coord_B's range of 25–49 aligns perfectly with US latitude, while Coord_A's range of 95–125 aligns with US longitude magnitude — making B the correct answer. You should assign Coord_A as longitude and Coord_B as latitude, then validate by plotting a handful of known cities and confirming the points land where expected. This ground-truth check is the gold standard for geographic validation. Choice A gets the assignment backwards — swapping latitude and longitude would scatter points into the ocean or foreign countries, and checking for null measures wouldn't catch that error at all. Null measures only confirm that data exists, not that it's mapped correctly. Choice C is nonsensical geographically: two fields cannot both represent latitude for the same location. The fact that both ranges are positive is irrelevant — longitude is frequently stored as a positive absolute value. Choice D makes a similarly flawed leap. The absence of city or state names in a field says nothing about whether it encodes longitude. Relying on Tableau's "generated latitude" without verifying the source data just layers an assumption on top of a wrong one. Study tip: Memorize the approximate bounding box of the contiguous US (lat 24–49, lon 67–125) — it's a quick mental filter for any coordinate ambiguity question on the Tableau exam.

Question 9

A sales field named Management District contains North, Central, Coastal, and Strategic Accounts. These are company-defined territories rather than official geographic entities. Each record also contains a valid postal code that Tableau recognizes.

How should you build and validate a geographic view without misrepresenting Management District?

  1. Assign Management District the State/Province role and resolve each unknown value to the nearest state.
  2. Assign Management District the Country/Region role and use postal code only as a text label.
  3. Assign Management District the City role and set the default location to the company's headquarters.
  4. Map the Postal Code field using its geographic role, then use Management District to categorize the marks. (correct answer)
Explanation: When Tableau assigns a geographic role to a field, it tries to geocode that field's values against known geographic entities. The critical question here is: does your data field actually represent a recognized geography, or does it represent something else that merely sounds geographic? Management District values like "North," "Central," and "Coastal" are internal business territories — Tableau has no geocoding knowledge of them. Forcing these labels into a legitimate geographic role produces unreliable or fabricated map placements. The postal codes, however, are genuine geographic identifiers that Tableau can confidently geocode. Answer D is correct because it separates these two concerns cleanly: let Postal Code do the geographic heavy lifting (plotting accurate map coordinates), then use Management District as a categorical dimension to color, group, or filter those marks. This gives you a geographically accurate map that also reflects your business segmentation — without misrepresenting either field. Answer A is a common trap — assigning "North" or "Central" to the State/Province role would force Tableau to guess or error on unrecognized values, potentially snapping records to wrong states and corrupting your map. Answer B makes a similar mistake: treating Management District as Country/Region would either fail geocoding entirely or match against real countries with those names, producing nonsense placements. Answer C compounds the error by adding a headquarters default location, which would collapse all your data onto a single point rather than distributing it geographically. The pattern to remember: geographic roles belong to fields whose values Tableau can actually look up in its geocoding database. When a field is a business category, keep it as a dimension attribute and let a properly recognized geographic field — like postal code or state — handle the spatial placement.

Question 10

A field named Store Code contains five-digit identifiers. After it is assigned the Postal Code geographic role, Tableau recognizes every value and plots stores across the United States. The data owner explains that these are internally generated store numbers and have no relationship to postal codes.

What is the most appropriate conclusion from this validation result?

  1. The Postal Code role is valid because Tableau reported no unknown geographic values.
  2. The Postal Code role is valid only if Store Code is first converted from a dimension to a measure.
  3. The role is invalid because geographic roles require field names that match Tableau's standard names.
  4. The role is semantically invalid even though the codes coincidentally match recognized postal codes. (correct answer)
Explanation: When working with geographic roles in Tableau, it's critical to distinguish between technical validity and semantic validity. A geographic role is technically valid when Tableau can match field values to its internal geographic database — but that says nothing about whether the assignment is meaningful. Here, store codes happen to be five digits, the same format as U.S. postal codes. Tableau's geographic matching is purely pattern-based: it checks whether values exist in its lookup table, not whether your field represents what that role implies. Since the store codes coincidentally align with real postal codes, Tableau plots them without complaint. That technical success, however, masks a conceptual error — the data means something entirely different from what the role claims. This makes D correct. The role is semantically invalid: the codes carry no geographic meaning, so any map built from them shows locations that are accurate by accident, not by design. The visualization would be misleading. A is the classic trap here — it confuses Tableau's lack of errors with correctness. No unknown values simply means the values matched, not that the match was appropriate. B is irrelevant because converting a dimension to a measure has no bearing on whether a geographic role is valid; geographic roles apply to dimensions, and the field type isn't the issue. C is false because Tableau assigns geographic roles based on field values, not field names — you can name a field anything and still assign any geographic role you choose. The study takeaway: on Tableau exam questions, always ask whether a result is technically successful and semantically meaningful. These two things can come apart, and questions are often designed to test exactly that distinction.