Tableau Quiz: Kpi Tiles
10 questions · exam conditions
0:00
Kpi TilesQuestion 1 of 10

A KPI tile must show total sales as a large label. Its background should be green when total sales meet or exceed total target and red otherwise. The tile must remain one mark so it can be placed cleanly in a dashboard container.

Which Marks card configuration best satisfies these requirements?

Use a Square mark, place SUM([Sales])SUM([Sales]) on Label, and place an aggregated target-status calculation on Color.
Use a Text mark, place Target on Detail, and place the row-level comparison between Sales and Target on Color.
Use a Square mark, place the target-status calculation on Filters, and place both Sales and Target on Detail.
Use a Shape mark, place SUM([Target])SUM([Target]) on Label, and place the unaggregated Sales field on Color.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Kpi Tiles

Practice Kpi Tiles 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 Kpi Tiles, 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 KPI tile must show total sales as a large label. Its background should be green when total sales meet or exceed total target and red otherwise. The tile must remain one mark so it can be placed cleanly in a dashboard container.

Which Marks card configuration best satisfies these requirements?

  1. Use a Square mark, place SUM([Sales])SUM([Sales]) on Label, and place an aggregated target-status calculation on Color. (correct answer)
  2. Use a Text mark, place Target on Detail, and place the row-level comparison between Sales and Target on Color.
  3. Use a Square mark, place the target-status calculation on Filters, and place both Sales and Target on Detail.
  4. Use a Shape mark, place SUM([Target])SUM([Target]) on Label, and place the unaggregated Sales field on Color.
Explanation: When designing a KPI tile in Tableau, you need to think about three things simultaneously: what displays visually (mark type), what drives the color encoding, and whether your aggregations are consistent. A single-mark tile means your view should produce exactly one row of data, which requires fully aggregated fields everywhere. Answer A satisfies every requirement cleanly. A Square mark produces a solid, colored tile — perfect for a KPI background. Placing SUM([Sales])SUM([Sales]) on Label gives you the large numeric display the spec calls for. The aggregated target-status calculation — something like SUM([Sales])>=SUM([Target])SUM([Sales]) >= SUM([Target]) — drives Color, turning the tile green or red based on the comparison of totals. Because every field is aggregated, Tableau produces one mark, exactly as required. Answer B fails in two ways: a Text mark won't fill the tile with a solid background color the way a Square does, and placing a row-level (unaggregated) comparison on Color creates a disaggregated view, breaking the single-mark requirement and causing Tableau to mix or blend colors unpredictably. Answer C misuses Filters for the target-status logic. Filters remove data from the view — they don't encode color — so the tile would have no conditional background at all. Placing both fields on Detail also disaggregates the view, multiplying marks. Answer D places SUM([Target])SUM([Target]) on Label instead of Sales, showing the wrong number, and uses an unaggregated Sales field on Color, which disaggregates the view and breaks the single-mark rule. The study tip here: on any KPI or single-mark question, check that every field on the Marks card is aggregated. One unaggregated field anywhere will multiply your marks and ruin the layout.

Question 2

A dashboard contains a segment summary view and a KPI tile. Selecting a segment should restrict the KPI to that segment. When the user clears the selection, the KPI should return to the total for all segments rather than remain filtered or become blank.

How should the dashboard action be configured?

  1. Create a highlight action that runs on Select and set clearing the selection to Exclude all values.
  2. Create a filter action that runs on Select and set clearing the selection to Show all values. (correct answer)
  3. Create a URL action that runs on Menu and set the target field to the Segment dimension.
  4. Create a parameter action that runs on Hover and set clearing the selection to Keep current value.
Explanation: When a dashboard needs to filter one view based on a selection in another, you're working with dashboard actions — and the key is matching the action type and clearing behavior to the exact user experience described. The scenario requires two things: selections filter the KPI, and clearing the selection restores the full total. This points directly to a filter action set to Show all values when the selection is cleared. Filter actions pass the selected dimension members as a filter to target sheets. When "Show all values" is the clearing behavior, removing the selection lifts the filter entirely, returning the KPI to its unfiltered, all-segments total. That's answer B, and it maps precisely to what the passage describes. A is wrong because highlight actions don't filter data — they dim non-selected marks while keeping all values visible. The KPI tile would still show the total for all segments regardless of the selection, which doesn't meet the requirement of restricting the KPI. C is wrong on two counts: URL actions navigate to external web pages, not between sheets, and running on Menu requires the user to right-click rather than simply selecting a mark — neither fits the described behavior. D is wrong because parameter actions update a parameter value, not a direct filter, requiring additional calculated fields to wire up the filtering logic. Additionally, "Keep current value" on clearing means the KPI would stay filtered to the last selection rather than resetting — the opposite of what's needed. A reliable study tip: on action questions, always check two things — the action type (filter, highlight, URL, parameter) and the clearing behavior. The passage usually signals both requirements explicitly.

