Tableau Quiz: Performance Optimization
10 questions · exam conditions
0:00
Performance OptimizationQuestion 1 of 10

A five-year transaction extract is too large. All approved dashboards analyze results by calendar month or higher, but a workbook author occasionally uses an exact transaction date as a filter. The team proposes rolling dates up to the month level when aggregating the extract.

What is the most important consequence to evaluate before applying the proposed optimization?

Monthly and yearly views will stop working because Tableau extracts require transaction-level dates for time-series analysis.
Exact-day filtering will no longer be supported because the aggregation removes the original daily date detail.
Monthly totals will become inaccurate because Tableau cannot sum measures after dates have been rolled up.
Extract refreshes will become live queries because date rollups disable stored data in the extract.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Performance Optimization

Practice Performance Optimization 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 Performance Optimization, 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 five-year transaction extract is too large. All approved dashboards analyze results by calendar month or higher, but a workbook author occasionally uses an exact transaction date as a filter. The team proposes rolling dates up to the month level when aggregating the extract.

What is the most important consequence to evaluate before applying the proposed optimization?

  1. Monthly and yearly views will stop working because Tableau extracts require transaction-level dates for time-series analysis.
  2. Exact-day filtering will no longer be supported because the aggregation removes the original daily date detail. (correct answer)
  3. Monthly totals will become inaccurate because Tableau cannot sum measures after dates have been rolled up.
  4. Extract refreshes will become live queries because date rollups disable stored data in the extract.
Explanation: When a question asks about consequences of aggregating an extract, you should focus on what data disappears during that process — because once detail is removed from an extract, Tableau cannot reconstruct it. Rolling transaction dates up to the month level means the extract stores only a single date per month (e.g., 2024-01-01 to represent all of January). The original daily timestamps are gone. So if a workbook author tries to filter on an exact date — say, January 15th — that value simply doesn't exist in the extract anymore. The filter will return no results or behave unexpectedly. This is precisely why B is the most important consequence to evaluate before applying the change: the team has already acknowledged that at least one author uses exact transaction dates as filters, and this optimization would silently break that workflow. A is incorrect because rolling up dates does not break monthly or yearly views — those aggregations work at a higher granularity than the stored month-level dates, so they remain fully functional. C is incorrect because Tableau can absolutely sum measures after dates have been rolled up; aggregation affects granularity, not mathematical operations on numeric fields. D is incorrect because date rollups have no effect on how the extract stores data — the extract remains a static, stored file and does not revert to live queries under any circumstance. A good rule of thumb: whenever you see an extract optimization question, ask yourself "what detail level is being removed, and who currently depends on that detail?" The passage even hints at the answer by mentioning the author's exact-date filter habit — that's your signal to focus on B.

Question 2

A sales dashboard uses a live connection to a cloud data warehouse. Opening the dashboard triggers several queries, and network latency accounts for most of the load time. Sales data is finalized overnight, and users do not require changes made during the current day.

Which change is most likely to improve performance while still meeting the stated freshness requirement?

  1. Create a Tableau extract, schedule a refresh after the nightly load, and direct the dashboard to the extract. (correct answer)
  2. Keep the live connection, add a relative-date filter, and rely on the warehouse to cache each query.
  3. Create an extract that refreshes whenever a user opens the workbook, ensuring that each session begins with current data.
  4. Keep the live connection, aggregate every worksheet to yearly values, and remove all dashboard-level filters.
Explanation: When a question describes network latency as the primary bottleneck and states that data only needs to be current as of the previous night, you should immediately think about extracts versus live connections. The core trade-off is: live connections send queries across the network every time, while extracts store a local snapshot that Tableau can query without that round-trip cost. Option A solves both problems cleanly. A Tableau extract (a .hyper file) is stored and queried locally, eliminating the network latency entirely. Scheduling the refresh to run after the nightly data load means users always see yesterday's finalized data — exactly what the requirement specifies. Fast performance and appropriate freshness, achieved together. Option B keeps the live connection, which means every dashboard load still suffers from the same network latency. Warehouse-level caching helps in some scenarios, but it's unreliable and outside Tableau's control — and it doesn't address the root cause the passage identifies. Option C creates an extract but refreshes it on every workbook open. This is counterproductive: it reintroduces query overhead at open time, potentially making load times worse, and provides no benefit over the live connection since users don't need intra-day freshness anyway. Option D keeps the live connection and reduces query complexity by aggregating to yearly values. While simpler queries do run faster, the network latency — the stated bottleneck — remains unchanged. Aggregating to yearly granularity also likely destroys the dashboard's analytical value without fully solving the problem. For the exam, remember this pattern: latency problem + overnight freshness requirement = extract with scheduled refresh. When you see those two signals together, A-type solutions are almost always correct.

