Tableau Quiz: Creating And Refreshing Extracts
10 questions · exam conditions
0:00
Creating And Refreshing ExtractsQuestion 1 of 10

An analyst creates an extract from an order database on Monday morning. On Monday afternoon, the database receives additional orders. The analyst then opens the packaged workbook on a laptop that has no access to the database.

What data will the workbook display before the analyst refreshes the extract?

The Monday morning snapshot, because the extract is independent of later source changes until it is refreshed
All Monday orders, because packaged workbooks synchronize extracts automatically whenever they are opened
No order data, because an extract still requires an active connection to its original database
Only cached worksheet marks, because the extract becomes unavailable when the source database is offline
← Back to quizzes

Tableau Quiz

Tableau Quiz: Creating And Refreshing Extracts

Practice Creating And Refreshing Extracts 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 Creating And Refreshing Extracts, 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

An analyst creates an extract from an order database on Monday morning. On Monday afternoon, the database receives additional orders. The analyst then opens the packaged workbook on a laptop that has no access to the database.

What data will the workbook display before the analyst refreshes the extract?

  1. The Monday morning snapshot, because the extract is independent of later source changes until it is refreshed (correct answer)
  2. All Monday orders, because packaged workbooks synchronize extracts automatically whenever they are opened
  3. No order data, because an extract still requires an active connection to its original database
  4. Only cached worksheet marks, because the extract becomes unavailable when the source database is offline
Explanation: Whenever you see a question about Tableau extracts, anchor your thinking around one core principle: an extract is a static snapshot of data saved locally at the moment of extraction. It does not maintain a live link to the source — that's the whole point of extracting in the first place. When the analyst creates the extract Monday morning, Tableau captures exactly the data that exists at that moment and stores it in a .hyper file. That file travels with the packaged workbook (.twbx). When the afternoon orders arrive in the database, the extract has no awareness of them — it simply sits unchanged until someone explicitly triggers a refresh. So when the analyst opens the workbook on a database-disconnected laptop, they see the Monday morning snapshot cleanly and completely. That makes A correct. B is wrong because packaged workbooks have no automatic sync mechanism. Extracts never refresh on their own — refreshing always requires a deliberate action by the user or a scheduled refresh on Tableau Server/Cloud. C describes live connections, not extracts. A live connection does require active database access, but an extract exists precisely to eliminate that dependency — the data is embedded locally. D contains a grain of truth (cached marks do exist), but it misrepresents what an extract is. The extract itself remains fully available and queryable offline; it is not "unavailable" just because the source is offline. A helpful rule of thumb: extract = independence. Any answer suggesting an extract needs the source database to function is describing live connection behavior, not extract behavior — and that distinction will come up repeatedly on the Tableau exam.

Question 2

A customer extract is refreshed incrementally each night. During the day, the source system adds new customers, changes addresses for existing customers, and deletes customers whose records must be purged.

Which refresh strategy is required to make the extract fully match all three kinds of source changes?

  1. Run an incremental refresh using customer creation time, because it processes additions, updates, and deletions
  2. Run an incremental refresh using address modification time, because newer timestamps replace matching customer rows
  3. Run a full refresh, because existing rows must be rebuilt and deleted source rows must be removed (correct answer)
  4. Append the customer source again, because Tableau automatically deduplicates records by customer identifier
Explanation: When working with Tableau extracts, the core question to ask is: what kinds of changes does my source system produce, and can my refresh strategy capture all of them? Tableau offers two main strategies — incremental refresh and full refresh — and they handle changes very differently. A full refresh rebuilds the entire extract from scratch by re-querying all source data. This means additions show up as new rows, modifications appear because the updated source row replaces what was there before, and deletions are handled naturally — if a customer no longer exists in the source, they simply won't appear in the rebuilt extract. This makes C the correct answer: only a full refresh guarantees the extract mirrors all three types of changes. A is wrong because incremental refreshes using a creation timestamp only capture new rows added after the last refresh. They do nothing for updated addresses or deleted customers — those rows already exist in the extract and won't be touched. B improves on A slightly by capturing address updates (since modified rows get a newer timestamp), but it still fails for deletions. A purged customer has no timestamp at all in the source — they're gone — so no incremental strategy can remove them. D is simply false: Tableau does not automatically deduplicate records on append. Appending the full source repeatedly would create massive duplication, not a clean match. A useful study rule: if the word deletion appears in an extract scenario, incremental refresh cannot help you. Only a full refresh can remove rows that no longer exist in the source.

