- Which calculation implements management's definition at the summary-view level?
Answer: SUM([Sales])/SUM([Target]), formatted as a percentage in the KPI worksheet
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]) 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]), 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]), 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]) 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), never to row-level division. - Which change most directly produces the required result?
Answer: Convert the Region filter to a context filter so it is applied before the fixed maximum-date calculation.
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]) } 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. - Which calculation design is most appropriate for a robust textual KPI status?
Answer: Test for a missing prior value first, then test whether [PriorSales]=0, and calculate percentage change only otherwise.
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 [Prior Sales][Current Sales]−[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. - Which approach provides the two formats without changing the underlying KPI value?
Answer: Create separate Revenue Label and Revenue Exact calculations, format them independently, and place them on Label and Tooltip.
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.
- How should the dashboard action be configured?
Answer: Create a filter action that runs on Select and set clearing the selection to Show all values.
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.
- What is the most direct way to create the intended single-mark summary tile?
Answer: Remove Category from Detail and retain only SUM([Sales]) on the Text or Label shelf.
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]) 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]) 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 FIXED 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. - Which Marks card configuration best satisfies these requirements?
Answer: Use a Square mark, place SUM([Sales]) on Label, and place an aggregated target-status calculation on Color.
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]) on Label gives you the large numeric display the spec calls for. The aggregated target-status calculation — something like 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]) 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. - Which statement describes the appropriate workflow and resulting behavior?
Answer: 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.
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.
- What should the author verify or change first?
Answer: On the Region filter menu, apply the filter to all worksheets using the same data source.
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.
- Which design should be used so the KPI displays only the latest month while retaining the prior month for the comparison?
Answer: Keep both months in the partition, compute the change, and use a table-calculation filter such as LAST()=0.
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()=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) 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.