Question 3

A large extract is refreshed incrementally using Transaction ID as the key. New transactions are appended daily, but the source system also corrects amounts on existing transactions and occasionally deletes canceled transactions. The dashboard must reflect all corrections by Monday morning.

Which refresh strategy best balances refresh performance with the stated accuracy requirement?

  1. Run incremental refreshes during the week and schedule a full refresh before Monday reporting begins. (correct answer)
  2. Run only incremental refreshes because the key causes changed and deleted rows to be replaced automatically.
  3. Run only full refreshes after every new transaction because extracts cannot append newly created source rows.
  4. Aggregate the extract by week and use incremental refreshes because aggregation automatically removes corrected rows.
Explanation: When working with Tableau extracts, the core question is always: what kinds of changes happen in the source data, and can your refresh strategy capture all of them? Incremental refreshes only append rows where the key field value is new — they do not detect modifications to existing rows or deletions. That distinction is what makes this scenario tricky. The scenario describes three types of changes: new transactions (appended daily), corrections to existing amounts (updates), and cancellation deletions. Incremental refresh handles only the first type. To capture updates and deletes, a full refresh is required. Answer A is the best strategy because it uses incremental refreshes throughout the week for efficiency — capturing new rows quickly — while scheduling a full refresh before Monday reporting. This ensures all corrections and deletions are reflected by the deadline without running expensive full refreshes every single day. Answer B is the most tempting trap. Incremental refresh does not replace corrected or deleted rows just because a key field is defined. The key only tells Tableau which rows are "new" — existing rows with the same key are ignored entirely, not re-evaluated. Answer C misrepresents how incremental refresh works in the opposite direction — claiming extracts cannot append new rows, which is false. Incremental refresh exists precisely to append new rows efficiently. Answer D introduces a dangerous misconception: pre-aggregating data doesn't magically resolve incorrect source values. If the underlying transactions are wrong, aggregating them just bakes the errors into the extract at a higher level. A reliable study tip: whenever you see "incremental refresh," ask yourself whether the scenario involves only inserts, or also updates and deletes. If it's the latter, a periodic full refresh is non-negotiable.

Question 4

A data source contains 400 million transaction rows and 120 columns. The published workbook uses 18 columns and reports only by Region, Product Line, and Month. No worksheet requires transaction-level drill-down.

Which extract design should generally provide the greatest reduction in stored data while preserving the workbook's stated analyses?

  1. Retain every column and transaction row, but convert the connection from live to an unfiltered extract.
  2. Retain the 18 used columns and transaction rows, but sort the extract by Region before publishing it.
  3. Retain the used fields and aggregate rows to Region, Product Line, and Month before publishing the extract. (correct answer)
  4. Retain all dimensions, aggregate only by Month, and recreate Region and Product Line from measure values.
Explanation: When designing a Tableau extract for maximum size reduction, your goal is to eliminate every row and column the workbook doesn't actually need. The two levers you have are column pruning (removing unused fields) and row aggregation (pre-summarizing data when no drill-down is required). Questions like this test whether you understand both levers and know when to apply them together. Option C is the strongest choice because it applies both levers simultaneously. Since the workbook only analyzes by Region, Product Line, and Month — and never needs transaction-level detail — you can safely aggregate all 400 million rows down to, at most, a few thousand distinct Region × Product Line × Month combinations. Combine that with keeping only the 18 used columns instead of all 120, and you've achieved the maximum possible reduction in stored data without losing any analytical capability the workbook actually uses. Option A converts the connection to an extract but retains all 400 million rows and all 120 columns — essentially trading a live query for a bloated local file. You've gained scheduling flexibility but almost no storage savings. Option B is a partial improvement: dropping unused columns helps, but keeping every transaction row leaves the extract enormous. Sorting by Region has zero effect on file size. Option D introduces unnecessary complexity — recreating dimensions from measure values is error-prone and doesn't address the fundamental problem of keeping all dimensions and only partially aggregating, leaving far more rows than Option C would. A useful rule of thumb: if no worksheet needs row-level detail, aggregating the extract is almost always the right answer. Always ask yourself, "What is the lowest grain this workbook actually needs?"