Question 3

A monthly sales KPI must display the percentage change for the latest completed month compared with the immediately preceding month. The worksheet uses a Percent Difference table calculation. When a standard Month filter keeps only the latest month, the KPI displays null because the preceding mark is no longer available.

Which design should be used so the KPI displays only the latest month while retaining the prior month for the comparison?

  1. Filter to the latest month first, and replace the table calculation with SUM([Sales])−LOOKUP(SUM([Sales]),−1)SUM([Sales]) - LOOKUP(SUM([Sales]), -1).
  2. Keep both months, convert the Month field to a discrete dimension, and hide the prior month by deselecting its header.
  3. Keep both months in the partition, compute the change, and use a table-calculation filter such as LAST()=0LAST() = 0. (correct answer)
  4. Filter to the latest month, duplicate the Sales measure, and calculate the difference between the two measure instances.
Explanation: Whenever you see a question about table calculations and filters in Tableau, the critical concept to internalize is this: standard dimension filters remove marks from the view entirely, which breaks any table calculation that depends on neighboring marks. A Percent Difference calculation needs the prior month's value to exist in the partition — if it's filtered out, the result is null. The correct approach, C, solves this elegantly. By keeping both months in the view and applying a table-calculation filter instead of a dimension filter, the prior month remains available for the computation. The expression LAST()=0LAST() = 0 evaluates to true only for the last mark in the partition, so only the latest month is displayed — but the prior month still participates in the underlying calculation. Table-calculation filters execute after table calculations, meaning they hide marks without destroying the data the calculations rely on. A fails because filtering to the latest month first removes the prior mark before any calculation runs. Even replacing the calc with LOOKUP(SUM([Sales]),−1)LOOKUP(SUM([Sales]), -1) cannot retrieve a mark that no longer exists in the partition. B is a common misconception — hiding a header by deselecting it in Tableau doesn't remove the mark from the view's data; it only hides the label. However, this approach is unreliable and non-dynamic: it won't automatically track "the latest month" as new data arrives, making it impractical for a live KPI. D duplicating the Sales measure still operates on a single-month filtered view, so the duplicate has no access to prior-month data either. The key study takeaway: always distinguish between dimension filters (which remove marks, breaking table calcs) and table-calculation filters (which hide marks after calcs run, preserving them). When a table calc needs context outside the displayed range, reach for a table-calc filter.

Question 4

A dashboard has a Region filter, a detail view, and four KPI worksheets. The detail view responds to Region, but two KPI tiles continue showing company-wide totals. All worksheets use the same Tableau data source, and the intended behavior is for every tile to reflect the selected region.

What should the author verify or change first?

  1. Add each KPI worksheet to a horizontal container that also contains the Region filter card.
  2. Add Region to Detail on every KPI worksheet so Tableau creates one mark for each region.
  3. Replace the Region filter with a highlight action targeting all worksheets on the dashboard.
  4. On the Region filter menu, apply the filter to all worksheets using the same data source. (correct answer)
Explanation: When a Tableau dashboard filter isn't affecting every worksheet, the first thing to investigate is the filter's scope — specifically, which worksheets it has been configured to control. By default, a filter only applies to the sheet it was created on. To extend it across multiple sheets sharing the same data source, you right-click the filter card on the dashboard, choose "Apply to Worksheets," and select "All Using This Data Source." That single setting is what makes D the correct first action here. Since all worksheets already share the same data source, this is a simple configuration fix that requires no structural changes to the workbook. Choice A misunderstands how filter scope works. Placing worksheets and the filter card inside the same container is a layout decision — it affects visual organization, not filter logic. Containers don't extend filter reach. Choice B confuses filtering with level of detail. Adding Region to the Detail shelf controls how marks are drawn (one mark per region value), but it doesn't make the sheet respond to a dashboard filter. These are separate concepts — granularity versus filter scope. Choice C replaces a filter with a highlight action, which is a fundamentally different interaction. Highlight actions emphasize matching marks without removing others from view, so company-wide totals would still display. This doesn't achieve the intended behavior and introduces unnecessary complexity before trying the obvious fix. A useful pattern to remember: whenever a dashboard filter seems "broken" for some sheets but not others, always check filter scope before rebuilding anything. It's the most common culprit and the quickest fix.

