- Which design choice best avoids repeated, unnecessary refresh work?
Answer: Allow users to pause automatic updates, make the selections, and resume updates once the configuration is complete.
When a question describes users making multiple sequential filter changes without needing to see intermediate results, you should immediately think about unnecessary query triggering. The core problem is that each filter change fires a fresh data query by default, so five changes generate five refreshes when only one final refresh is actually needed.
Tableau's Pause Automatic Updates feature (the pause button in the toolbar) is designed exactly for this scenario. When users pause updates, they can adjust all five filters freely, then resume — triggering a single refresh that reflects the final configuration. This is why D is correct: it directly addresses the root problem by collapsing five refreshes into one.
A is tempting but wrong. Table-calculation filters operate after data is returned from the source, meaning the underlying query still runs on every change. They reduce what's displayed, not what's computed. Using them doesn't prevent repeated refreshes.
B confuses query efficiency with query frequency. "Only relevant values" (domain filtering) reduces the size of each refresh query, but a refresh still fires after every filter change. You've made each trip shorter, but you're still making five trips.
C misapplies context filters. Adding filters to context is useful for optimizing filter processing order, but context itself gets recomputed when context filter values change. Making all five filters context filters would actually cause the context to rebuild with each sequential selection — potentially more expensive, not less.
Study tip: On Tableau exam questions about performance and user interaction, watch for the phrase "does not need intermediate states" — it's a signal that Pause Automatic Updates is the intended tool.
- Which conclusion is best supported by the information provided?
Answer: The source row count alone does not prove the table calculation is the bottleneck; measure query, filter-domain, and local calculation costs separately.
When troubleshooting Tableau dashboard performance, your first instinct should be to isolate where the slowness actually lives rather than assuming the most visible or largest component is the culprit. Performance has several distinct cost centers: the database query that aggregates raw rows into marks, filter-domain queries that populate dropdown lists, and local computations (like table calculations) that run in Tableau's engine after the query returns.
B is correct because the scenario tells you the database query already reduces 100 million rows to ~2,000 marks before the percent-of-total table calculation ever runs. A table calculation operating on 2,000 marks is trivially fast. The real bottleneck could be the aggregation query itself, or the five high-cardinality filter controls each firing their own domain queries to populate their list of values. You cannot conclude the table calculation is slow without measuring each component separately — using tools like Tableau's built-in Performance Recorder.
A is wrong because it fixates on the raw row count rather than what the table calculation actually receives. Row count in the source is irrelevant to a calculation that only sees 2,000 aggregated marks.
C is wrong because filter-domain queries absolutely do hit the data source to retrieve distinct values — especially for high-cardinality fields. These queries can be a significant and often overlooked performance cost.
D is wrong because an extract does not automatically eliminate either cost. Filter-domain queries still run against the extract, and percent-of-total is still computed locally regardless of connection type.
Your study tip: on Tableau performance questions, always trace the data flow — source → query → marks → local calculation — and ask which stage is actually doing heavy work.
- Which assessment best reflects the performance tradeoff in this design?
Answer: The design improves selection accuracy, but the large dependent City domain may still require costly refreshes whenever State changes.
When you see a question about filter dependencies and context filters in Tableau, your mental model should center on how Tableau queries the data source to populate filter value lists — and what triggers those queries.
Placing Country in context does one important thing: it creates a temporary table that scopes subsequent filters, improving query efficiency for filters that depend on Country. However, context filters do not magically cache every downstream value list forever. When a user changes State, Tableau still needs to re-query the data source to determine which City values are relevant to that new State selection. Because the City domain is large, this re-query is expensive and happens frequently — since State changes are described as common. Answer B correctly captures this tension: the "Only Relevant Values" approach ensures accurate, dependent filter lists, but the City domain refresh on every State change carries a real performance cost.
Answer A is incorrect because context filters do not cache all downstream value lists indefinitely. Caching applies to the context query itself, not to every dependent filter's domain across all possible selections.
Answer C misrepresents how "Only Relevant Values" works. This mode issues actual data-source queries to compute relevant members — it does not derive them purely from displayed marks (that's "Only Relevant Values" from the view, a different mechanism), so query overhead absolutely exists.
Answer D is backwards. State filter changes do trigger City domain refreshes because City depends on State, not just on Country. Ordinary filters absolutely affect dependent value domains.
Your study takeaway: context filters reduce redundant querying but don't eliminate downstream refresh costs — always trace the dependency chain when evaluating filter performance.
- Which redesign most appropriately removes the high-cardinality filter-control pitfall while preserving the stated requirement?
Answer: Use a free-entry parameter for one identifier and filter with a Boolean comparison against the customer field.
When a filter control must load millions of distinct values, Tableau queries the full domain before rendering the dropdown — creating the slowdown you see here. The solution isn't to shrink or reorganize that list; it's to eliminate the list entirely. Since users always type exactly one known identifier rather than browse, a parameter is the right tool: it accepts free text input, never queries the data source for a domain, and renders instantly regardless of cardinality. You then create a calculated field like [Customer Identifier] = [Customer Parameter] and place it on the filter shelf as a Boolean. This perfectly matches the stated requirement — one entry, no browsing — and D describes exactly this approach.
Choice A is a red herring. Converting the field to a discrete table calculation doesn't reduce the number of unique values Tableau must display; it still iterates over millions of records and presents them in a filter control, preserving the performance problem.
Choice B — showing only relevant values — can reduce the list contextually, but it doesn't eliminate the domain-loading cost for a two-million-row identifier field. It also still forces users to scroll or search a large list, which conflicts with the "no browsing needed" requirement.
Choice C puts the field on Detail so users click a mark on the viz. With two million customers, the rendered view would be an unnavigable sea of marks, making selection impractical and doing nothing to address filter-control performance.
As a study tip, remember this pattern: high cardinality + single known value = parameter, not filter. Anytime you see a question pairing a massive domain with a precise, typed lookup, parameters are almost always the correct answer.
- Which change is most likely to reduce interaction time while preserving the useful cascading behavior?
Answer: Retain Only Relevant Values for the three dependent controls and simplify or remove the remaining visible filter controls.
When a dashboard has multiple filters set to Only Relevant Values, Tableau issues a separate database query for each filter's value list whenever any selection changes. If most of those filters don't actually depend on each other, you're paying a performance cost for dependency behavior you don't need — this question asks you to identify the most surgical fix.
The right move is A: keep Only Relevant Values only for the three controls that genuinely cascade, and simplify or remove the others. This directly eliminates the unnecessary re-query chain. Tableau no longer needs to refresh value lists for filters that have no meaningful dependency, so interaction time drops while the useful cascading behavior remains intact. The fix is targeted and proportional to the actual problem.
B is tempting but flawed. Converting everything to context filters doesn't eliminate queries — it restructures them around a temporary table. You'd still be computing value lists for all 12 filters, and context filters carry their own overhead (rebuilding the temp table on each context change). This trades one performance problem for another.
C misdiagnoses the issue. Switching to an extract improves raw query speed, but it leaves all 12 filter dependencies in place. You'd still trigger multiple value-list refresh queries on each interaction — they'd just run faster against local data. The cascade problem persists.
D is a misconception about scope. Table calculations operate on data already returned by a query; they can't drive filter value lists, which are generated before the mark-level data is rendered.
Study tip: On performance questions, distinguish between what triggers queries and how fast those queries run — the best fix usually reduces the number of queries, not just their speed.
- Which explanation and response best address this performance pattern?
Answer: The context is rebuilt when the date changes; remove the date from context unless the dependent customer list justifies that recurring cost.
When you see a question about Tableau context filters and performance, think about the cost-benefit tradeoff: context filters rebuild a temporary table every time they change, so placing a high-frequency filter in context can be expensive.
Here's what's happening in this scenario. Every time the analyst adjusts the date range, Tableau rebuilds the entire context — generating a new temporary table from the full data source. That rebuild is the source of the slowness. Answer A correctly identifies this: the context is reconstructed on each date change, and the analyst should evaluate whether the benefit (a correctly scoped Customer dependent filter) actually justifies paying that rebuild cost repeatedly. If the customer dependency is essential, the design is defensible; if not, the date filter should leave context.
Answer B gets the filter order backwards. Context filters are evaluated first, before noncontext filters like Category — not after. Moving Category into context would only add more rebuild overhead, not delay the date evaluation.
Answer C contains two misconceptions. Context filters don't "scan the full data source" in a way that table-calculation filters would bypass — and table-calculation filters actually run after aggregation in Tableau's order of operations, making them generally worse for performance, not better. Query pushdown doesn't apply here the way the answer implies.
Answer D is simply false. The customer domain cache is not permanent across date selections. Changing the context filter (the date) invalidates and rebuilds that cache each time, which is precisely the performance problem being described.
Your takeaway: on context-filter questions, always ask how often does this filter change? Frequent changes mean frequent rebuilds — context is best reserved for filters that are set once or rarely adjusted.
- Which change is both semantically appropriate and likely to improve performance?
Answer: Use a regular region filter before the ranking calculation so fewer marks enter the table-calculation stage.
Whenever you see a question about table calculations and performance in Tableau, the core concept to keep in mind is the order of operations. Tableau processes filters in a specific sequence: regular (dimension) filters execute early, reducing the dataset before most calculations run, while table-calculation filters execute late — after the full computation has already occurred.
This distinction is exactly what makes C the right answer. A regular Region filter acts as a dimension filter, meaning Tableau eliminates non-selected regions before computing the rank. With ~500,000 marks, filtering down to a single region first could reduce the working dataset dramatically — say, from 500,000 marks to 100,000 — so the ranking calculation partitions and processes far fewer rows. It's also semantically correct: you genuinely want to rank products only within the selected region, which a pre-calculation filter enforces by definition.
Each distractor contains a specific trap. A is wrong because moving Region to Detail expands partitions rather than shrinking them — you'd be ranking across more marks, not fewer, defeating both goals. B is the most tempting distractor: it sounds plausible because table-calculation filters do "hide" marks visually, but the ranking calculation already ran on the full 500,000-mark partition before any hiding occurs, so performance doesn't improve and the rank values reflect the wrong scope. D is wrong because using a parameter in a label doesn't filter data at all — all marks still enter the calculation stage and the partition remains unchanged.
The study tip here: always ask when a filter fires in Tableau's order of operations. If a filter runs after table calculations, it cannot reduce the computation cost or correct partition-level logic.
- Which redesign most directly addresses the principal table-calculation performance pitfall?
Answer: Preaggregate the required data to month and region, then calculate the prior-period comparison on the smaller result.
When you see a question about table-calculation performance, the core concept to focus on is partition size. Table calculations like WINDOW_SUM and LOOKUP operate row-by-row across the underlying query result set — not the visual summary. That means if your underlying data contains millions of marks, Tableau evaluates those calculations across millions of rows, even if the final view only shows a handful of aggregated values.
Option A is the correct redesign because it attacks the root cause directly: too many marks entering the table-calculation engine. By preaggregating to month and region before the comparison logic runs, you reduce the partition from millions of customer-day rows to perhaps a few dozen monthly-regional subtotals. The nested WINDOW_SUM/LOOKUP then operates on that tiny result set, yielding dramatic performance gains without sacrificing any information the dashboard actually displays.
Option B makes the problem worse, not better. Adding customer ID to Detail increases mark granularity, expanding the partition the table calculations must traverse. Option C is a common instinct — context filters do run earlier in Tableau's order of operations — but they still leave all the customer-day marks intact within the filtered scope; you've narrowed the data slightly but haven't collapsed it to the monthly grain the view needs. Option D is a misconception about how Tableau evaluates calculations. Moving a calculation to a tooltip defers its display, but Tableau still computes the underlying query result eagerly; you don't meaningfully avoid the performance cost.
The study tip here: always ask "how many marks feed the table calculation?" Reducing mark count before the calculation runs is almost always more effective than changing filters or display locations.
- Which action is most likely to produce the largest improvement?
Answer: Reduce the worksheet's mark count and simplify the calculations before considering a different connection type.
When Tableau Performance Recording reveals that database queries are fast but table calculations and mark rendering are slow, you've identified a client-side bottleneck — the problem lives in Tableau's local processing engine, not the database. Your fix should target exactly those two culprits directly.
That's precisely what A does. Reducing the mark count (by filtering, aggregating, or redesigning the view) directly cuts rendering time, and simplifying table calculations reduces the computational load Tableau carries locally. Crucially, A also reflects good diagnostic discipline: address the confirmed bottlenecks before introducing architectural changes like switching connection types.
B is tempting but contains a fundamental misconception. Extracts do speed up many queries by moving data to Tableau's fast in-memory engine, but they do not eliminate table calculation processing — Tableau still evaluates those calculations locally regardless of connection type. An extract won't solve the mark-rendering problem either.
C misunderstands how filters and caching work. Adding more filter controls doesn't meaningfully improve performance through caching; it can actually increase complexity and query overhead. Fewer, well-designed filters are generally better for performance.
D confuses table calculations with database queries. Table calculations are evaluated after data is returned from the database — they never execute as part of a SQL query. Nesting them doesn't push logic to the database; it only reorganizes client-side computation.
As a study tip: always let the Performance Recording data guide your solution. If the recording points to a specific bottleneck, the best answer will target that bottleneck directly rather than introduce unrelated architectural changes.
- Which modification most directly reduces duplicated work during initial dashboard loading?
Answer: Remove or defer worksheets that users do not initially need, and consolidate sheets where one view can satisfy multiple requirements.
When optimizing dashboard load performance, think about what work Tableau actually needs to do at load time. Every worksheet rendered on initial load requires its own query, filter evaluation, and table calculation — so the number of active sheets directly multiplies the computational cost.
The most impactful lever here is reducing the number of worksheets Tableau must render upfront. Since users only view two of the eight sheets initially, the other six are consuming query execution, filter processing, and expensive table calculations for no immediate benefit. Answer C targets this directly: removing or deferring unused sheets eliminates that wasted work entirely, and consolidating views means fewer redundant computations overall. Fewer sheets rendered = less duplicated effort at load time.
Answer A makes things worse, not better. Duplicating the data source means Tableau maintains separate connections and caches, increasing overhead rather than sharing work across sheets. Parallelism doesn't eliminate redundancy — it just runs redundant work simultaneously.
Answer B is a reasonable-sounding distractor, but filter controls are not the bottleneck described. Sharing a filter UI widget doesn't automatically make Tableau reuse a single intermediate computation for all eight sheets. Each sheet still executes its own query pipeline.
Answer D misunderstands how table calculations work. Merging logic into one calculated field doesn't cause Tableau to share computation across separate worksheets — each sheet still evaluates its own result set independently.
As a study tip: on Tableau performance questions, always trace the problem back to how many views are being rendered. Reducing rendered sheet count is almost always more impactful than optimizing what's inside those sheets.
