Tableau Quiz: Lod And Filters
10 questions · exam conditions
0:00
Lod And FiltersQuestion 1 of 10

A workbook contains { FIXED [Employee ID] : SUM([Compensation]) }. A worksheet-level Department filter is added to context so the calculation only includes the selected department. The workbook will be distributed to users who must not be able to access compensation from other departments.

Which approach is most appropriate for enforcing the access restriction?

Rely on the context filter because FIXED expressions cannot access rows excluded from that worksheet's context.
Use a data source filter or row-level security rule, rather than treating the context filter as security.
Change the calculation to EXCLUDE because EXCLUDE expressions prevent users from viewing filtered department rows.
Use an ordinary Department filter because it is evaluated after FIXED and therefore permanently masks excluded rows.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Lod And Filters

Practice Lod And Filters 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 Lod And Filters, 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 workbook contains { FIXED [Employee ID] : SUM([Compensation]) }. A worksheet-level Department filter is added to context so the calculation only includes the selected department. The workbook will be distributed to users who must not be able to access compensation from other departments.

Which approach is most appropriate for enforcing the access restriction?

  1. Rely on the context filter because FIXED expressions cannot access rows excluded from that worksheet's context.
  2. Use a data source filter or row-level security rule, rather than treating the context filter as security. (correct answer)
  3. Change the calculation to EXCLUDE because EXCLUDE expressions prevent users from viewing filtered department rows.
  4. Use an ordinary Department filter because it is evaluated after FIXED and therefore permanently masks excluded rows.
Explanation: 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.

Question 2

A worksheet uses { FIXED [Customer Name] : SUM([Sales]) }. Region is filtered to East and Year is filtered to 2025; both filters are in context. Segment is an ordinary dimension filter set to Consumer. Some customers bought in both Consumer and Corporate during 2025.

For a mixed-segment customer still visible after filtering, which sales are included in the FIXED value?

  1. The customer's East, 2025 Consumer sales only, because all three filters precede the FIXED calculation.
  2. The customer's 2025 Consumer sales from every region, because Segment replaces the Region context filter.
  3. The customer's East sales from every year and segment, because only the first context filter affects FIXED.
  4. The customer's East, 2025 sales from all segments, because both context filters precede FIXED but Segment does not. (correct answer)
Explanation: 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.

Question 3

A worksheet applies a Top 10 Customer filter ranked by { FIXED [Customer Name] : SUM([Sales]) }. It also has a Category filter. Users expect the Top 10 list to show customers with the highest sales within the selected category, not the highest companywide customers who happened to buy in that category.

How should the Category filter be configured?

  1. Keep Category as an ordinary dimension filter so it executes simultaneously with the Top 10 filter.
  2. Add Category to context so it limits the data used by both the FIXED ranking metric and Top 10 filter. (correct answer)
  3. Convert Category to a measure filter so customer sales are aggregated only after the Top 10 list is generated.
  4. Show Only Relevant Values for Category so the FIXED calculation automatically adopts the selected category.
Explanation: 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.

Question 4

An analyst defines [Data Max Date] as { FIXED : MAX([Order Date]) }. A worksheet also has a date filter that retains a recent reporting window. The analyst wants [Data Max Date] to remain the latest date in the full data set, even when the worksheet displays only the reporting window.

Which filter configuration best preserves that requirement?

  1. Keep the date filter as an ordinary dimension filter so the FIXED maximum is computed before that filter. (correct answer)
  2. Add the date filter to context so the FIXED maximum reflects only the reporting window's date range.
  3. Convert the date filter to a measure filter so the FIXED maximum is constrained to the visible marks only.
  4. Replace the FIXED expression with INCLUDE so the maximum still spans the full data regardless of dimension filters.
Explanation: 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.

Question 5

A worksheet contains { FIXED [Category] : SUM([Sales]) }. Category is filtered to Furniture and added to context. State remains an ordinary dimension filter and is set to California.

