Tableau Quiz: Basic Chart Types
10 questions · exam conditions
0:00
Basic Chart TypesQuestion 1 of 10

A worksheet must compare SUM(Sales) for each Category within each Region. The analyst wants vertical bars placed side by side, grouped first by Region, rather than category segments stacked in one bar.

Which configuration best produces the requested bar chart?

Place Region followed by Category on Columns, place SUM(Sales) on Rows, and use the Bar mark type.
Place Region on Columns, SUM(Sales) on Rows, place Category on Color, and keep Stack Marks enabled.
Place Category followed by Region on Columns, place SUM(Sales) on Rows, and use the Bar mark type.
Place Region on Rows, SUM(Sales) on Columns, place Category on Color, and keep Stack Marks enabled.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Basic Chart Types

Practice Basic Chart Types 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 Basic Chart Types, 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 worksheet must compare SUM(Sales) for each Category within each Region. The analyst wants vertical bars placed side by side, grouped first by Region, rather than category segments stacked in one bar.

Which configuration best produces the requested bar chart?

  1. Place Region followed by Category on Columns, place SUM(Sales) on Rows, and use the Bar mark type. (correct answer)
  2. Place Region on Columns, SUM(Sales) on Rows, place Category on Color, and keep Stack Marks enabled.
  3. Place Category followed by Region on Columns, place SUM(Sales) on Rows, and use the Bar mark type.
  4. Place Region on Rows, SUM(Sales) on Columns, place Category on Color, and keep Stack Marks enabled.
Explanation: When building a grouped bar chart in Tableau, the key question is: what controls grouping versus what controls the individual bars within each group? The order of dimensions on the Columns shelf determines the visual hierarchy — the first dimension creates the outer groups, and the second dimension creates the individual bars nested inside each group. Since the requirement is to group first by Region and then compare Categories side by side within each Region, you need Region as the leading dimension on Columns, followed by Category. Adding SUM(Sales) on Rows and selecting the Bar mark type then produces exactly the described layout — vertical bars for each Category, clustered together under their respective Region header. That's option A, the correct answer. Option B places Region on Columns and Category on Color with Stack Marks enabled. Color with stacking produces a stacked bar — one bar per Region with Category segments layered inside it, which is explicitly what the question asks you not to do. Option C reverses the dimension order (Category first, then Region), which groups bars by Category first and nests Regions inside — the opposite of the requirement. Option D places Region on Rows and SUM(Sales) on Columns, which produces horizontal bars, not vertical ones, and the stacking issue from B still applies. Study tip: In Tableau, the first dimension on Columns (or Rows) is always your primary grouping. When a question specifies "grouped by X, broken down by Y," translate that directly to the shelf order: X first, then Y. Stacked vs. side-by-side is a separate decision controlled by the Stack Marks setting.

Question 2

After placing SUM(Sales) on Columns and SUM(Profit) on Rows, Tableau displays one mark representing the entire data source. The required scatter plot must contain one aggregated mark per customer, not one mark per transaction.

What should the analyst do next?

  1. Clear Analysis > Aggregate Measures so Tableau creates a separate mark from every underlying transaction row.
  2. Place Customer Name on Filters and select all customers so the aggregate mark is divided automatically.
  3. Place Customer Name on Detail while leaving Aggregate Measures enabled for the two measures. (correct answer)
  4. Place Customer Name on Rows so Tableau creates a separate scatter-plot pane for every customer.
Explanation: Whenever you see a question about controlling the level of detail in a Tableau scatter plot, focus on one core idea: the number of marks is determined by the fields that define granularity — not by the measures themselves. By default, Tableau aggregates everything into a single mark when only measures sit on the view. To split that single mark into one mark per customer, you need to introduce Customer Name into the view at the right level without changing the chart's structure. Placing Customer Name on Detail (C) is exactly the right move. Detail is a Marks card property that increases granularity — telling Tableau "compute separate aggregates for each customer" — without adding axes, panes, or filters. With Aggregate Measures still enabled, SUM(Sales) and SUM(Profit) are calculated per customer, giving you exactly one aggregated mark per customer on the same single scatter-plot canvas. A is wrong because disabling Aggregate Measures switches Tableau to row-level mode, so each transaction becomes its own mark — the opposite of what you need. This would flood the scatter plot with individual rows rather than per-customer totals. B is wrong because filtering to all customers doesn't change granularity at all. Filtering controls which data is included, not how marks are grouped. You'd still see one aggregated mark representing all selected customers. D is wrong because placing Customer Name on Rows creates a separate horizontal pane for every customer — turning the view into hundreds of mini-charts rather than a unified scatter plot. The study tip: on Tableau questions, always ask yourself "what controls the number of marks?" The answer is almost always what's on Detail, Color, Size, or a discrete dimension on Rows/Columns — not filtering or aggregation settings alone.

