- What benchmark does the EXCLUDE expression return after the filter?
Answer: Category sales for East only, because the ordinary dimension filter is applied before the EXCLUDE expression is evaluated.
When you see a question involving Tableau's Level of Detail (LOD) expressions, the critical concept to master is filter order of operations. Tableau processes calculations and filters in a specific sequence: ordinary dimension filters (context filters aside) are applied before FIXED LOD expressions but after INCLUDE and EXCLUDE LOD expressions — wait, actually the key distinction here is that EXCLUDE and INCLUDE LOD expressions are evaluated after dimension filters, meaning dimension filters do affect them.
This is exactly what makes A correct. An ordinary dimension filter on Region (filtering to East) is applied before the EXCLUDE expression is evaluated. So when { EXCLUDE [Region] : SUM([Sales]) } runs, it only sees the data that passed through the filter — East's data. It then removes Region from the aggregation level, giving you sales summed across all Categories within East. The result is a per-category benchmark scoped to East, not the entire company.
B is the most tempting distractor and represents a common misconception — that EXCLUDE "ignores" filters the way FIXED does. FIXED LOD expressions ignore ordinary dimension filters; EXCLUDE and INCLUDE do not. C misreads what EXCLUDE does: removing Region from the LOD doesn't collapse Category, it simply aggregates across regions at the Category level. D incorrectly attributes FIXED-like behavior to any LOD expression without explicitly using FIXED syntax, which is wrong.
Your study tip: memorize the LOD filter hierarchy — FIXED > ordinary dimension filters > INCLUDE/EXCLUDE. FIXED sits above dimension filters; INCLUDE and EXCLUDE sit below them. That single rule resolves most LOD filter-interaction questions on the exam.
- Which redesign most appropriately gives the two metrics different filter behavior on the same worksheet?
Answer: Keep Segment ordinary, use an INCLUDE LOD for the responsive customer KPI, and retain FIXED for the all-segment benchmark.
When a question asks how to give two metrics different filter sensitivity on the same worksheet, you need to think about how Tableau's LOD hierarchy interacts with filters. The key rule: FIXED expressions ignore dimension filters unless those filters are promoted to context; INCLUDE expressions respect dimension filters naturally without requiring context.
This makes C the right choice. By keeping Segment as an ordinary filter and switching the customer KPI to an INCLUDE LOD, that metric automatically recalculates when the Segment filter changes — INCLUDE aggregates within the current filter context. Meanwhile, the benchmark stays as FIXED, which ignores ordinary dimension filters entirely, so it always reflects all segments. No context filter needed, and the two metrics behave differently by design.
Answer A fails because converting a measure from continuous to discrete changes how it's displayed on shelves, not how it responds to filters. That's a visual formatting change with zero effect on LOD computation.
Answer B promotes Segment to context, which does make FIXED expressions respect the filter — but it applies equally to both FIXED expressions. You'd lose the benchmark's all-segment behavior, which is exactly the problem described in the passage.
Answer D has the logic backwards. Adding Segment to context makes FIXED respect the filter, so the "responsive" metric would already react. Using EXCLUDE Segment on the benchmark is redundant and still won't isolate the two metrics cleanly with context active — EXCLUDE removes a dimension from a finer aggregation, not a filter shield.
Study tip: Memorize the LOD filter hierarchy — context filters affect FIXED, ordinary dimension filters affect INCLUDE/EXCLUDE but not FIXED. When you need selective filter sensitivity, reach for mixed LOD types rather than context filters.
- How should the Category filter be configured?
Answer: Add Category to context so it limits the data used by both the FIXED ranking metric and Top 10 filter.
Whenever you see a question involving FIXED LOD expressions and filters, you need to think carefully about filter order of operations in Tableau. FIXED calculations are computed before dimension filters — meaning a standard Category filter won't restrict the data your FIXED expression sees. This is the core concept being tested here.
Adding Category to context (Answer B) is the correct approach. Context filters execute before LOD expressions, effectively pre-filtering the underlying dataset. Once Category is in context, the { FIXED [Customer Name] : SUM([Sales]) } calculation runs against only the rows matching the selected category, so the Top 10 ranking reflects category-level sales exactly as users expect.
Here's why each distractor fails: A is the classic trap — an ordinary dimension filter sits below FIXED in the order of operations, so the FIXED expression still aggregates across all data companywide before the category restriction is applied. You'd get the top 10 overall customers who happen to sell in that category, not the true top 10 within it. C is a fabricated workflow — there's no "measure filter" mechanism that delays ranking generation in Tableau; measure filters filter on aggregated values but don't reorder execution relative to LOD expressions in the way described. D is a UI display setting ("Show Only Relevant Values") that controls what appears in a filter dropdown — it has absolutely no effect on how or when FIXED calculations are computed.
Study tip: Memorize Tableau's filter order of operations: Extract → Data Source → Context → Sets/LOD → Dimension → Measure. Any time a FIXED LOD must respect a filter, that filter must be promoted to context.
- Which change most directly produces the required result while retaining the existing calculation?
Answer: Add the Region filter to context so it restricts the rows used by the FIXED denominator.
Whenever you see a FIXED LOD expression in Tableau combined with a user filter, ask yourself: at what point in the order of operations does this filter execute relative to the LOD? FIXED expressions compute before standard dimension filters — meaning a Region filter applied normally won't restrict the FIXED denominator, which will always reflect companywide totals. That's exactly the problem described in the passage.
The fix is adding the Region filter to context (Answer A). Context filters execute before FIXED LODs in Tableau's order of operations. Once Region is a context filter, the database effectively treats filtered-out regions as if they don't exist when computing { FIXED : SUM([Sales]) }. So when a user selects East, the denominator becomes East's total sales — making the ratio 100%, which is precisely what the business wants.
Answer B is a trap. "Measure filters" execute after FIXED LODs, so converting Region to a measure filter would have no effect on the denominator at all. Answer C, selecting "Only Relevant Values," controls what appears in the filter dropdown UI — it has nothing to do with the order of operations or how LODs compute. Answer D moves the filter to the data source, which would indeed restrict rows globally, but it would permanently remove non-East data from every worksheet connected to that source — a heavy-handed change that breaks companywide analysis elsewhere, not a targeted fix.
Study tip: Memorize Tableau's order of operations as a hierarchy: Data Source Filters → Context Filters → FIXED LODs → Dimension Filters → Measure Filters. Questions about LOD behavior almost always hinge on where a filter sits in this chain.
- How is the denominator affected by the measure filter?
Answer: It still includes sales from filtered-out states because the FIXED expression is evaluated before the measure filter.
Whenever you see a question mixing LOD expressions with filters, your first instinct should be to recall Tableau's order of operations: dimension filters → FIXED LODs → measure filters. This sequence is the key to unlocking this question.
Because FIXED expressions are evaluated before measure filters, the denominator { FIXED : SUM([Sales]) } locks in the grand total of all states' sales during the LOD computation phase. Only afterward does Tableau apply the measure filter (SUM([Sales]) > threshold), which removes low-sales states from the view — but those states' sales were already baked into the denominator. So the correct answer is D: the denominator still includes filtered-out states, meaning each retained state's share is calculated against the full dataset total, not just the visible states.
A gets the order of operations exactly backwards. Measure filters do not define the input rows for FIXED expressions — they run after FIXED LODs have already been resolved. B introduces a fabricated concept; filtering aggregated marks does not alter the granularity or scoping of a FIXED expression. The expression remains unscoped and grand-total in nature regardless of what marks are visible. C is a plausible-sounding but invented distinction — the continuous vs. discrete nature of a measure filter has no bearing on when LOD expressions are evaluated. Both filter types operate after FIXED LODs.
A reliable study tip: memorize Tableau's order of operations as a hierarchy — dimension filters → LODs → measure filters → table calculations. On exam questions, trace where each filter type sits in that chain, and the effect on LODs becomes predictable.
- Which approach is most appropriate for enforcing the access restriction?
Answer: Use a data source filter or row-level security rule, rather than treating the context filter as security.
Whenever you see a question combining Tableau's Level of Detail expressions with access control, your first instinct should be to separate two distinct concerns: calculation scope and data security. These are not the same thing, and conflating them is exactly the trap this question sets.
FIXED LOD expressions compute at a specified dimension level regardless of view filters. Adding a context filter does push FIXED to respect that filter's exclusions — but only within that worksheet session. A context filter is a UI-level mechanism, not a permission layer. A determined user could remove it, modify the workbook, or access the data source directly. Because compensation data is sensitive, relying on a context filter as your security boundary is fundamentally inadequate. The right approach is enforcing restrictions at the data layer — through a data source filter or row-level security — so the restricted rows are never surfaced to users in the first place, regardless of what filters they add or remove. That's why B is correct.
A is misleading because while context filters do influence FIXED calculations, they are not access controls. Describing them as security is a dangerous oversimplification. C confuses EXCLUDE's purpose — EXCLUDE removes dimensions from the current view's partitioning but has nothing to do with restricting row visibility or enforcing permissions. D is doubly wrong: ordinary filters are evaluated after FIXED, meaning FIXED already computed across all rows before the filter applied, and filters never "permanently mask" data — they are always adjustable by users.
As a study rule: filters control what you see; data source filters and RLS control what you can access. Any security requirement involving sensitive data must live at the data layer, not the worksheet layer.
- Which data contributes to the customer-level values that are averaged in the view?
Answer: Only Consumer rows, because the ordinary Segment filter is applied before the INCLUDE LOD expression is evaluated.
When working with LOD expressions and filters in Tableau, the critical concept is the order of operations: where does each type of filter sit in Tableau's query pipeline relative to LOD expression evaluation?
Ordinary dimension filters — those created by dragging a dimension to the Filters shelf without using context — are applied after fixed and include LOD expressions are computed. However, this is the key insight: INCLUDE LOD expressions are actually computed within the data that has already been filtered by dimension filters. Dimension filters reduce the underlying data before the INCLUDE expression aggregates it. So when Segment is filtered to Consumer, only Consumer rows reach the LOD calculation. The AVG({ INCLUDE [Customer Name] : SUM([Sales]) }) therefore sums Sales only for each customer's Consumer-segment rows, then averages those sums across regions. That makes B correct.
A is wrong because it reverses the order of operations. Ordinary dimension filters do affect INCLUDE LODs — the misconception that LODs are immune to dimension filters applies only to context filters (which INCLUDE LODs can also be made to respect) or fixed LODs under certain configurations, not INCLUDE by default.
C introduces a concept Tableau doesn't enforce. Customers who appear in multiple segments aren't "removed" — they simply contribute only their Consumer-segment rows to the SUM.
D confuses INCLUDE behavior with FIXED behavior. FIXED expressions genuinely disregard dimension filters (unless promoted to context); INCLUDE expressions do not — they respect the view's filter context.
The study tip: memorize the filter hierarchy. Dimension filters sit above INCLUDE and EXCLUDE LODs in execution order, meaning they constrain the data those LODs operate on.
- What does the LOD value represent for the displayed Furniture marks?
Answer: Furniture sales across all states because the context filter is honored and the ordinary State filter is ignored by the LOD.
Whenever you see a question about LOD expressions and filters, your first move should be to mentally rank the filter types: context filters sit above FIXED expressions in Tableau's order of operations, while ordinary dimension filters sit below them.
Here's how that plays out in this scenario. The { FIXED [Category] : SUM([Sales]) } expression aggregates sales by Category. The Category filter has been added to context, meaning it executes before the LOD — so the expression only ever "sees" Furniture rows. The result is Furniture sales computed across all remaining states. The State filter, however, is an ordinary dimension filter, which runs after FIXED expressions. This means State can control which marks are displayed, but it cannot alter the value the LOD already calculated. So the displayed Furniture marks show Furniture sales across all states — confirming C is correct.
A is wrong because it assumes both filters restrict the data before the LOD runs. Only context filters do that; ordinary dimension filters apply afterward and don't influence the LOD's computed value.
B is wrong on two counts: the State filter doesn't override the Category dimension in the expression, and it doesn't cause the LOD to aggregate across all categories. The FIXED clause explicitly locks computation to Category.
D is wrong because it overstates FIXED's independence. FIXED expressions do not ignore context filters — that's precisely the point of promoting a filter to context.
A reliable rule of thumb: context filters shrink the data before FIXED runs; ordinary dimension filters only hide marks after FIXED is done.
- For a mixed-segment customer still visible after filtering, which sales are included in the FIXED value?
Answer: The customer's East, 2025 sales from all segments, because both context filters precede FIXED but Segment does not.
Whenever you see a FIXED LOD expression combined with filters, your first move should be to mentally sort every filter into one of three tiers: context filters (run before FIXED), FIXED itself, and dimension filters (run after FIXED). The order of these tiers determines exactly which rows feed into the LOD calculation.
In this scenario, Region (East) and Year (2025) are both promoted to context filters, so they execute before { FIXED [Customer Name] : SUM([Sales]) } is evaluated. That means the LOD sees only rows where Region = East and Year = 2025 — but it sees all segments within that universe, because Segment is an ordinary dimension filter sitting after FIXED in the order of operations. The FIXED expression therefore aggregates each customer's sales across Consumer and Corporate, as long as those rows are East and 2025. D captures this precisely: both context filters constrain the data FIXED sees, but Segment does not.
A is wrong because it assumes Segment also precedes FIXED — it doesn't. Ordinary dimension filters are applied after the LOD resolves, so they cannot restrict what the LOD computes. B is wrong on two counts: it incorrectly dismisses the Region context filter and invents a nonsensical rule about one filter "replacing" another. C is wrong because it implies only one context filter matters; in reality, all context filters collectively scope the data before FIXED runs, so both Region and Year constrain it.
Your study tip: memorize the filter order of operations — Extract → Data Source → Context → Sets/Conditions → FIXED LODs → INCLUDE/EXCLUDE LODs → Dimension Filters → Measure Filters. Questions like this are essentially asking you to locate each filter in that chain.
- Which filter configuration best preserves that requirement?
Answer: Keep the date filter as an ordinary dimension filter so the FIXED maximum is computed before that filter.
Whenever you see a question about Tableau's order of operations, picture the filter pipeline: context filters → data source filters → extract filters → FIXED LOD expressions → dimension filters → measure filters. The position of your date filter in that pipeline determines whether a FIXED calculation "sees" filtered or unfiltered data.
Because { FIXED : MAX([Order Date]) } is a FIXED LOD expression, it executes before ordinary dimension filters in Tableau's order of operations. That means if you leave the date filter as a standard dimension filter — which is exactly what answer A recommends — the FIXED expression runs against the full dataset first, locking in the true maximum date, and only then does the dimension filter trim the view to your reporting window. The calculated field stays anchored to the full data regardless of what the worksheet displays. A is correct.
Answer B is a trap: adding the date filter to context promotes it above FIXED LODs in the pipeline, so the FIXED expression now computes after that context filter, meaning it will only see dates within the reporting window — the opposite of what you want.
Answer C is wrong for the same directional reason but in reverse: measure filters sit below FIXED LODs, so converting the filter there wouldn't constrain the FIXED calculation at all, but it also isn't the mechanism you'd use to control LOD scope and introduces unnecessary complexity.
Answer D misidentifies INCLUDE as a solution. INCLUDE LODs respect dimension filters, so swapping FIXED for INCLUDE would actually make the result more sensitive to filtering, not less.
The key study tip: memorize Tableau's order of operations as a vertical pipeline. When a question asks whether a LOD calculation is "protected" from a filter, your first move is to locate both the LOD type and the filter type on that pipeline and check which comes first.