Question 5

A Tableau story contains three points based on the same executive dashboard. Each point must preserve a different Region filter state and corresponding KPI values. After creating the points, the author changes a worksheet calculation used by the KPI.

Which statement describes the appropriate workflow and resulting behavior?

  1. Duplicate the data source for each point because story points cannot retain different filter states for a single dashboard without separate sources.
  2. Set the Region filter for each point and update that point; later worksheet-calculation changes are reflected in every story point because story points reference live worksheets. (correct answer)
  3. Set Region with a dashboard action only; worksheet-calculation changes remain frozen in previously saved story points and do not update automatically.
  4. Create one story point and change its caption for each region because captions automatically store and restore independent KPI filter states.
Explanation: When working with Tableau stories, the key concept to understand is how story points relate to the underlying worksheets and dashboards they reference. Story points are not static snapshots frozen at creation — they are live references that capture filter and parameter states independently per point, while still pulling from the live worksheet logic beneath them. This is exactly what makes B correct. You configure each story point by setting the Region filter to the desired value and clicking "Update," which saves that filter state for that point. Because story points reference live worksheets, any change to a worksheet calculation — such as updating a KPI formula — propagates automatically across all story points the next time they render. You get independent filter states and always-current calculations simultaneously. A is wrong because duplicating data sources is completely unnecessary. Story points natively support different filter states on the same dashboard without any source separation — that's a core feature of the story functionality, not a limitation. C is incorrect because it conflates dashboard actions with filter state storage, then incorrectly claims calculation changes are "frozen." Dashboard actions can set filters, but the freeze behavior described simply doesn't exist — worksheet calculation changes always flow through to story points dynamically. D is a trap that sounds plausible if you misunderstand what captions do. Captions are purely descriptive text labels for a story point. They have no mechanism to store or restore filter states — that job belongs to the "Update" workflow described in B. Study tip: Remember the mantra — story points save state, not snapshots. Filter states are locked per point; worksheet logic is always live.

Question 6

An executive KPI must display revenue compactly as 1.3M, but its tooltip must show the same filtered value with full precision as 1,274,892. Applying one number format to the existing Revenue field causes both presentations to use the same display style.

Which approach provides the two formats without changing the underlying KPI value?

  1. Create separate Revenue Label and Revenue Exact calculations, format them independently, and place them on Label and Tooltip. (correct answer)
  2. Place Revenue on Label twice, use display units on one copy, and rely on the tooltip to ignore worksheet formatting.
  3. Convert Revenue to a dimension for the tooltip and leave the aggregated measure on Label with million units.
  4. Round Revenue to the nearest million for Label and use the rounded calculation again in the detailed tooltip.
Explanation: Whenever you see a question about displaying the same measure in two different formats simultaneously, think about calculated fields as a way to create independent copies of a value that can each be formatted separately — this is a core Tableau flexibility pattern. The cleanest solution here is A: create two separate calculated fields — say, Revenue Label and Revenue Exact — both referencing the same underlying filtered revenue measure. Because they are distinct fields, you can apply different default number formats to each independently (e.g., abbreviated millions for one, full comma-separated integers for the other). Dragging Revenue Label onto the Label shelf and Revenue Exact onto the Tooltip shelf gives you exactly the two display styles the KPI requires, with no impact on the underlying data or aggregation. Option B is flawed because Tableau does not have a mechanism that makes tooltip automatically "ignore" worksheet formatting on a pill — both instances of the same field on a shelf would share the same formatting behavior, so you cannot achieve two independent styles this way. Option C misunderstands how dimensions and measures work. Converting a measure to a dimension does not grant it a different number format context; it changes how Tableau aggregates and partitions the data, which would distort the KPI value itself. Option D defeats the purpose of a "full precision" tooltip. Rounding revenue to the nearest million and reusing that rounded calculation in the tooltip means both the label and tooltip display approximate values — you lose the exact 1,274,892 figure the requirement demands. As a study tip: whenever a question asks for two different visual formats of the same value, your first instinct should be duplicate via calculated fields and format independently — not try to force one field into two behaviors.