Question 3

A monthly area chart currently shows raw SUM(Sales) for each month. Management instead wants the area height in March to represent January sales plus February sales plus March sales, with accumulation continuing through the year.

Which change produces the requested result?

  1. Keep SUM(Sales) unchanged, choose Area marks, and enable Stack Marks so earlier months contribute to later months.
  2. Apply a Running Total table calculation to SUM(Sales), compute it along Month, and retain the Area mark type. (correct answer)
  3. Apply Percent of Total to SUM(Sales), compute it along Month, and retain the Area mark type.
  4. Apply WINDOW_SUM to the full monthly partition so every month displays the same annual sales total.
Explanation: When a question asks you to accumulate values over time — where each period's display represents all prior periods summed together — you're being tested on table calculations, specifically the difference between Running Total, Percent of Total, and window aggregations. The scenario describes a classic running sum: March should show Jan + Feb + Mar, April should show Jan through Apr, and so on. That's precisely what a Running Total table calculation does. By applying it to SUM(Sales) and computing it along the Month dimension, Tableau sequentially adds each month's value to all previous months. B is correct because it directly matches this accumulative behavior while preserving the area chart's visual encoding of magnitude over time. Choice A is a tempting trap. Stacking marks in an area chart is relevant when you have multiple series (dimensions on Color) layered on top of each other — it doesn't cause a single series to accumulate across time. Your single SUM(Sales) measure would still show raw monthly values. Choice C applies Percent of Total, which recalculates each month as its share of the annual total (e.g., 8.3% if all months were equal). This answers "what proportion?" not "what is the cumulative sum?" — a fundamentally different question. Choice D uses WINDOW_SUM over the entire partition, which returns the same grand total for every month. Every bar or area segment would be identical in height — the opposite of a progressive accumulation. Study tip: When you see "accumulate," "running," or "year-to-date" in a question, immediately think Running Total table calculation computed along the date dimension — that's Tableau's dedicated tool for this pattern.

Question 4

A dashboard needs a horizontal bar chart of the ten products with the highest SUM(Sales). The membership of the top ten must update when refreshed data changes product rankings.

Which sequence most directly creates the required worksheet?

  1. Filter Product Name to Top 10 by SUM(Sales), place Product Name on Rows and SUM(Sales) on Columns, then sort descending. (correct answer)
  2. Sort Product Name by SUM(Sales), manually select the first ten product names in a general filter, then use horizontal bars.
  3. Filter Product Name to Top 10 by COUNT(Sales), place Product Name on Rows and SUM(Sales) on Columns, then sort descending.
  4. Filter Product Name to Top 10 by SUM(Profit), place Product Name on Rows and SUM(Sales) on Columns, then sort descending.
Explanation: When building dynamic top-N views in Tableau, the critical distinction is between filters that compute the top members automatically versus those that hardcode a selection. Any time a question mentions that the ranking must update with refreshed data, you need a computed Top filter — not a manual one. The right approach is A: applying a Top 10 filter on Product Name by SUM(Sales), placing Product Name on Rows and SUM(Sales) on Columns, then sorting descending. Tableau's built-in Top filter recalculates which products qualify every time the data refreshes, so the view stays accurate without any manual intervention. Placing a dimension on Rows and a measure on Columns naturally produces a horizontal bar chart. B is the most dangerous distractor. Manually selecting ten product names creates a hardcoded general filter — if rankings shift after a data refresh, those same ten names stay selected regardless of whether they still belong in the top ten. This directly violates the "must update when refreshed" requirement. C uses COUNT(Sales) as the ranking metric instead of SUM(Sales). This filters by how many sales transactions exist per product, not total revenue — a completely different ranking that won't reliably surface the highest-selling products by dollar amount. D filters by SUM(Profit) to determine the top ten, but then displays SUM(Sales). The products with the highest profit are not necessarily the products with the highest sales, so the view would show the wrong set of products for the stated goal. A reliable study tip: whenever you see "top N" combined with "updates dynamically," immediately look for the answer that uses Tableau's built-in Top filter by the same measure being analyzed — that pairing is almost always correct.