Question 3

A published workbook uses an extract from a database. The workbook displays correctly on Tableau Server, but scheduled refreshes fail after the database password is changed. Manually opening the workbook does not update its data.

What is the most appropriate corrective action?

  1. Update the stored connection credentials used by the published data source, then rerun or reschedule the refresh (correct answer)
  2. Convert every worksheet to a live connection, because published extracts cannot use database passwords in schedules
  3. Republish only the workbook layout, because publication refreshes the extract without reconnecting to the database
  4. Clear each user's browser cache, because failed schedules usually indicate stale client-side authentication information
Explanation: When a published workbook on Tableau Server uses an extract with scheduled refreshes, those refreshes run server-side using stored credentials — not your local credentials or the workbook file itself. When a database password changes, the stored credentials Tableau Server holds become invalid, causing scheduled refreshes to fail. The fix lives entirely in the server's credential configuration, not in the workbook or the client. A is correct because updating the stored connection credentials on the published data source gives Tableau Server the new password it needs to authenticate against the database. Once credentials are updated, you can immediately rerun the failed refresh or simply let the next scheduled run proceed normally. This is exactly how Tableau Server is designed to handle credential changes. B is wrong because published extracts absolutely can use stored database credentials for scheduled refreshes — that's a core feature of Tableau Server. Converting to live connections would change your architecture unnecessarily and doesn't address the root cause (stale credentials). C is wrong because republishing only the workbook layout does nothing to reconnect the extract to the database. The extract is a separate artifact on the server; republishing layout doesn't refresh or re-authenticate the underlying data source. D is wrong because browser cache has no relationship to server-side scheduled refresh failures. Schedules run as background server processes completely independent of any user's browser session or client-side state. A useful pattern to remember: on Tableau Server questions, when refreshes fail after an environmental change (password reset, certificate update, network change), your first instinct should always be to look at stored credentials on the server, not the workbook file or client machines.

Question 4

A company publishes an extract to Tableau Cloud. Its source is a database accessible only from the company's private network, and the database cannot accept inbound connections from Tableau Cloud.

Which approach best supports scheduled refreshes without exposing the database publicly?

  1. Install and configure Tableau Bridge where it can reach the private database, then associate it with the connection (correct answer)
  2. Embed the database password in the workbook, allowing Tableau Cloud to bypass the network access restriction
  3. Change the workbook to a live connection, allowing each browser to connect directly to the private database
  4. Download and reopen the extract daily, allowing Tableau Cloud to detect source changes through the workbook
Explanation: When a question asks how to schedule extract refreshes for a database that lives behind a private network, you should immediately think about Tableau Bridge — the component specifically designed to bridge the gap between Tableau Cloud and data sources that aren't publicly accessible. Tableau Bridge is a lightweight client you install on a machine inside your private network. Because it initiates the outbound connection to Tableau Cloud (rather than waiting for an inbound one), it works seamlessly with firewalls and private databases. That's exactly why A is correct: installing Bridge on a machine that can reach the private database allows Tableau Cloud to trigger scheduled refreshes without ever needing direct access to the database itself. The distractors each reflect a common misconception. B is wrong because embedding a password doesn't change network routing — Tableau Cloud still can't reach a database that blocks inbound connections, regardless of credentials. C misunderstands the architecture: switching to a live connection would require every user's browser to connect directly to a private database, which is both impossible from outside the network and a serious security risk. D describes a completely manual process — downloading and reopening the workbook yourself — which defeats the purpose of scheduled, automated refreshes and doesn't actually allow Tableau Cloud to detect source changes on its own. A useful pattern to remember: whenever a question mentions a private or on-premises data source paired with Tableau Cloud, Bridge is almost always the right tool. It's the standard answer for closing the gap between a cloud-hosted platform and a network-restricted data source.

