Tableau Quiz: Parameters
10 questions · exam conditions
0:00
ParametersQuestion 1 of 10

A worksheet contains one mark per customer and displays total sales as SUM([Sales]). An analyst creates a numeric parameter named Minimum Sales and wants the view to retain only customers whose total sales meet the selected threshold.

Which implementation correctly applies the parameter at the customer-total level?

Place Minimum Sales directly on the Filters shelf and retain parameter values above the desired threshold.
Create [Sales]>=[MinimumSales][Sales] >= [Minimum Sales], place it on Filters, and retain only records where the result is True.
Create SUM([Sales])>=[MinimumSales]SUM([Sales]) >= [Minimum Sales], place it on Filters, and retain only marks where the result is True.
Add a reference line based on Minimum Sales and configure the line to display only when totals exceed it.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Parameters

Practice Parameters 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 Parameters, 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 contains one mark per customer and displays total sales as SUM([Sales]). An analyst creates a numeric parameter named Minimum Sales and wants the view to retain only customers whose total sales meet the selected threshold.

Which implementation correctly applies the parameter at the customer-total level?

  1. Place Minimum Sales directly on the Filters shelf and retain parameter values above the desired threshold.
  2. Create [Sales]>=[MinimumSales][Sales] >= [Minimum Sales], place it on Filters, and retain only records where the result is True.
  3. Create SUM([Sales])>=[MinimumSales]SUM([Sales]) >= [Minimum Sales], place it on Filters, and retain only marks where the result is True. (correct answer)
  4. Add a reference line based on Minimum Sales and configure the line to display only when totals exceed it.
Explanation: 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]SUM([Sales]) >= [Minimum Sales] 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][Sales] >= [Minimum Sales], 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.

Question 2

A published workbook uses a date parameter named As-of Date. Each time a new session opens the workbook, the parameter's list should reflect the available values in [Snapshot Date], and its initial selection should be the latest available snapshot.

Which parameter configuration satisfies both requirements without manually editing the workbook after each data refresh?

  1. Use a fixed list of dates and set the current value to today's date each time the workbook is republished.
  2. Populate the allowable values with a fixed list sourced from Snapshot Date and save the final listed date as the current value.
  3. Allow all date values and rely on the user to manually select the most recent snapshot after opening the workbook.
  4. 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. (correct answer)
Explanation: 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.

Question 3

A dashboard contains two worksheets that both use a parameter named Forecast Months. The designer displays a parameter control next to each worksheet. Users report that changing either control also changes the forecast horizon in the other worksheet. The two worksheets now need independently selectable horizons.

Which modification best meets the new requirement?

  1. Duplicate the parameter control while retaining the same parameter in both forecast calculations.
  2. Apply each displayed parameter control only to its neighboring worksheet through the control menu.
  3. Create two aliases for the parameter values and assign one alias set to each forecast worksheet.
  4. Create a second parameter and revise one worksheet's calculation to reference the new parameter. (correct answer)
Explanation: 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.

Question 4

A dashboard parameter action updates Selected Customer when a user selects a customer mark. The selected customer drives detailed calculations on other worksheets. When the user clears the selection, the dashboard should continue showing details for the most recently selected customer.

Which clearing-selection behavior should be configured for the parameter action?

  1. Set the parameter to its default value so clearing a selection restores the workbook's originally saved state.
  2. Keep the current parameter value so clearing a selection leaves the most recently selected customer in place. (correct answer)
  3. Set the parameter to a blank string so downstream calculations can detect that no customer is actively selected.
  4. Revert the parameter to the first customer in the list so the view always falls back to a predictable starting state.
Explanation: 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.

Question 5

A dashboard contains one bar per region, with each bar showing SUM([Sales]). A numeric parameter named Selected Sales Total is targeted by a parameter action. Users may select several region bars simultaneously, and the parameter should become the combined sales of all selected regions.

How should the parameter action be configured?

  1. Use Sales as the source field with Average aggregation so each selected region contributes an equal-weighted value.
  2. Use Sales as the source field with Sum aggregation so the combined sales of all selected marks are assigned to the parameter. (correct answer)
  3. Use Region as the source field with Count aggregation so the parameter receives the number of selected regions.
  4. Use Sales as the source field with Minimum aggregation so the parameter reflects the smallest regional sales value among selected marks.
Explanation: 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.

Question 6

A worksheet uses a parameter named Top Customers to control the number of customers retained by a Top filter based on SUM([Sales]). The worksheet also has a single-value Region filter. Users expect to see the top selected number of customers within the chosen region, but Tableau currently identifies the top customers across all regions before applying the Region filter.

What change is required while continuing to use the parameter-controlled Top filter?

  1. Convert Top Customers to a string parameter and compare its selected label with each customer's rank.
  2. Add the Region filter to context so it is evaluated before the parameter-controlled Top customer filter. (correct answer)
  3. Show the Top Customers parameter control on the worksheet and place it above the Region filter control.
  4. Convert the Region filter to a parameter so all parameter values are evaluated before dimension filters.