Question 7

A snapshot KPI uses [SnapshotDate]=FIXED:MAX([SnapshotDate])[Snapshot Date] = { FIXED : MAX([Snapshot Date]) } to retain records from the latest snapshot. Users can filter the dashboard by Region. Some regions do not have records on the data source's global latest date, so selecting one of those regions makes the KPI blank. The KPI should instead use the latest date available within the selected region or regions.

Which change most directly produces the required result?

  1. Convert the Region filter to a context filter so it is applied before the fixed maximum-date calculation. (correct answer)
  2. Convert the Snapshot Date filter to a context filter while leaving Region as a standard dimension filter.
  3. Replace the fixed expression with MAX([SnapshotDate])MAX([Snapshot Date]) and place Snapshot Date on the Label shelf.
  4. Make Region a data source filter and retain a separate standard Region filter for dashboard interaction.
Explanation: When you see a question involving FIXED LOD expressions and dashboard filters, the key concept to understand is Tableau's order of operations: context filters apply before LOD calculations, while standard dimension filters apply after. This ordering determines what data the FIXED expression "sees" when it computes. The core problem here is that { FIXED : MAX([Snapshot Date]) }\text{\{ FIXED : MAX([Snapshot Date]) \}} calculates the maximum snapshot date across the entire data source, ignoring any Region filter the user applies. When a user selects a region whose latest data predates the global maximum, the KPI returns blank because no records match that global date within that region. The fix is to make the Region filter a context filter. This forces Tableau to first restrict the data to the selected region(s), and then evaluate the FIXED expression — so MAX([Snapshot Date]) now reflects the latest date available within that filtered context. Answer A is correct. Answer B is backwards. Making the Snapshot Date filter a context filter doesn't help, because the Region filter — still a standard filter — still applies after the LOD, leaving the same scoping problem intact. Answer C replaces the LOD with a plain MAX([Snapshot Date]), which is an aggregate that depends on what's in the view. This would change display behavior unpredictably and doesn't reliably retain only the latest-date records across all marks. Answer D using a data source filter for Region would permanently restrict the data, meaning users couldn't interactively switch regions — it defeats the dashboard's purpose entirely. The key study tip: whenever a FIXED LOD produces unexpected results with a user-facing filter, ask yourself whether that filter needs to become a context filter to constrain the LOD's scope.

Question 8

A revenue KPI compares actual sales with target. The data contains several target rows at different levels, and management defines attainment as total actual sales divided by total target. A developer instead averages the row-level values of [Sales]/[Target][Sales] / [Target], causing small-target rows to influence the KPI disproportionately.

Which calculation implements management's definition at the summary-view level?

  1. AVG([Sales]/[Target])AVG([Sales] / [Target]), formatted as a percentage after all dashboard filters are applied
  2. SUM([Sales]/[Target])SUM([Sales] / [Target]), formatted as a percentage after all dashboard filters are applied
  3. SUM([Sales])/SUM([Target])SUM([Sales]) / SUM([Target]), formatted as a percentage in the KPI worksheet (correct answer)
  4. AVG([Sales])/AVG([Target])AVG([Sales]) / AVG([Target]), computed separately for every target-record grouping
Explanation: Whenever you see a KPI question involving ratios, ask yourself: should aggregation happen before or after the division? Management's definition — total actual divided by total target — means you must sum each measure independently first, then divide. This is the classic "ratio of sums" versus "sum of ratios" distinction, and confusing the two is one of the most common modeling errors in Tableau. SUM([Sales])/SUM([Target])SUM([Sales]) / SUM([Target]) in answer C does exactly what management wants. It collapses all sales into one number and all targets into one number, then computes a single attainment percentage. A row with a tiny target carries weight proportional to its actual contribution — no more, no less. Answer A uses AVG([Sales]/[Target])AVG([Sales] / [Target]), which is precisely the developer's mistake described in the passage. Dividing row by row first lets small-target rows punch above their weight, because a row with $10 actual vs. $5 target contributes the same 200% as a row with $1M actual vs. $500K target. Answer B applies SUM([Sales]/[Target])SUM([Sales] / [Target]), which still divides at the row level before aggregating. Summing those row-level ratios produces a dimensionless number with no coherent business meaning — it is neither a percentage nor a valid attainment metric. Answer D computes AVG([Sales])/AVG([Target])AVG([Sales]) / AVG([Target]) per grouping. Averaging both measures separately before dividing can produce the correct result only when group sizes are equal, which is rarely guaranteed and not what management specified. As a study habit, always translate business language into aggregation order: "total X divided by total Y" maps directly to SUM(X)/SUM(Y)SUM(X) / SUM(Y), never to row-level division.