Question 5

To reduce extract size, an analyst creates an extract using Aggregate data for visible dimensions. The workbook currently displays monthly sales by region. Later, another author needs order-level records from the same data source.

What should the author do to obtain the required order-level detail?

  1. Run a full refresh of the existing extract, because full refreshes automatically restore the source's finest grain
  2. Run an incremental refresh using Order ID, because new refresh keys decompose previously aggregated records
  3. Add Order ID to Detail, because Tableau reconstructs underlying rows from the aggregated measure values
  4. Disable aggregation and recreate the extract, because the current extract does not store the omitted row-level detail (correct answer)
Explanation: When Tableau creates an extract with Aggregate data for visible dimensions enabled, it pre-aggregates the data at the granularity of whatever dimensions are currently visible — in this case, month and region. Critically, the underlying row-level records are never stored in the extract file. This is a one-way transformation: once aggregation is applied at extract creation, the original detail is gone from the extract permanently. This is why D is correct. To get order-level records, the author must disable aggregation and recreate the extract from scratch, pulling the full row-level data from the source. There is no mechanism to "undo" aggregation within an existing extract. A is tempting because full refreshes sound comprehensive, but a full refresh only re-executes the same extract definition against the source — it still applies the same aggregation settings. It replaces all rows in the extract, but with equally aggregated data. B is a misconception about incremental refreshes. Incremental refreshes append new rows based on a key field like Order ID; they do not decompose or reverse previously aggregated records. The aggregated history remains aggregated. C reflects a misunderstanding of how Tableau's Detail shelf works. Adding a field to Detail changes the view's level of granularity for visualization purposes, but it cannot reconstruct row-level data that was never stored in the extract in the first place. Study tip: Whenever you see a question involving extract aggregation, ask yourself: "Was the detail stored?" If aggregation was applied at extract creation, the answer is no — and no refresh or shelf adjustment can recover what was never saved.

Question 6

A monthly CSV file is replaced in place. Each replacement contains the complete current customer list, and its RowNumber values restart at 1. The existing extract uses RowNumber for incremental refreshes, and its current maximum is 85000.

Which refresh method should be used after the file is replaced?

  1. Use an incremental refresh, because replacing the file causes Tableau to reset the extract's maximum row number
  2. Use an incremental refresh, because Tableau compares the file's modified date rather than the selected refresh field
  3. Use a full refresh, because restarted row numbers will not exceed the high-water value in the existing extract (correct answer)
  4. Append the replacement file, because complete snapshots are automatically reconciled against existing customer rows
Explanation: Whenever you see a question about incremental refresh, the critical concept to understand is how Tableau's high-water mark works. During an incremental refresh, Tableau looks at the maximum value of your chosen refresh field in the existing extract — say, 85000 — and only pulls in new rows where that field exceeds that value. It does not re-examine the source file's modification date, reset its internal counter, or compare records by content. Here's the problem: when the monthly CSV is replaced, its RowNumber values restart at 1. Every row in the new file has a value below 85000, so Tableau's incremental refresh logic concludes there is nothing new to add. The extract appears up to date, but it actually reflects the old customer list entirely. A full refresh wipes the extract and rebuilds it completely from the source, which is exactly what you need when the source file is a complete replacement snapshot. That makes C correct. A is wrong because Tableau does not automatically reset the extract's high-water mark when the source file is replaced — the stored maximum of 85000 remains unchanged, which is precisely the root of the problem. B is wrong because incremental refresh uses the selected field's value, not the file's modified date; confusing these two mechanisms is a classic trap. D is wrong because appending adds rows rather than replacing them, and Tableau has no built-in logic to reconcile or deduplicate customer records during an append operation. As a study rule: whenever a source file is a full replacement snapshot (not an additive log), always default to a full refresh — incremental refresh is designed for append-only data sources.

