- Which approach most appropriately uses a parameter to control the date granularity?
Answer: Create a string parameter and use a CASE calculation that returns DATETRUNC of Order Date for each selected grain.
When you need users to dynamically switch date granularity while keeping the axis as a true date axis (so years stay distinct), the key tool is DATETRUNC. Unlike DATEPART, which extracts a numeric component (e.g., week 3, month 7), DATETRUNC truncates a date to a given level while preserving the full date context — so January 2023 and January 2024 remain separate points on the axis.
Option C is the right approach because a string parameter (with list values like "Week," "Month," "Quarter") drives a CASE statement that returns DATETRUNC('week', [Order Date]), DATETRUNC('month', [Order Date]), and so on. The result is a calculated field that is still a date, which means Tableau renders it correctly on a continuous or discrete date axis with year-level separation intact. This satisfies every requirement in the passage.
Option A fails because DATEPART returns an integer, not a date. Week 10 of 2022 and week 10 of 2023 collapse into the same value (10), destroying year distinctness — exactly what the question forbids. Option B is a workflow workaround, not a parameter-driven solution; toggling visibility of pills using a filter parameter is fragile and doesn't elegantly control granularity through a single calculated field. Option D sounds plausible but is a trap: Tableau parameters cannot be assigned directly as the date level of a pill — there is no native mechanism to inject a parameter value into the date hierarchy selector on a pill.
Study tip: On Tableau exam questions about dynamic date granularity, always distinguish DATETRUNC (returns a date, preserves year context) from DATEPART (returns a number, loses year context). That distinction alone eliminates many distractors.
- What change is required while continuing to use the parameter-controlled Top filter?
Answer: Add the Region filter to context so it is evaluated before the parameter-controlled Top customer filter.
Whenever you see a Tableau question about filter execution order — especially one where a filter seems to be "ignoring" another filter — you should immediately think about context filters. Tableau evaluates filters in a fixed sequence: extract filters → data source filters → context filters → dimension filters → measure filters. A standard dimension filter (like Region) sits in the same tier as a Top N filter, but the Top N filter runs first by default, meaning Tableau ranks customers across all regions before restricting to the selected one.
The fix is answer B: adding the Region filter to context promotes it to an earlier evaluation stage. Once Region becomes a context filter, Tableau first narrows the data to only the chosen region, then applies the parameter-controlled Top N filter — giving users the top customers within that region, exactly as expected. No changes to the parameter or the Top filter itself are needed.
Answer A is a red herring. Converting the parameter to a string and manually comparing labels would be an overly complex workaround that doesn't address the underlying filter-order problem. Answer C is a UI/display change only — rearranging parameter controls on a worksheet has no effect on how Tableau internally sequences filter evaluation. Answer D reflects a misconception: parameters aren't filters at all; they're user-input values. Converting Region to a parameter would actually remove it from the filter pipeline entirely, breaking the intended filtering behavior.
A useful rule of thumb: when a filter needs to "run before" another filter in Tableau, the answer is almost always Add to Context. Watch for questions where the symptom is a filter being "ignored" or producing unexpected scope — that's your signal.
- Which clearing-selection behavior should be configured for the parameter action?
Answer: Keep the current parameter value so clearing a selection leaves the most recently selected customer in place.
When configuring a parameter action in Tableau, the "clearing behavior" controls what happens to the parameter's value when a user clicks away from a mark or deselects entirely. The key question to ask yourself is: what should the dashboard show when nothing is selected? The passage explicitly states the dashboard should continue showing details for the most recently selected customer — meaning the parameter should hold its last value, not change at all.
That makes B the correct choice. "Keep the current parameter value" is exactly the clearing behavior designed for this use case: once a user selects a customer, that selection persists in the parameter even after they click away, preserving the last meaningful state without any additional logic required.
A is wrong because reverting to the default value would likely reset the view to a generic or empty state — the opposite of what the passage requires. Default values represent the workbook's saved baseline, not the user's most recent interaction.
C is tempting if you're thinking about building null-detection logic downstream, but introducing a blank string creates unnecessary complexity. You'd need every downstream calculation to handle the empty case, and the passage gives no indication that detecting "no selection" is a goal — only that the last selection should persist.
D is wrong because falling back to the first customer in the list is an arbitrary reset. It's predictable, yes, but it discards the user's most recent context, which directly contradicts the requirement.
A useful pattern to remember: when a question asks about preserving user state after deselection, "keep the current value" is almost always the right clearing behavior — it's Tableau's way of making parameter actions feel persistent and intentional.
- Which calculated field is valid and produces the intended result?
Answer: CASE[Metric]WHEN′Revenue′THENSUM([Sales])WHEN′Profit′THENSUM([Profit])WHEN′Margin′THENSUM([Profit])/SUM([Sales])END
When building a parameter-driven calculated field in Tableau, the critical rule is aggregation consistency: every THEN branch must return the same level of detail — either all aggregates or all row-level values. Mixing the two causes a calculation error.
Answer A is correct because every branch returns a proper aggregate. Revenue uses SUM([Sales]), Profit uses SUM([Profit]), and Margin uses SUM([Profit])/SUM([Sales]) — which is the correct way to calculate an aggregated margin ratio. Tableau treats the entire expression as an aggregate, and all branches are consistent.
Answer B mixes aggregated and row-level values: the Revenue branch uses [Sales] (row-level) while Profit uses SUM([Profit]) (aggregate). This inconsistency causes a validation error, making the field unusable.
Answer C uses SUM([Profit]/[Sales]) for Margin, which computes the ratio row by row first and then sums those ratios — a fundamentally different (and typically wrong) calculation compared to dividing total profit by total sales. This produces incorrect margin values, even though it might not throw an error.
Answer D is also inconsistent: the Margin branch uses [Profit] at row-level in the numerator but SUM([Sales]) as the denominator. Mixing aggregate and non-aggregate values in a single expression is invalid in Tableau.
Study tip: Whenever you write a CASE statement with aggregations in Tableau, check every branch — all must be fully aggregated or fully row-level. For ratio metrics like Margin, always divide two separate SUM expressions: SUM(numerator)/SUM(denominator). - Which parameter configuration satisfies both requirements without manually editing the workbook after each data refresh?
Answer: Configure the parameter as dynamic, sourcing allowable values from Snapshot Date when the workbook opens, and set the current value to the maximum of that field.
When you see a question about parameters updating automatically based on data, you should immediately think about Tableau's dynamic parameters feature — the mechanism that allows a parameter's list of allowable values and its current value to refresh each time a workbook is opened or the data source is refreshed.
Dynamic parameters, introduced in Tableau 2021.1, solve exactly this problem: they bind a parameter's domain to a field in your data source, so the list stays current without manual workbook edits. When you configure a parameter to source its allowable values from [Snapshot Date] dynamically, Tableau rebuilds that list on each session. Setting the current value to the maximum of that field means the parameter automatically initializes to the most recent date available — satisfying both requirements in the question simultaneously. That's why D is correct.
A fails because a fixed list doesn't update when new snapshot dates appear in the data — you'd have to manually add new dates and republish every time. Setting the current value to "today" also doesn't guarantee today is even a valid snapshot date.
B is a subtler trap: sourcing from a field sounds dynamic, but if you save a fixed list from that field at publish time, new dates added after publication won't appear. It's a snapshot of a snapshot, not a live connection.
C shifts the burden entirely onto the user, which directly violates the requirement for automatic initial selection — it's not a configuration solution at all.
Study tip: On Tableau exam questions, any time requirements include both "auto-updating list" and "auto-selecting a value," dynamic parameters with a field-driven current value is almost always the answer.
- Which implementation correctly applies the parameter at the customer-total level?
Answer: Create SUM([Sales])>=[MinimumSales], place it on Filters, and retain only marks where the result is True.
Whenever you see a question about filtering based on aggregated values in Tableau, the key distinction is understanding row-level filters versus aggregate filters. Tableau evaluates filters at different levels of detail, so the formula you write must match the level at which you want the filter applied.
Since the view already aggregates sales per customer using SUM([Sales]), you need a filter that operates at that same aggregated level. Option C does exactly this: the calculated field SUM([Sales])>=[MinimumSales] compares the customer-level total against the parameter threshold. When placed on the Filters shelf and set to True, Tableau retains only those customer marks whose aggregate total meets the threshold — precisely the behavior the analyst wants.
Option A fails because you cannot place a parameter directly on the Filters shelf and define meaningful filter logic from it alone. A parameter is just a user-controlled input value; it has no inherent filtering behavior until compared inside a calculated field.
Option B uses a row-level expression [Sales]>=[MinimumSales], which compares individual transaction records to the threshold before aggregation occurs. This filters out individual rows of data, meaning a customer with many small sales could be excluded even if their total exceeds the threshold — producing incorrect results.
Option D uses a reference line, which is purely a visual annotation. Reference lines highlight values in the view but do not filter the underlying data or remove marks from the display.
Your study tip: whenever a question asks you to filter on an aggregated value in Tableau, look for a calculated field that wraps the measure in an aggregate function like SUM(). If the formula lacks that aggregation, it's operating at the wrong level. - How should the Reduction parameter be configured?
Answer: Use a numeric value of 0.10 and format the parameter's displayed value as a percentage.
When configuring a parameter that feeds directly into a calculation, you need to think carefully about the unit mismatch trap: what the user sees should not necessarily equal what the formula receives. These two concerns — display and computation — can be decoupled in Tableau through formatting.
The calculation SUM([Sales])∗(1−[Reduction]) requires [Reduction] to be a decimal proportion. When the user selects 10 percent, the formula needs 1−0.10=0.90, which correctly yields 90% of sales. That means the parameter's stored value must be 0.10, not 10. Tableau's parameter formatting options let you display 0.10 as "10%" to the user while the underlying value remains 0.10 — exactly what C describes.
A is wrong because storing an integer value of 10 would make the calculation 1−10=−9, producing a nonsensical negative multiplier. Formatting alone cannot fix a fundamentally wrong stored value. B is wrong because Tableau parameters do not implicitly convert strings to numbers during arithmetic; using a string type would cause the multiplication to fail entirely. D is wrong for the same reason as A — storing 10.00 as the parameter value still breaks the formula, and formatting it as a decimal with two places doesn't resolve the unit problem.
The key study tip: on parameter questions, always trace the stored value through the formula first, then decide how to format the display. If the math requires a proportion, store a proportion — use formatting to make it human-readable. - How should the parameter action be configured?
Answer: Use Sales as the source field with Sum aggregation so the combined sales of all selected marks are assigned to the parameter.
When configuring a parameter action in Tableau, your goal is to ask: what value do I want the parameter to hold, and how should it be derived from the selected marks? Parameter actions pull a value from a source field and assign it to the parameter — and when multiple marks are selected, the aggregation setting determines how those multiple values collapse into a single number.
Here, you need the parameter to reflect the combined sales of all selected regions. That means summing the sales values across every selected mark. Option B does exactly this: using Sales as the source field with Sum aggregation causes Tableau to add up the SUM([Sales]) values from each selected region bar and pass that total into the parameter. If two regions are selected with $200K and $350K in sales, the parameter receives $550K.
Option A uses Average aggregation, which would divide the total by the number of selected regions — giving you a per-region average rather than a combined total. Option C sources from Region with Count aggregation, which counts how many regions are selected rather than measuring their sales at all — this would produce 2 or 3, not a dollar figure. Option D uses Minimum, which discards all selected values except the smallest, making multi-select behavior misleading and inconsistent.
The key study tip: on parameter action questions, always match the aggregation to the semantic intent — "combined" means Sum, "typical" means Average, "smallest/largest" means Min/Max. Misreading the business requirement is the most common trap here, so slow down and identify exactly what the parameter is supposed to represent.
- Which design most directly provides this behavior using Tableau's native bin functionality?
Answer: Create a numeric Bin Size parameter and use that parameter as the generated bin field's size.
When you see a question about dynamic histogram bin widths in Tableau, think about how parameters integrate with native bin fields — this is a core workflow for making visualizations interactive without duplicating data structure.
Tableau's generated bin fields have a Size of bins property that accepts not just fixed numbers, but also parameter references. By creating a numeric parameter (say, "Bin Size") and setting the generated [Sales (bin)] field's size to that parameter, users can adjust the slider or input box at runtime and the histogram instantly redraws with the new bin width. This is exactly what A describes — it's the native, purpose-built mechanism Tableau provides for this use case.
B is wrong because placing a parameter directly on Columns doesn't replace or control a bin field — parameters aren't dimensions that automatically group continuous measures into bins. You'd just be placing a constant value on the axis, not restructuring the histogram's aggregation logic.
C describes parameter actions, which allow a click or selection to write a value into a parameter — but parameter actions respond to mark selections in the view, not to a user typing or sliding a bin-width control. More importantly, you cannot write directly into a generated bin field through a parameter action; you'd still need the parameter connected to the bin size property as in A.
D confuses filtering with binning. A range filter removes data points from the view but doesn't change how remaining values are grouped into bins — the histogram structure stays unchanged.
Study tip: On Tableau exam questions, whenever "dynamic bin width" appears, the answer almost always involves wiring a numeric parameter to the bin field's size property — that's the one native path Tableau provides.
- Which modification best meets the new requirement?
Answer: Create a second parameter and revise one worksheet's calculation to reference the new parameter.
When you see a question about parameters in Tableau, the key concept to remember is that a parameter is a single global variable — it exists once in the workbook, and every reference to it points to the same value. There is no native way to scope a parameter to an individual worksheet; it's workbook-wide by design.
Because both worksheets reference the same Forecast Months parameter, any change to that parameter — regardless of which control the user interacts with — updates both worksheets simultaneously. The only way to give each worksheet an independent horizon is to give each its own separate parameter. That means creating a second parameter and updating one worksheet's calculation to reference the new parameter instead of the original. This is exactly what D prescribes, and it's the correct answer.
A is a trap: duplicating the control (the UI widget) does nothing to decouple the underlying parameter. Two controls pointing at the same parameter still move in lockstep — users would see two sliders that always match.
B describes a feature that doesn't exist in Tableau. Parameter controls cannot be scoped or restricted to a neighboring worksheet through any menu option; the control simply exposes the single global parameter value.
C confuses aliases with parameters. Aliases are display-name substitutions for dimension members in a data source — they have no effect on parameter behavior or independence whatsoever.
As a study tip: on the Tableau exam, whenever a scenario requires independent control of the same type of variable across worksheets, the answer almost always involves creating separate parameters, not duplicating controls or reassigning existing ones.