Question 9

A KPI displays current sales and a comparison status derived from prior-period sales. The existing percentage-change expression divides the difference by prior sales. It returns null or misleading output when the prior period is missing or when prior sales equal zero.

Which calculation design is most appropriate for a robust textual KPI status?

  1. Exclude all records with zero prior sales and allow missing prior periods to inherit the current-period value.
  2. Replace every missing or zero prior value with one, then calculate the standard percentage-change expression.
  3. Calculate the percentage change first, then use number formatting to convert every null result into zero percent.
  4. Test for a missing prior value first, then test whether [PriorSales]=0[Prior Sales] = 0, and calculate percentage change only otherwise. (correct answer)
Explanation: When building KPI calculations in Tableau, the core challenge is defensive programming: your formula must anticipate bad data before attempting arithmetic. Division-by-zero and null inputs are the two most common failure modes, and you must handle them in the right sequence. The strongest approach is D. You first check whether [Prior Sales] is null using ISNULL(), then — only if it exists — check whether it equals zero. If both tests pass, you calculate [Current Sales]−[Prior Sales][Prior Sales]\frac{[\text{Current Sales}] - [\text{Prior Sales}]}{[\text{Prior Sales}]} and display a meaningful status; otherwise, you return a clearly labeled fallback string like "N/A" or "No Prior Data." This two-gate structure prevents both null propagation and division-by-zero, giving users honest, readable output. Answer A is flawed because excluding zero-prior records silently drops data, and letting missing periods "inherit" current values fabricates a comparison that doesn't exist — this misleads rather than protects. Answer B replaces missing or zero values with one, which manufactures a denominator out of thin air. A percentage change calculated against a prior value of $1 is mathematically valid but analytically meaningless, and it disguises data gaps as real performance signals. Answer C applies number formatting after the fact, converting null results to zero percent. This is cosmetic, not computational — it makes a null look like zero change, which is factually wrong and can cause serious misinterpretation of KPI trends. Study tip: Whenever a Tableau calculation involves division, write your logic as a nested IF that gates on ISNULL() first, then checks the denominator for zero — always in that order.

Question 10

A KPI worksheet should display one company-wide sales total. It currently contains Category on Detail and SUM([Sales])SUM([Sales]) on Text. On the dashboard, the tile behaves as several overlapping marks and exposes category-level marks when users hover.

What is the most direct way to create the intended single-mark summary tile?

  1. Remove Category from Detail and retain only SUM([Sales])SUM([Sales]) on the Text or Label shelf. (correct answer)
  2. Convert Category to a continuous field and retain it on Detail with the sales measure.
  3. Replace Category with ATTR([Category])ATTR([Category]) on Detail and retain the existing sales aggregation.
  4. Create a fixed total for sales but retain Category on Detail to preserve the worksheet granularity.
Explanation: Whenever you see a question about mark granularity in Tableau, ask yourself: what dimension is controlling the level of detail? Every dimension on the Marks card — including Detail — creates a separate mark per member. That's the root of this problem. Here, Category sitting on Detail tells Tableau to draw one mark per category, giving you three overlapping marks instead of one. The fix is simply to remove Category from Detail entirely, leaving only SUM([Sales])SUM([Sales]) on Text. With no dimension breaking the view, Tableau aggregates all sales into a single mark — exactly the summary tile you want. That's why A is correct and the most direct path. B is wrong because converting Category to continuous changes its visual encoding but doesn't remove it from Detail. It still partitions marks by category; you've just changed the color or axis treatment, not the granularity. C is a tempting trap. ATTR([Category])ATTR([Category]) returns the single value if all rows share the same category, or * if they don't — but it doesn't collapse the marks. The field is still on Detail, so Tableau still draws multiple marks, one per category member. D directly contradicts the goal. A fixed total (like a FIXEDFIXED LOD expression) can produce the right number, but keeping Category on Detail preserves category-level granularity, so you still get multiple overlapping marks. Study tip: Treat the Marks card like a granularity checklist — every dimension present creates separate marks. When a viz shows unwanted detail, scan the Marks card for dimensions you can remove before reaching for calculated fields or workarounds.