All questions
Question 1
How does adding one filter to context affect the remaining filters?
- They are applied after it (correct answer)
- They are applied before it
- They are ignored in the view
- They are sent to the source
Explanation: When you set a filter as a context filter, Tableau evaluates it first to define the data set. Every remaining filter then runs on that already narrowed data, so they are applied after it. The tempting mistake is thinking they are ignored, but they still affect the view, just after the context filter.
Question 2
Why make Region a context filter for Top 5 Products in West?
- Top N runs on West rows (correct answer)
- Top N runs before Region
- Region runs after Top N
- Top N ignores other filters
Explanation: With Region as a context filter, Tableau applies the West filter first. So Top N sees only West rows and picks the top 5 products within that region. Without it, Top N runs on all rows and Region filters afterward, so you might get fewer than 5 West products; that's the mistake to avoid.
Question 3
Why should a workbook avoid making every filter a context filter?
- They prevent quick filter use
- They run before the extract
- They create a temporary table (correct answer)
- They remove all duplicate rows
Explanation: Every context filter forces Tableau to build a temporary table before other filters run, so using them everywhere multiplies the work and slows performance. The tempting wrong answer is that they prevent quick filter use, but context filters don't disable quick filters; they just change evaluation order and add that extra temp-table cost.
Question 4
How does a context filter mainly help performance?
- It sorts rows before loading
- It always reduces query time
- It replaces extract filters
- Reduces rows for later filters (correct answer)
Explanation: A context filter computes first, so later filters and calculations see a smaller dataset. That means less work downstream, which is the main performance gain. The tempting wrong answer is "it always reduces query time," but no filter guarantees faster performance in every case, especially if the context filter itself is costly.
Question 5
A large extract has many filters. Which filter makes the best context filter?
- The last filter on the shelf
- One that removes the most rows (correct answer)
- One that sorts values by name
- One that changes only labels
Explanation: A context filter runs first and creates a smaller temporary table, so the most effective one is the filter that removes the most rows. That reduces what the remaining filters have to process. The tempting wrong choice is the last filter on the shelf: shelf order isn't what matters, because context filters change execution order, not row count.
Question 6
A view uses a calculation equivalent to { FIXED [Customer ID] : SUM([Sales]) }. A Region dimension filter is applied, but the fixed customer totals continue to include sales from regions excluded by that filter.
Which action would make the fixed totals respond to the Region selection without rewriting the calculation?
- Change Region to a context filter so it is evaluated before the FIXED level-of-detail expression. (correct answer)
- Change Region to a measure filter so it is evaluated before the FIXED level-of-detail expression.
- Move Region to the top of the Filters shelf so Tableau evaluates it before the fixed calculation.
- Set Region to show only relevant values so the fixed calculation uses only visible regions.
Explanation: Whenever you see a question about FIXED level-of-detail (LOD) expressions behaving unexpectedly with filters, the key concept to recall is Tableau's order of operations. Tableau evaluates filters in a specific sequence: context filters → dimension filters → LOD expressions (FIXED) → measure filters. This order determines what data each calculation "sees."
Because FIXED LODs are evaluated after regular dimension filters, a Region dimension filter has no effect on a FIXED calculation — the LOD has already locked its scope to Customer ID regardless of what the filter excludes. The solution is to promote Region to a context filter, which places it earlier in the pipeline, before FIXED LODs are computed. This means the FIXED expression only sees the data that survives the context filter, making it respond to the Region selection. That makes A correct.
B is wrong because measure filters sit even later in the order of operations than FIXED LODs — moving Region there would have no impact on the calculation's scope whatsoever. C is a common trap: dragging a filter to the "top" of the Filters shelf does not change its evaluation stage. Tableau's order of operations is determined by filter type, not physical position on the shelf. D is a display setting that controls what appears in a filter dropdown for user convenience; it has no effect on how LOD expressions are computed.
Study tip: Memorize Tableau's filter order as: Extract → Data Source → Context → Sets/Conditions → Dimension → LOD (FIXED) → Measure. When a FIXED LOD ignores a filter, your first instinct should be "does this filter need to become a context filter?"
Question 7
A workbook queries a very large relational table. Users select one business unit at the beginning of a session, and that selection typically retains only a small fraction of the rows. Several other filters and views then operate on the selected unit, which rarely changes during the session.
Why might making Business Unit a context filter improve performance in this situation?
- It can create a much smaller working data set that several dependent filters repeatedly query. (correct answer)
- It forces Tableau to cache every possible business-unit selection before users open the workbook.
- It converts all dependent filters into extract filters that are evaluated during data refresh.
- It causes Tableau to bypass aggregation and retrieve only precomputed marks from the data source.
Explanation: When you see a question about Tableau performance optimization, focus on how data flows through the query pipeline and where filtering occurs relative to other operations.
Context filters in Tableau execute first, before all other filters, and their result is temporarily stored as a special data set that subsequent filters and views query against. This is the key mechanism: instead of every downstream filter hitting the full relational table repeatedly, they all work against a dramatically reduced subset. In the scenario described, selecting a single business unit eliminates the vast majority of rows upfront. Every other filter, calculated field, and view then operates on that smaller working set rather than scanning the entire table each time. Answer A captures this precisely — the context filter creates a compact intermediate data set that dependent filters reuse throughout the session, reducing the repetitive cost of large table scans.
Answer B is incorrect because context filters do not pre-cache all possible selections before the workbook opens. Tableau generates the context for whichever value the user actually selects, not every possible value in advance.
Answer C confuses context filters with extract filters. Extract filters are applied when building a .hyper extract during data refresh — an entirely separate mechanism. Context filters operate at query time against the live or extracted data source, not during refresh.
Answer D describes something Tableau doesn't do at all. Context filters don't bypass aggregation or retrieve precomputed marks; aggregation still occurs normally on the reduced data set.
As a study tip, remember the phrase "context first, then everything else." On the Tableau exam, any question about query order or filter hierarchy should prompt you to think about context filters as the earliest evaluation step.
Question 8
An analyst makes Order ID a context filter on a transaction-level worksheet. The filter normally retains nearly all orders, and users change its multi-select values after almost every interaction. The worksheet becomes slower rather than faster.
Which explanation best accounts for the performance decrease?
- The context is highly selective, so Tableau must repeatedly query too few rows to use efficient aggregation.
- The context provides little data reduction and may need to be rebuilt whenever its selection changes. (correct answer)
- Context filters always disable query optimization whenever they contain a high-cardinality dimension.
- Order ID becomes a table-calculation filter, requiring Tableau to render all orders before filtering them.
Explanation: When you see a question about context filters and performance, your mental model should center on what a context filter actually does mechanically: Tableau materializes a temporary table containing only the rows passing the context filter, then runs all other filters against that smaller set. The key performance question is always: does the temporary table meaningfully reduce the data?
Here, Order ID retains nearly all orders and users change its selection constantly. That combination is doubly problematic. First, the temporary table is almost as large as the original data, so downstream queries gain little benefit. Second, every time the user changes the multi-select values, Tableau must rebuild the context — regenerating that temp table from scratch. You're paying the overhead cost repeatedly without receiving the payoff of a smaller working dataset. That's exactly what B describes, making it the correct answer.
A is wrong because it inverts the logic — high selectivity (filtering to few rows) is actually where context filters help most, not hurt. Low selectivity (few rows removed) is the problem here.
C is wrong because context filters don't universally disable query optimization based on cardinality. High cardinality is relevant to context filter design choices, but it doesn't trigger a blanket optimization shutdown.
D is wrong because context filters are not the same as table-calculation filters. Table-calculation filters operate post-aggregation in Tableau's query pipeline, but context filters operate at the data source level. Order ID here never becomes a table-calculation filter just by being set as context.
Your study tip: remember context filters as a trade-off tool — they only help when they dramatically shrink the dataset and remain stable. High cardinality + frequent changes = net performance loss.
Question 9
A worksheet ranks products with a table calculation. It also has an ordinary Category dimension filter. The rank already recalculates using the products remaining after the Category selection. An analyst proposes adding Category to context solely to make the table calculation see the filtered category.
Which assessment of the proposal is most accurate?
- It is required because table calculations are evaluated before every ordinary dimension filter but after context filters.
- It is ineffective because table calculations are always evaluated before context and ordinary dimension filters.
- It is required because context converts the rank from a table calculation into a database-level Top filter.
- It is unnecessary for that purpose because ordinary dimension filters also precede table calculations. (correct answer)
Explanation: When a question asks about adding a dimension to context, you should immediately think about Tableau's order of operations and why context filters exist in the first place. Context filters sit early in the query pipeline specifically to create a temporary table that downstream filters and calculations work against — but the key question is always: what problem does that actually solve?
Ordinary dimension filters in Tableau are applied before table calculations are evaluated. This means that when a user selects a category, the underlying data is already restricted to that category before the rank calculation runs. The rank therefore naturally reflects only the filtered products — no context filter is needed to achieve this. That's precisely why D is correct: the proposal is unnecessary because ordinary dimension filters already precede table calculations, so the rank is already "seeing" the filtered data.
A is wrong because it inverts reality — ordinary dimension filters are not evaluated after table calculations; they come before. The whole reason table calculations can sometimes produce unexpected results with filters is that table calculations run on top of whatever the query returns, not before filters restrict that query. B is wrong because it claims table calculations run before all filters, including ordinary ones — this is false. Table calculations run after dimension filters have already narrowed the data. C is wrong because context filters do not convert table calculations into database-level Top N filters; that's a separate (and valid) use case for context, but it has nothing to do with making a table calculation recognize a filtered category.
A useful rule of thumb: context filters solve two specific problems — enabling Top N filters that reference aggregated measures, and improving query performance on large data sources. If neither of those applies to your scenario, context is probably unnecessary.
Question 10
Two worksheets use the same published data source. On the first worksheet, Region is added to context to control a customer Top filter. The second worksheet has its own customer Top filter but does not have Region configured as a context filter.
What should the author expect on the second worksheet?
- Its customer Top filter automatically uses the first worksheet's regional context because the data source is shared.
- Its customer Top filter is disabled because a shared data source can support only one worksheet context.
- Its customer Top filter becomes a context filter automatically when the first worksheet is placed on a dashboard.
- Its customer Top filter remains unaffected unless the Region filter and required context behavior are applied there. (correct answer)
Explanation: When you see a question about context filters in Tableau, remember the core principle: context filters are worksheet-specific configurations, not data source-level settings. A context filter controls filter evaluation order only on the sheet where it is explicitly set up.
Because context filters belong to individual worksheets, the second worksheet operates completely independently. Its Top N customer filter has no awareness of what the first worksheet has configured. Since Region was never added to context on the second worksheet, that sheet's Top filter runs against the full, unfiltered dataset — exactly as designed. Answer D captures this correctly: the second worksheet's filter is unaffected unless the author explicitly applies Region as a context filter there too.
Answer A is wrong because sharing a published data source does not propagate filter configurations between worksheets. Data source sharing means both sheets pull from the same underlying data, nothing more — filter logic stays local to each sheet. Answer B is wrong because there is no such limitation as "one context per shared data source." Multiple worksheets can each have their own independent context filters simultaneously without conflict or disabling. Answer C is wrong because placing worksheets on a dashboard does not trigger automatic context filter inheritance or promotion. Dashboard layout has no effect on how individual worksheet filters are evaluated.
A useful rule of thumb: in Tableau, anything configured in the "Filters" shelf or its settings is scoped to that worksheet. When an exam question implies that one sheet's filter setup "travels" to another sheet automatically, that is almost always a trap. Always ask yourself — was it explicitly set up on that sheet?
Question 11
A worksheet has Year and Region as context filters. Year is set to the current year, Region is set to West, and Customer Name has a Top filter. An analyst assumes that whichever context filter appears higher on the Filters shelf becomes dependent on the other.
How does Tableau actually establish the data used by the Customer Name Top filter?
- It applies only the higher context filter, then treats the lower context filter as an ordinary dimension filter.
- It applies Region first because geographic filters always precede date filters in Tableau's order of operations.
- It uses the intersection of the Year and Region context filters before evaluating the customer Top filter. (correct answer)
- It evaluates the customer Top filter first, then applies both context filters to the resulting customer list.
Explanation: When you see a question about Tableau's filter order of operations, the key concept to anchor yourself to is how context filters work as a group — not as a hierarchy among themselves.
Context filters in Tableau work together to define a temporary, reduced dataset — essentially a virtual table — before any downstream filters are evaluated. When you place both Year and Region in context, Tableau intersects them simultaneously: it carves out rows matching the current year and the West region. Only after that combined dataset is established does Tableau evaluate the Customer Name Top filter against it. This is exactly what C describes, and it's the correct answer.
A is wrong because it implies a parent-child dependency between context filters, where one subordinates the other. Tableau treats all context filters as peers — they all run together at the same priority level to build one unified context dataset. The order they appear on the Filters shelf is irrelevant to how they interact with each other.
B introduces a rule about geographic filters preceding date filters that simply doesn't exist in Tableau. Tableau has no built-in logic that prioritizes filter types by their dimension category. This is a fabricated hierarchy designed to sound plausible.
D reverses Tableau's actual order of operations. The Top filter on Customer Name is a dimension filter, which always runs after context is established — never before it.
A useful reminder: think of context filters as building a "sandbox" together. All context filters fill the sandbox simultaneously, and every other filter plays inside it.
Question 12
A worksheet filters Customer Name using the condition that total Sales must exceed a specified threshold. A Category filter is also present. The current result includes customers whose companywide sales exceed the threshold even when their sales in the selected category do not.
How should the analyst make the customer condition evaluate using only sales from the selected category?
- Make Customer Name a context filter and leave Category as an ordinary dependent dimension filter.
- Make Category a context filter and leave the conditional Customer Name filter dependent on it. (correct answer)
- Convert the Category filter to a table-calculation filter and evaluate it after Customer Name.
- Place Category above Customer Name on the Filters shelf without changing either filter type.
Explanation: Whenever you see a question about filters producing unexpected results — especially when a condition seems to ignore another active filter — you should immediately think about Tableau's filter order of operations and the role of context filters.
By default, Tableau evaluates dimension filters independently against the full dataset. This means the conditional Customer Name filter (Sales > threshold) checks each customer's total sales across all categories, completely ignoring the Category filter. To force the Customer Name condition to see only the filtered category's data, you need to make Category a context filter. Context filters run first, creating a temporary reduced dataset that all subsequent filters evaluate against. Once Category is promoted to context, the conditional Customer Name filter calculates its Sales total using only records that passed the category filter — which is exactly the behavior you want. Answer B is correct.
Answer A gets the relationship backwards. Making Customer Name a context filter doesn't help; you need Category to run first so it constrains the data before the customer condition is evaluated. Swapping which filter is in context reverses the dependency entirely.
Answer C misapplies table-calculation filters. Table-calc filters operate at the end of Tableau's pipeline, after aggregation, and are used to hide marks post-computation — not to restrict what data feeds into a conditional filter like this one.
Answer D is a common misconception: simply reordering filters on the Filters shelf has no effect on evaluation order. Tableau doesn't process regular dimension filters sequentially based on shelf position.
Study tip: Memorize this rule — to make Filter B's condition respect Filter A's selection, promote Filter A to context. "Context first, dependents follow."
Question 13
A worksheet displays the ten customers with the highest Sales. It also has a Region filter. When a user selects East, Tableau displays customers who are among the top ten companywide and also belong to East. The requirement is to display the ten highest-sales customers within East.
Which change most directly produces the required result?
- Add the Region filter to context so the customer Top filter is evaluated from East-region rows. (correct answer)
- Add the customer Top filter to context so the Region filter is evaluated from the ten selected customers.
- Convert the Region filter to a measure filter so it is evaluated after the customer Top filter.
- Sort customers by Sales after filtering Region, while leaving both filters outside the context.
Explanation: Whenever you see a question about Tableau filters producing unexpected results, think about filter order of operations. By default, Tableau evaluates dimension filters (like a Top N filter and a Region filter) at the same level — meaning they act on the full dataset simultaneously. This causes the problem described: the Top 10 filter finds the ten best customers company-wide, then Region trims that list rather than recomputing it within East.
The fix is context filters. When you add a filter to context, Tableau pre-processes that filter first, creating a temporary "reduced" dataset. All other filters then run against that smaller result. So if you add the Region filter to context (choice A), Tableau first isolates only East-region rows, then evaluates the Top 10 customer filter against that East-only pool — giving you exactly the ten highest-sales customers within East. That's the most direct and intended solution.
Choice B reverses the logic entirely. Adding the Top filter to context means Tableau identifies the top ten customers company-wide first, then applies the Region filter to those ten — which is exactly the broken behavior you're trying to fix, not a solution.
Choice C is a misconception about filter types. Measure filters affect aggregated values and don't solve evaluation-order problems for dimension-based top filters. Converting Region to a measure filter doesn't make it a pre-filter; it would actually place it later in the order of operations, making things worse.
Choice D is simply incorrect — sorting has no effect on which rows are included in a filtered result.
Study tip: Remember the phrase "context = first." Whatever goes into context runs before everything else, so always ask yourself which filter needs to define the universe for the others.
Question 14
A dashboard has Country and City filter controls. The City filter is configured to show only relevant values. The designer wants the City list to be based on the selected Country before other dependent worksheet filters are evaluated.
Which configuration most clearly establishes the intended filter hierarchy?
- Add both fields to context and place City above Country on the Filters shelf.
- Add City to context and keep Country as a dependent filter showing all database values.
- Add Country to context and keep City as a dependent filter showing only relevant values. (correct answer)
- Leave both as ordinary filters and sort the City values by their associated Country names.
Explanation: When you see a question about filter hierarchies in Tableau, think about the context filter concept: any filter added to context is evaluated first, before regular filters, and "only relevant values" filters depend on what context has already established.
The designer's goal is clear — the Country selection should narrow the City list before other worksheet filters run. This is exactly what context filters are designed to do. By adding Country to context and leaving City as a dependent filter set to "only relevant values," City automatically restricts its list based on whichever Country is already locked in by context. That's why C is correct — it precisely mirrors the intended evaluation order: Country resolves first (context), then City filters against that result.
A gets the mechanics backwards. Placing City above Country on the Filters shelf doesn't override evaluation order the way context does — shelf position alone doesn't establish a true dependency hierarchy. Also, adding both to context means they evaluate together, eliminating the dependency relationship you need.
B inverts the logic entirely. Adding City to context and leaving Country as a dependent filter means City would be evaluated first, which is the opposite of what the designer wants. Country would then have no upstream anchor.
D is a red herring. Sorting City values by their associated Country name is a display formatting choice, not a filtering hierarchy. It changes how values appear, not which values are included.
Your study tip: whenever a question describes one filter that should "drive" another, that driving filter belongs in context. Think of context as a pre-filter that runs before everything else.
Question 15
A data source filter permanently excludes archived records from a workbook. On one worksheet, Status is then added as a context filter. A developer expects the context filter to make some archived records available when a particular status is selected.
What will happen when Tableau evaluates these filters?
- The context filter can restore archived records because worksheet context takes precedence over data source filters.
- The data source filter removes archived records first, so the context can use only the remaining records. (correct answer)
- The two filters are combined only after aggregation, allowing archived records to affect intermediate totals.
- The filters cancel each other when they reference related fields, leaving the full data source available.
Explanation: Whenever you see a question about Tableau filters, think in terms of the order of operations: Tableau applies filters in a strict sequence, and where a filter sits in that hierarchy determines what data is available to every filter that comes after it.
Data source filters sit at the very top of Tableau's filter order — they execute before extract filters, context filters, dimension filters, and measure filters. This means a data source filter acts like a gate that permanently removes records from consideration before anything else runs. In this scenario, archived records are eliminated at the data source level, so by the time Tableau even evaluates the context filter on Status, those records simply don't exist in the pipeline. The context filter can only slice and dice whatever survived the data source filter — and archived records didn't. Answer B captures this exactly: the data source filter runs first, and the context filter inherits only the remaining records.
Answer A is backwards. Context filters do sit above most worksheet-level filters, but they are still subordinate to data source filters — not above them. Answer C introduces a fabricated rule; filters in Tableau are never held until after aggregation and then combined — that's not how the filter pipeline works at any stage. Answer D describes a kind of filter-collision behavior that doesn't exist in Tableau; filters on related fields don't cancel each other out or unlock the full dataset.
A useful mental model: picture Tableau's filter order as a funnel. Data source filters are the narrowest point at the top — whatever they cut is gone for good. Study this hierarchy explicitly, because exam questions frequently test whether you know which filter type "wins."