Question 5

An analyst needs a single area chart showing monthly total expenses. Each month's total must be visibly divided into stacked contributions from Department.

Which approach meets both requirements?

  1. Place continuous MONTH(Date) on Columns, SUM(Expense) on Rows, Department on Columns, and choose Area marks.
  2. Place continuous MONTH(Date) on Columns, SUM(Expense) on Rows, Department on Detail, and turn Stack Marks off.
  3. Place continuous MONTH(Date) on Columns, SUM(Expense) on Rows, Department on Color, and turn Stack Marks off.
  4. Place continuous MONTH(Date) on Columns, SUM(Expense) on Rows, Department on Color, and turn Stack Marks on. (correct answer)
Explanation: When building stacked area charts in Tableau, you need to think about two distinct settings working together: how data is segmented and how marks are stacked. The segmentation control determines which dimension splits your measure into separate series, while Stack Marks determines whether those series layer on top of each other or overlap independently. For a single area chart where monthly totals are visibly divided by Department, you need Department on Color — this creates one area series per department within a single chart pane — and Stack Marks set to On. With stacking enabled, each department's area sits on top of the previous one, so the combined height at any month equals the total expense, and each colored band shows that department's contribution. That's exactly what option D provides, making it the correct answer. Option A places Department on Columns, which splits the view into separate chart panes — one per department — rather than a single unified chart. That violates the "single area chart" requirement immediately. Option B puts Department on Detail, which does partition the data into separate marks but provides no color differentiation between departments, so the contributions aren't visibly distinct. Additionally, turning Stack Marks off means areas would overlap rather than stack, further obscuring the breakdown. Option C is the closest distractor: it correctly uses Department on Color, but turning Stack Marks off causes the department areas to overlap rather than stack. You'd lose the clear view of each department's contribution and the running total would be unreadable. Remember this pairing: Color segments, Stack Marks layers. On Tableau questions asking for stacked charts, both must be configured correctly — one without the other won't satisfy the requirements.

Question 6

A data source contains daily orders from January 2024 through December 2025. An analyst wants one chronological line with a mark for each calendar month across the entire two-year period.

Which field placement most directly creates the requested view?

  1. Place discrete MONTH(Order Date) on Columns, SUM(Sales) on Rows, and select Line on the Marks card.
  2. Place continuous MONTH(Order Date) on Columns, SUM(Sales) on Rows, and select Line on the Marks card. (correct answer)
  3. Place discrete YEAR(Order Date) and discrete MONTH(Order Date) on Columns, then place SUM(Sales) on Rows.
  4. Place continuous DAY(Order Date) on Columns, SUM(Sales) on Rows, and increase the line size on the Marks card.
Explanation: When building time-series line charts in Tableau, the most important distinction to understand is discrete vs. continuous date parts, and how each affects the structure of your view. A continuous date field plots values along an unbroken numeric axis, allowing Tableau to respect the full chronological sequence across years. When you place a continuous MONTH(Order Date) on Columns, Tableau treats each month as a unique point in time — January 2024, February 2024, ..., December 2025 — producing exactly 24 ordered marks connected by a single line. That's precisely what the analyst needs, making B the correct answer. Here's why the other options fall short. A uses a discrete MONTH, which strips away the year context entirely and collapses all data into just 12 buckets (Jan through Dec). You'd end up with aggregated values across both years, not a 24-point chronological line. C partially fixes that problem by adding a discrete YEAR pill before the discrete MONTH pill, which does separate 2024 from 2025 — but discrete fields create headers and segments, so you get two disconnected line segments (one per year) rather than one continuous 24-month line. D uses a continuous DAY field, which would produce hundreds of individual daily marks rather than one mark per calendar month, and increasing line size does nothing to solve the aggregation mismatch. As a study tip, remember this pattern: discrete date parts = headers and grouped buckets; continuous date parts = a flowing axis that respects chronological order across years. Whenever a question asks for one unbroken timeline spanning multiple years, reach for a continuous date field.