Question 5

One published data source supports two dashboards. The executive dashboard needs monthly totals by Region. The operations dashboard needs daily totals by Store, and each Store belongs to one Region. Both dashboards currently use the same transaction-level extract.

If the team wants one aggregated extract to support both dashboards, what is the coarsest safe aggregation grain?

  1. Region and Month, because the executive dashboard has the least detailed reporting requirement.
  2. Store and Day, because Region and Month can be derived by rolling up the more detailed values. (correct answer)
  3. Region and Day, because Store can be recovered from the Region assigned to each transaction.
  4. Store and Month, because daily values can be allocated evenly across the days in each month.
Explanation: When designing a shared extract, the guiding principle is information preservation: you must retain enough granularity so that every consumer can derive exactly what they need. Aggregating too coarsely destroys data permanently — you can always roll up finer data, but you can never reconstruct detail from a summary. Here, the operations dashboard needs daily totals by Store, while the executive dashboard needs monthly totals by Region. The question is: what's the coarsest grain that satisfies both? Store-and-Day is the answer (B), because Region is simply a grouping of Stores and Month is simply a grouping of Days. Both higher-level summaries can be computed by rolling up — grouping Store → Region and Day → Month — without any loss of accuracy. Choice A fails because Region-and-Month satisfies only the executive dashboard. Once you collapse to that grain, the Store-level and Day-level detail needed by operations is gone forever — you cannot disaggregate a regional monthly total back into individual stores or individual days. Choice C (Region and Day) is subtler but still wrong. Knowing a transaction belongs to a Region doesn't tell you which Store within that Region it came from. Store identity is irretrievably lost at Region-level aggregation, so the operations dashboard breaks. Choice D (Store and Month) sounds like a compromise, but it destroys daily granularity. You cannot reliably reconstruct daily totals from a monthly figure — "allocating evenly" is an assumption, not a derivation, and it would produce fabricated data. Study tip: When evaluating aggregation grain, always anchor to the most granular requirement across all consumers. That grain is your safe floor — anything coarser risks destroying irreplaceable detail.

Question 6

An extract is aggregated to one row per Store and Month. It stores summed Sales and summed Quantity. Each order belongs to exactly one month, but customers can purchase in multiple stores and months.

Which new analysis can be derived reliably from the aggregated extract without returning to order-level data?

  1. Annual average selling price by Store, calculated as total Sales divided by total Quantity. (correct answer)
  2. Annual distinct customer count by Store, calculated by adding the monthly customer counts.
  3. Median order value by Store, calculated from the stored monthly Sales totals.
  4. Percentage of orders with a discount by Store, calculated from the stored monthly Quantity totals.
Explanation: When working with pre-aggregated extracts, the core question to ask is: does the calculation I need require data that was preserved during aggregation, or was it lost? Additive measures — like sums — survive aggregation intact. Non-additive measures — like counts of distinct values, medians, or conditional percentages — generally do not. This is precisely what this question tests. The extract stores summed Sales and summed Quantity per Store per Month. Answer A asks for annual average selling price, calculated as ASP=∑Sales∑Quantity\text{ASP} = \frac{\sum \text{Sales}}{\sum \text{Quantity}}. Both components are preserved in the extract, so you can simply sum Sales across all months for a Store and divide by the summed Quantity — no order-level data needed. This makes A the reliable derivation. Answer B fails because distinct customer counts are non-additive. A customer who shopped in January and February would be counted twice if you summed the monthly customer counts, inflating the annual total. You'd need the original order-level data to deduplicate. Answer C requires knowing the distribution of individual order values — not just their monthly totals. A median cannot be reconstructed from aggregated sums; you need the underlying values to find the middle point. Answer D asks about the percentage of orders with a discount, but the extract stores no information about discounts at all — neither discounted order counts nor flags. This information was never captured, so it cannot be derived regardless of how you manipulate Quantity. Study tip: Whenever you evaluate an aggregated source, mentally categorize each needed metric as additive (safe to aggregate) or non-additive (requires row-level data). Sums are additive; distinct counts, medians, and conditional percentages are not.