Question 7

An extract initially contains five years of sales. Its extract filter is then changed so that only the most recent two years qualify. The extract is configured for incremental refreshes.

Which action will remove the older three years from the stored extract while retaining qualifying source data?

  1. Run an incremental refresh after changing the filter, because nonqualifying existing rows are removed during the append
  2. Run a full refresh with the revised extract filter, because the stored rows must be rebuilt under the new condition (correct answer)
  3. Apply the same condition as a worksheet filter, because hiding marks also removes their rows from the extract
  4. Refresh the worksheet twice, because the first refresh updates metadata and the second removes excluded rows
Explanation: When working with Tableau extracts, you need to understand the difference between incremental and full refreshes — this question tests exactly that distinction. A full refresh completely rebuilds the extract from scratch using the current extract filter definition. This means Tableau queries the source, applies the revised filter (most recent two years), and replaces all stored rows with only the qualifying data. The older three years simply never make it into the rebuilt extract. This is why B is correct — changing an extract filter alone doesn't alter stored data; you must run a full refresh to enforce the new filter against the existing rows. A is a tempting trap because incremental refreshes do interact with extract filters, but incrementally refreshing only appends new rows that meet the defined incremental column criteria — it does not scan and remove previously stored rows that no longer qualify. Old data already sitting in the extract stays there. C confuses two separate Tableau layers. Worksheet filters control what's displayed in a view; they have no effect on what rows are physically stored inside the extract file (.hyper). Hiding marks on a worksheet leaves the underlying extract data completely untouched. D is fabricated logic. There is no two-pass refresh mechanism in Tableau where the first refresh updates metadata and the second purges rows. This answer exploits vague familiarity with "refreshing" to sound plausible, but it describes no real Tableau behavior. Study tip: Whenever a question involves removing data from an extract, think "full refresh." Incremental refreshes add; full refreshes rebuild. That distinction appears repeatedly on the Tableau exam.

Question 8

A transaction extract uses CreatedAt for incremental refreshes. Its current maximum value is 2026-06-30 23:59:59. Several transactions committed later were assigned that exact same timestamp because the source stores time only to the nearest second.

Which action most reliably captures those same-timestamp transactions?

  1. Repeat the incremental refresh, because rows equal to the current maximum are added on the second attempt
  2. Use a full refresh, because rows tied with the existing high-water value may not qualify as newer (correct answer)
  3. Clear the worksheet cache, because the rows are already in the extract but are not yet displayed
  4. Sort CreatedAt descending, because sorting recalculates the maximum value used by the refresh
Explanation: Whenever you see a question about incremental extract refreshes, focus on how Tableau determines which rows to fetch: it pulls records where the timestamp is strictly greater than the stored high-water mark. That boundary condition is the heart of this question. Here's the problem: the high-water mark is 2026-06-30 23:59:59, and several new transactions were committed with that exact same timestamp. Because the incremental refresh filter asks for rows newer than the maximum — not equal to or newer than — those tied rows are silently excluded. They aren't "newer"; they're equal. The only way to guarantee they are captured is to run a full refresh, which re-reads the entire source table without relying on a high-water mark at all. That makes B correct. A is wrong because repeating the incremental refresh applies the same > max_timestamp logic a second time. The high-water mark doesn't change between attempts, so the same rows are excluded again — you'd just get the same gap twice. C is wrong because this is not a display or caching issue. The rows are genuinely absent from the extract; clearing a worksheet cache only affects what's shown from data already loaded, not what was fetched from the source. D is wrong because sorting is purely a presentation operation. The order of rows in a view has absolutely no effect on how Tableau calculates or applies the high-water mark during a refresh. As a study tip: anytime you see "incremental refresh" paired with boundary values or timestamp precision limits, ask yourself whether equal-timestamp rows fall inside or outside the > filter — that's the trap Tableau questions love to set.