Question 7

An analyst has three complete years of order data. The goal is to compare seasonal patterns by overlaying three lines on the same January-through-December axis, with one line for each year.

Which configuration best creates this comparison?

  1. Place continuous MONTH(Order Date) on Columns, SUM(Sales) on Rows, and discrete YEAR(Order Date) on Color.
  2. Place discrete MONTH(Order Date) on Columns, discrete YEAR(Order Date) on Rows, and SUM(Sales) on the Line mark.
  3. Place discrete MONTH(Order Date) on Columns, SUM(Sales) on Rows, and discrete YEAR(Order Date) on Color. (correct answer)
  4. Place continuous YEAR(Order Date) on Columns, SUM(Sales) on Rows, and discrete MONTH(Order Date) on Color.
Explanation: When building a seasonal comparison chart in Tableau, you need to think about two things: what structures the X-axis (the shared "template" all years follow) and what separates the years into distinct lines. The goal here is a January–December axis repeated across three overlapping lines — one per year. For that to work, months must be discrete on Columns. Discrete date parts in Tableau create fixed, labeled headers (Jan, Feb, Mar…) rather than a continuous timeline. This gives you the shared 12-month axis every year maps onto. Then, placing discrete YEAR(Order Date) on Color tells Tableau to draw a separate line for each year, overlaid on that same axis. That's exactly what answer C describes — and it's the correct configuration. Answer A fails because it uses continuous MONTH on Columns. Continuous months produce a flowing timeline that stretches across all three years sequentially rather than folding them onto a shared Jan–Dec axis. You'd get one long line, not three overlapping ones. Answer B puts YEAR on Rows instead of Color, which creates separate panels (one row per year) rather than overlaying the lines. This makes comparison harder because the lines aren't on the same axis simultaneously. Answer D reverses the logic entirely — continuous YEAR on Columns produces a year-over-year timeline, and putting MONTH on Color creates 12 colored lines across years. This shows monthly trends over time, not seasonal patterns aligned by month. A useful rule of thumb: whenever a question asks you to overlay multiple series on one shared axis, the grouping field (Year here) goes on Color, and the axis field must be discrete to create fixed, repeatable headers.

Question 8

Several subcategories have positive profit and several have negative profit. The analyst wants a horizontal bar chart in which profitable subcategories extend right from zero and unprofitable subcategories extend left from zero, preserving the original profit values.

Which configuration creates the requested diverging result with the fewest changes?

  1. Place Subcategory on Rows and SUM(Profit) on Columns, use Bar marks, and retain the zero baseline. (correct answer)
  2. Place Subcategory on Columns and SUM(Profit) on Rows, use Bar marks, and retain the zero baseline.
  3. Place Subcategory on Rows and ABS(SUM(Profit)) on Columns, then assign profit direction using Color.
  4. Place Subcategory on Rows and SUM(Profit) on Columns, then filter out values below the zero baseline.
Explanation: When building a diverging bar chart in Tableau, the key insight is that Tableau automatically handles negative values — bars for negative numbers extend left of zero, and bars for positive numbers extend right, as long as you preserve the raw signed values and orient the chart correctly. For a horizontal bar chart, you need the measure on the Columns shelf and the dimension on the Rows shelf. Placing SUM(Profit) on Columns and Subcategory on Rows with Bar marks gives you exactly what the analyst wants: profitable subcategories produce bars stretching right, unprofitable ones stretch left, all anchored at zero. No additional configuration is needed — this is option A, and it achieves the goal with the absolute minimum changes. Option B reverses the shelf placement (Subcategory on Columns, SUM(Profit) on Rows), which produces a vertical bar chart. The diverging behavior would still work, but the chart would be vertical, not horizontal — failing the requirement. Option C replaces SUM(Profit) with ABS(SUM(Profit)), which strips the negative sign entirely. Every bar would extend right, and you'd lose the true diverging structure. Using Color to indicate direction is a workaround that doesn't actually satisfy "preserving the original profit values" in the visual encoding. Option D filters out values below zero, which would remove unprofitable subcategories from the view altogether — the opposite of what was requested. The study tip here: in Tableau, "horizontal vs. vertical" is determined by which shelf holds the measure. Measure on Columns = horizontal bars. Memorize this axis-orientation rule, as it appears frequently in scenario-based exam questions.