What does the LOD value represent for the displayed Furniture marks?

  1. Furniture sales in California because both filters limit the rows before the FIXED expression runs.
  2. All-category sales in California because the State filter overrides the Category dimension in the expression.
  3. Furniture sales across all states because the context filter is honored and the ordinary State filter is ignored by the LOD. (correct answer)
  4. Companywide sales across all categories and states because FIXED expressions ignore every worksheet filter.
Explanation: 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.

Question 6

A state-level view calculates each state's share as SUM([Sales]) / { FIXED : SUM([Sales]) }. A measure filter retains only states whose SUM([Sales]) exceeds a specified threshold. Several low-sales states disappear from the view.

How is the denominator affected by the measure filter?

  1. It is recalculated from only the retained states because measure filters define the FIXED expression's input rows.
  2. It becomes a state-level total because filtering aggregated marks changes an unscoped FIXED expression's granularity.
  3. It includes only retained states when the measure filter is continuous, but includes all states when it is discrete.
  4. It still includes sales from filtered-out states because the FIXED expression is evaluated before the measure filter. (correct answer)
Explanation: 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.

Question 7

A view contains Region and Category and uses { EXCLUDE [Region] : SUM([Sales]) } to display a category benchmark. Region is then filtered to East using an ordinary dimension filter.

What benchmark does the EXCLUDE expression return after the filter?

  1. Category sales for East only, because the ordinary dimension filter is applied before the EXCLUDE expression is evaluated. (correct answer)
  2. Category sales across all regions, because EXCLUDE removes Region from the aggregation level, causing regional filters to be disregarded.
  3. Total East sales across all categories, because EXCLUDE removes Region from the view's level of detail and collapses Category.
  4. Companywide sales across all categories, because an EXCLUDE expression without a FIXED scope always aggregates over the full underlying table.
Explanation: 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.

Question 8

A worksheet displays sales by Region and uses SUM([Sales]) / { FIXED : SUM([Sales]) } to calculate each region's share of sales. When a user selects East in a Region filter, the business wants the East mark to display 100 percent rather than its share of companywide sales.

Which change most directly produces the required result while retaining the existing calculation?

  1. Add the Region filter to context so it restricts the rows used by the FIXED denominator. (correct answer)
  2. Convert the Region filter to a measure filter so it executes before the FIXED denominator.
  3. Keep Region as a standard dimension filter and select Only Relevant Values for the filter.
  4. Move the Region filter to the data source so the denominator remains companywide in the worksheet.
Explanation: 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.

Question 9

A dashboard has a Segment filter and two metrics. A customer-level KPI should recalculate for the selected segment, while a company benchmark must remain based on all segments. Both metrics are currently FIXED LOD expressions. Making Segment a context filter changes both metrics; leaving it ordinary changes neither metric.

Which redesign most appropriately gives the two metrics different filter behavior on the same worksheet?

  1. Keep Segment ordinary, retain both FIXED expressions, and convert the benchmark measure from continuous to discrete.
  2. Add Segment to context, retain both FIXED expressions, and set the benchmark filter card to Only Relevant Values.
  3. Keep Segment ordinary, use an INCLUDE LOD for the responsive customer KPI, and retain FIXED for the all-segment benchmark. (correct answer)
  4. Add Segment to context, replace the benchmark with EXCLUDE Segment, and retain FIXED for the responsive customer KPI.
Explanation: 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.

Question 10

A view shows Region and evaluates AVG({ INCLUDE [Customer Name] : SUM([Sales]) }). Segment is placed on Filters as an ordinary dimension filter, and the user selects Consumer.

Which data contributes to the customer-level values that are averaged in the view?

  1. All segment rows for each customer, because INCLUDE LOD expressions are evaluated before ordinary dimension filters.
  2. Only Consumer rows, because the ordinary Segment filter is applied before the INCLUDE LOD expression is evaluated. (correct answer)
  3. Only customers assigned exclusively to Consumer, because mixed-segment customers are removed from the LOD domain.
  4. All segment rows in each region, because INCLUDE expressions disregard filters on dimensions not present in the view.
Explanation: 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.