- What is the most appropriate corrective action?
Answer: Update the stored connection credentials used by the published data source, then rerun or reschedule the refresh
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.
- Which action most reliably captures those same-timestamp transactions?
Answer: Use a full refresh, because rows tied with the existing high-water value may not qualify as newer
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.
- Which refresh method should be used after the file is replaced?
Answer: Use a full refresh, because restarted row numbers will not exceed the high-water value in the existing extract
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.
- Which refresh strategy is required to make the extract fully match all three kinds of source changes?
Answer: Run a full refresh, because existing rows must be rebuilt and deleted source rows must be removed
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.
- What is the expected result of a standard incremental refresh?
Answer: Rows 501 and 502 are added, while row 498 and the correction to 320 are not captured
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.
- Which approach best supports scheduled refreshes without exposing the database publicly?
Answer: Install and configure Tableau Bridge where it can reach the private database, then associate it with the connection
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.
- Which field is the best candidate for a standard incremental refresh key?
Answer: EventID, because it is stable and increasing, so newly appended rows can exceed the existing maximum
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.
- Which action will remove the older three years from the stored extract while retaining qualifying source data?
Answer: Run a full refresh with the revised extract filter, because the stored rows must be rebuilt under the new condition
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.
- What should the author do to obtain the required order-level detail?
Answer: Disable aggregation and recreate the extract, because the current extract does not store the omitted row-level detail
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.
- What data will the workbook display before the analyst refreshes the extract?
Answer: The Monday morning snapshot, because the extract is independent of later source changes until it is refreshed
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.