Question 7

A dashboard already uses an extract aggregated to the level required by its worksheets. Performance recording shows that queries return quickly, but one worksheet displays several hundred thousand marks and takes most of the remaining time to render.

Which conclusion about further extract optimization is most appropriate?

  1. Replacing the extract with a live connection should reduce rendering time because the database will draw the marks.
  2. Refreshing the extract more frequently should reduce rendering time by keeping the stored rows physically ordered.
  3. Adding more dimensions to the extract aggregation should reduce rendering time by increasing the number of stored groups.
  4. The main issue is now the number of marks, so reducing displayed detail is more promising than changing connection type. (correct answer)
Explanation: When diagnosing dashboard slowness in Tableau, you need to distinguish between two separate performance stages: query time (how long it takes to retrieve data) and render time (how long Tableau's rendering engine takes to draw marks on screen). The passage explicitly tells you queries are already fast, so the bottleneck has shifted entirely to rendering. Since the extract is already aggregated correctly and queries are snappy, further extract changes won't meaningfully address a rendering problem. The rendering engine works independently of connection type or extract structure — it simply has to paint marks on screen, and hundreds of thousands of marks is a heavy load regardless of where the data comes from. The most effective fix is therefore reducing the number of marks displayed, whether by filtering, aggregating further in the viz, or changing the chart type. That's exactly what D captures. A is wrong because switching to a live connection doesn't offload rendering to the database — Tableau's client still draws every mark locally. Live connections typically increase query time, not decrease render time. B is wrong because refresh frequency controls data freshness, not physical row ordering, and neither concept has any bearing on how quickly marks are rendered after the data is already retrieved. C is wrong because adding more dimensions to aggregation produces more stored groups, which would likely increase the number of marks and worsen the rendering problem — the opposite of what you want. As a study strategy, remember that Tableau performance questions often hinge on correctly identifying which stage of the pipeline is the bottleneck. If queries are fast, look to rendering; if rendering is slow, look to mark count first.

Question 8

An order-level extract is aggregated to one row for each combination of Region, Product Category, and Month. The original extract included Customer ID and Order ID, but neither field is retained in the aggregated extract.

Which proposed worksheet cannot be supported accurately by this aggregated extract?

  1. Annual sales by Region, calculated by summing the monthly sales values across all product categories.
  2. Monthly sales by Product Category, filtered to a selected Region and displayed as a trend.
  3. Distinct customers by Region and Month, calculated from the customers who placed qualifying orders. (correct answer)
  4. Quarterly sales by Region and Product Category, calculated by combining the applicable monthly values.
Explanation: When working with aggregated extracts, the key question to ask yourself is: what information was permanently lost during aggregation? If a calculation requires granular, row-level data that no longer exists in the extract, that worksheet simply cannot be built accurately. This extract collapsed data to one row per Region + Product Category + Month combination, and critically, Customer ID was discarded in the process. That's the heart of this question. Answer C asks for distinct customer counts by Region and Month — a calculation that requires knowing which individual customers placed orders. Because Customer ID no longer exists anywhere in the extract, there is no way to count unique customers or deduplicate them. You can't reconstruct who the customers were from aggregated sales totals alone. C is the worksheet that cannot be supported. A is achievable because you can sum the pre-aggregated monthly sales values across product categories to arrive at annual regional totals — the sales measure itself was retained. B is similarly fine: monthly sales by Product Category filtered to a Region is exactly the grain the extract was built on, so a trend line presents no problem. D works too, because quarterly figures are just the sum of their constituent monthly values (e.g., January + February + March = Q1), and both Month and Product Category dimensions are preserved. The practical study tip here: whenever you see a question about extract limitations, immediately identify what dimensions or measures were dropped during aggregation. If a requested calculation depends on a discarded field — especially a granular ID like Customer ID or Order ID — that worksheet is the one that fails.

Question 9

A team plans to reduce extract size by including only the last 24 months of transactions and then aggregating the retained rows by Product, Region, and Month. A compliance worksheet must continue to report five-year totals, although it does not need transaction-level detail.

Which modification preserves the compliance requirement while still using aggregation for performance?

  1. Keep the 24-month extract filter and calculate the missing three years with a table calculation in the compliance worksheet.
  2. Retain five years in the extract and aggregate those rows by Product, Region, and Month before publication. (correct answer)
  3. Keep 24 months in the extract and remove Month from the compliance view so Tableau infers earlier years.
  4. Retain five years only in the live source and expect the filtered extract to query older rows when requested.
Explanation: When working with Tableau extracts, you need to balance two competing priorities: performance optimization (smaller extracts) and data completeness (all rows needed for analysis). The key concept here is that an extract's scope is fixed at publication — it cannot dynamically reach outside its own data to satisfy a query. Retaining five years of data in the extract and pre-aggregating those rows by Product, Region, and Month is exactly what the scenario requires. This approach in option B gives the compliance worksheet full five-year coverage while the aggregation step reduces row count significantly, delivering the performance benefit the team originally wanted. You get both goals simultaneously. Option A fails because table calculations in Tableau operate only on data already in the view — they cannot reconstruct or infer historical rows that were physically excluded from the extract. There is no data for those missing three years to calculate against. Option C contains a similar misconception: removing the Month dimension from a view changes how data is grouped and displayed, but it cannot conjure rows that don't exist in the extract. Tableau cannot "infer" earlier years from absent data. Option D describes a scenario that simply doesn't work in Tableau's architecture. An extract is a self-contained snapshot stored in a .hyper file. When a workbook uses an extract, it queries that file — it cannot fall back to the live source for rows the extract doesn't contain. The two sources don't communicate at query time. As a study tip, remember this rule: an extract can only return what it contains. Any answer suggesting Tableau can retrieve data excluded from an extract at query time is always wrong.

Question 10

A transaction-level extract supports a dashboard with filters for Region, Segment, and Product. The team proposes aggregating the extract only by Region and Month because the initial view shows regional monthly totals. Users must still be able to filter those totals by Segment and Product after publication.

How should the aggregation plan be revised?

  1. Aggregate by Region and Month only, because dashboard filters applied at view time can reconstruct any dimension values that were omitted from the extract grain.
  2. Aggregate by Segment and Product only, because Region can be derived from those dimensions and Month can be inferred from the transaction timestamps.
  3. Aggregate by Region, Month, Segment, and Product so all required filtering distinctions remain available. (correct answer)
  4. Aggregate by Region and Month, then convert Segment and Product into parameters that reference the original source fields to restore filtering capability.
Explanation: When working with aggregated extracts in Tableau, the golden rule is: you can only filter on dimensions that exist in the extract's grain. Aggregation collapses rows, and any dimension not included in the grouping key is permanently lost — it cannot be recovered at view time through filters alone. Here's why this matters for the scenario. The team wants to let users filter by Segment and Product after publication, but the proposed extract only preserves Region and Month as grouping dimensions. Once you aggregate away Segment and Product, those distinctions are gone — Tableau has no way to separate, say, "Technology in the East" from "Furniture in the East" because both were merged into a single "East" row. The only fix is to include all dimensions users need to filter on in the aggregation grain itself. That makes C correct: aggregating by Region, Month, Segment, and Product ensures every combination users might want to slice by is preserved. A is wrong because it describes something Tableau cannot actually do. View-time filters cannot reconstruct dimension values that were collapsed away during aggregation — the data simply doesn't exist in the extract anymore. B is wrong on two fronts: Region is its own independent dimension (not derivable from Segment/Product), and Month cannot be reliably inferred from timestamps that no longer exist in an aggregated extract. D is wrong because parameters in Tableau hold a single user-selected value and do not reference source fields dynamically — they cannot restore filtered dimension data that was excluded from the extract. Your study tip: whenever a question involves aggregated extracts, immediately ask yourself "what dimensions do users need to filter by?" — every one of those must appear in the extract grain.