Explanation: 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.

Question 7

A histogram uses a generated bin based on [Sales]. Users need to interactively change the bin width among positive numeric values without requiring the workbook author to create separate bin fields.

Which design most directly provides this behavior using Tableau's native bin functionality?

  1. Create a numeric Bin Size parameter and use that parameter as the generated bin field's size. (correct answer)
  2. Place a numeric Bin Size parameter on Columns and replace the generated Sales bin dimension.
  3. Create a parameter action that writes the selected value directly into the generated Sales bin field.
  4. Use a range filter controlled by Bin Size to remove sales values outside the selected width.
Explanation: 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.

Question 8

A what-if analysis lets users select a reduction from zero through 30 percent. When the control displays 10 percent, adjusted sales should equal 90 percent of total sales. The calculation is SUM([Sales])∗(1−[Reduction])SUM([Sales]) * (1 - [Reduction]).

How should the Reduction parameter be configured?

  1. Use an integer value of 1010 and display it as a percentage without changing the calculation.
  2. Use a string value of 10 percent and rely on Tableau to convert it during multiplication.
  3. Use a numeric value of 0.100.10 and format the parameter's displayed value as a percentage. (correct answer)
  4. Use a numeric value of 10.0010.00 and format it as a decimal with two displayed places.
Explanation: 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])SUM([Sales]) * (1 - [Reduction]) requires [Reduction] to be a decimal proportion. When the user selects 10 percent, the formula needs 1−0.10=0.901 - 0.10 = 0.90, which correctly yields 90% of sales. That means the parameter's stored value must be 0.100.10, not 1010. Tableau's parameter formatting options let you display 0.100.10 as "10%" to the user while the underlying value remains 0.100.10 — exactly what C describes. A is wrong because storing an integer value of 1010 would make the calculation 1−10=−91 - 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.0010.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.

Question 9

A time-series worksheet must let users switch the date axis among Week, Month, and Quarter. The axis should remain a date axis, and periods from different years must remain distinct.

Which approach most appropriately uses a parameter to control the date granularity?

  1. Create an integer parameter and return DATEPART values for week, month, or quarter based on the selected number.
  2. Place Order Date on the view three times and use a parameter as a filter to retain one date pill.
  3. Create a string parameter and use a CASE calculation that returns DATETRUNC of Order Date for each selected grain. (correct answer)
  4. Create a date parameter and assign its current value directly as the date level of the Order Date pill.
Explanation: 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.

Question 10

An analyst creates a string parameter named Metric with the values Revenue, Profit, and Margin. A single calculated field must return an aggregate value for the selected metric. Revenue is [Sales], Profit is [Profit], and Margin is profit divided by sales.

Which calculated field is valid and produces the intended result?

  1. CASE[Metric]WHEN′Revenue′THENSUM([Sales])WHEN′Profit′THENSUM([Profit])WHEN′Margin′THENSUM([Profit])/SUM([Sales])ENDCASE [Metric] WHEN 'Revenue' THEN SUM([Sales]) WHEN 'Profit' THEN SUM([Profit]) WHEN 'Margin' THEN SUM([Profit]) / SUM([Sales]) END (correct answer)
  2. CASE[Metric]WHEN′Revenue′THEN[Sales]WHEN′Profit′THENSUM([Profit])WHEN′Margin′THEN[Profit]/[Sales]ENDCASE [Metric] WHEN 'Revenue' THEN [Sales] WHEN 'Profit' THEN SUM([Profit]) WHEN 'Margin' THEN [Profit] / [Sales] END
  3. CASE[Metric]WHEN′Revenue′THENAVG([Sales])WHEN′Profit′THENAVG([Profit])WHEN′Margin′THENSUM([Profit]/[Sales])ENDCASE [Metric] WHEN 'Revenue' THEN AVG([Sales]) WHEN 'Profit' THEN AVG([Profit]) WHEN 'Margin' THEN SUM([Profit] / [Sales]) END
  4. CASE[Metric]WHEN′Revenue′THENSUM([Sales])WHEN′Profit′THENSUM([Profit])WHEN′Margin′THEN[Profit]/SUM([Sales])ENDCASE [Metric] WHEN 'Revenue' THEN SUM([Sales]) WHEN 'Profit' THEN SUM([Profit]) WHEN 'Margin' THEN [Profit] / SUM([Sales]) END
Explanation: 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])SUM([Sales]), Profit uses SUM([Profit])SUM([Profit]), and Margin uses SUM([Profit])/SUM([Sales])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][Sales] (row-level) while Profit uses SUM([Profit])SUM([Profit]) (aggregate). This inconsistency causes a validation error, making the field unusable. Answer C uses SUM([Profit]/[Sales])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][Profit] at row-level in the numerator but SUM([Sales])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)SUM(\text{numerator}) / SUM(\text{denominator}).