Question 9

An extract uses OrderID as its incremental refresh field. The largest OrderID currently stored is 500. Before the next refresh, the source receives new rows with OrderID values 498, 501, and 502. An existing source row with OrderID 320 is also corrected.

What is the expected result of a standard incremental refresh?

  1. Rows 498, 501, and 502 are added, while the corrected row 320 remains unchanged
  2. Rows 501 and 502 are added, while row 498 and the correction to 320 are not captured (correct answer)
  3. Rows 501 and 502 are added, and the existing extracted row 320 is replaced by its correction
  4. All four source changes are captured because Tableau compares every source row with the extract
Explanation: Whenever you see a question about incremental refresh, the core concept to keep in mind is this: Tableau uses a simple "greater than last known value" rule. It queries the source for rows where the refresh field exceeds the highest value already stored in the extract — nothing more, nothing less. In this scenario, the extract's ceiling is OrderID = 500. On the next incremental refresh, Tableau fetches rows where OrderID > 500, which means only 501 and 502 qualify. Those two rows are appended to the extract. That's it — making B the correct answer. Here's why the other choices miss the mark. A is tempting because it feels thorough, but 498 is below the current ceiling of 500, so it falls outside the refresh window entirely — Tableau never sees it. C suggests the correction to row 320 is captured, but incremental refresh has no mechanism to detect changes to existing rows. Row 320 is already in the extract and its OrderID is far below 500, so Tableau simply ignores it. D describes a full refresh, not an incremental one — Tableau does not compare every source row against the extract during incremental refresh; that would defeat the entire performance purpose of the feature. The study tip here: remember that incremental refresh is fast because it's blind to updates and late-arriving rows below the threshold. If your data can have corrections or out-of-order inserts, a full refresh is the safer choice — and that distinction is a favorite exam trap.

Question 10

A source table is append-only. EventID is unique, assigned in increasing order, and never changed. EventDate is entered by users and can be corrected later. Status changes repeatedly during an event's life.

Which field is the best candidate for a standard incremental refresh key?

  1. Any of the three fields, because a standard incremental refresh evaluates each complete source record against its extract counterpart rather than relying on a single high-water value
  2. EventDate, because business dates are always entered in strict chronological order, ensuring that later events always carry later values than those already in the extract
  3. Status, because changed status values cause Tableau to identify and replace matching rows already stored in the extract
  4. EventID, because it is stable and increasing, so newly appended rows can exceed the existing maximum (correct answer)
Explanation: When tackling incremental refresh questions, focus on what a standard incremental refresh actually does: it reads the current maximum value of your chosen key field from the extract, then pulls only source rows where that field's value exceeds that maximum. This mechanism depends entirely on the key being stable, unique, and monotonically increasing — otherwise Tableau either misses new rows or pulls the wrong ones. That's exactly why D is correct. EventID is assigned in increasing order and never changes, meaning every newly appended row will have an EventID greater than any row already in the extract. Tableau's high-water mark logic works perfectly here: grab everything above the current max, and you've captured all new data without re-scanning the full source. A is wrong because it describes a behavior that doesn't exist in a standard incremental refresh. Tableau does not compare complete records against extract counterparts row-by-row — that would be a full refresh. Standard incremental refresh is purely a high-water mark operation. B is wrong because EventDate is user-entered and correctable. Even setting aside data-entry errors, business dates are not guaranteed to arrive in strict chronological order — a user might log an event with yesterday's date today. Any out-of-order or corrected date could cause new rows to fall below the current maximum, making Tableau skip them entirely. C is wrong on two levels: Status is not monotonically increasing, and standard incremental refresh cannot identify and replace changed rows. That update-in-place behavior requires a different refresh strategy altogether. Study tip: On Tableau exam questions about incremental refresh, always ask: "Is this field stable, unique, and always growing?" If any answer is no, that field cannot serve as a reliable high-water mark key.