- Which sequence most directly creates the required worksheet?
Answer: Filter Product Name to Top 10 by SUM(Sales), place Product Name on Rows and SUM(Sales) on Columns, then sort descending.
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.
- Which configuration best produces the requested bar chart?
Answer: Place Region followed by Category on Columns, place SUM(Sales) on Rows, and use the Bar mark type.
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.
- Which approach meets both requirements?
Answer: Place continuous MONTH(Date) on Columns, SUM(Expense) on Rows, Department on Color, and turn Stack Marks on.
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.
- Which change produces the requested result?
Answer: Apply a Running Total table calculation to SUM(Sales), compute it along Month, and retain the Area mark type.
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.
- What should the analyst do next?
Answer: Place Customer Name on Detail while leaving Aggregate Measures enabled for the two measures.
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.
- Which measure and field placement should the analyst use?
Answer: Place Category on Rows and COUNTD(Order ID) on Columns, then display the resulting marks as horizontal bars.
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.
- Which configuration creates the requested diverging result with the fewest changes?
Answer: Place Subcategory on Rows and SUM(Profit) on Columns, use Bar marks, and retain the zero baseline.
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.
- Which configuration best creates this comparison?
Answer: Place discrete MONTH(Order Date) on Columns, SUM(Sales) on Rows, and discrete YEAR(Order Date) on Color.
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.
- Which field placement most directly creates the requested view?
Answer: Place continuous MONTH(Order Date) on Columns, SUM(Sales) on Rows, and select Line on the Marks card.
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.
- Which field arrangement most directly builds this view?
Answer: 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.
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.