Question 9

An order-line data source can contain several rows for the same Order ID and Category. An analyst needs a bar chart showing the number of distinct orders associated with each Category, not the number of line items.

Which measure and field placement should the analyst use?

  1. Place Category on Rows and SUM(Sales) on Columns, then display the resulting marks as horizontal bars.
  2. Place Category on Rows and COUNT(Order ID) on Columns, then display the resulting marks as horizontal bars.
  3. Place Category on Rows and COUNTD(Order ID) on Columns, then display the resulting marks as horizontal bars. (correct answer)
  4. Place Category on Rows and the generated row-count measure on Columns, then display horizontal bars.
Explanation: When working with transactional data sources like order lines, a single real-world order often spawns multiple rows — one per product or category. This means a simple count inflates the result by counting rows rather than unique orders. That distinction is exactly what this question tests. The right tool here is COUNTD, which stands for Count Distinct. Placing Category on Rows and COUNTD(Order ID) on Columns gives you the number of unique Order IDs within each category, regardless of how many line items belong to those orders. That's answer C, and it directly solves the analyst's problem. A is wrong because SUM(Sales) aggregates revenue, not order counts — it answers "how much was sold?" rather than "how many orders existed?" B uses COUNT(Order ID), which counts every row containing an Order ID, including duplicates. If Order #1001 has three line items in the Furniture category, COUNT returns 3 while COUNTD correctly returns 1. D refers to the auto-generated Number of Records measure Tableau creates, which also counts rows — not distinct orders — and has the same duplication problem as COUNT. A quick memory aid: whenever you see the word "distinct" in a question — distinct customers, distinct orders, distinct products — your immediate instinct should be COUNTD. COUNT and Number of Records are row-level measures, perfect for counting line items, but they overcount whenever your data has a one-to-many relationship between the real entity and the rows in your table.

Question 10

A worksheet must display monthly SUM(Sales) and SUM(Profit) as two differently colored lines in the same pane and on a shared axis. The analyst does not want separate row panes.

Which field arrangement most directly builds this view?

  1. Place MONTH(Order Date) on Columns, then place SUM(Sales) and SUM(Profit) as separate pills on Rows.
  2. Place MONTH(Order Date) on Columns, SUM(Sales) on Rows, and continuous SUM(Profit) on Color.
  3. Place Measure Names on Rows, Measure Values on Columns, and MONTH(Order Date) on Detail with Line marks.
  4. Place MONTH(Order Date) on Columns and Measure Values on Rows, filter Measure Names to Sales and Profit only, and place Measure Names on Color. (correct answer)
Explanation: Whenever Tableau asks you to plot multiple measures as lines in a single pane on a shared axis, the key mechanism is the Measure Names / Measure Values field pair. These two auto-generated fields let you blend multiple numeric measures onto one axis, avoiding the split-pane problem that arises when you drop measures independently onto Rows. Option D is the correct build: placing MONTH(Order Date) on Columns gives you the time spine, Measure Values on Rows creates that single shared axis, filtering Measure Names to just Sales and Profit narrows the data to the two series you want, and dragging Measure Names to Color encodes each measure as a distinct line color — exactly what the question describes. Everything lives in one pane, on one axis. Option A fails the core requirement: dropping SUM(Sales) and SUM(Profit) as separate pills on Rows creates two independent row panes, one per measure, with separate axes — the analyst explicitly does not want this. Option B places continuous SUM(Profit) on Color, but Color encodes magnitude (a gradient), not categorical identity. You'd get a single colored line for Sales with Profit driving the color shade, not two distinct lines — this misunderstands how continuous fields behave on Color. Option C has the axis concept backwards: Measure Names on Rows and Measure Values on Columns would put the measures along the horizontal axis and categories vertically, producing a column-style or transposed view rather than a time-series line chart with months on the x-axis. Study tip: Anytime a Tableau question mentions "same pane" or "shared axis" with multiple measures, your default reach should be Measure Values on Rows + Measure Names on Color.