Tableau Quiz: Scheduled Refreshes
10 questions · exam conditions
0:00
Scheduled RefreshesQuestion 1 of 10

A sales extract is scheduled to refresh at 8:00 a.m. The refresh usually takes 35 to 50 minutes, depending on backgrounder workload and source performance. Executives open the dashboard at 8:30 a.m. and require the new data to be available by then.

Which change most directly addresses the requirement?

Keep the 8:00 a.m. schedule because a scheduled time guarantees that the refresh will finish before the next half hour.
Move the refresh earlier and monitor completion history, because the schedule determines eligibility to start rather than a guaranteed finish time.
Add a second schedule at 8:15 a.m. because overlapping refresh attempts guarantee that the first successful job finishes by 8:30.
Switch to an incremental refresh because every incremental refresh is guaranteed to finish within the interval before dashboard access.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Scheduled Refreshes

Practice Scheduled Refreshes 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 Scheduled Refreshes, 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 sales extract is scheduled to refresh at 8:00 a.m. The refresh usually takes 35 to 50 minutes, depending on backgrounder workload and source performance. Executives open the dashboard at 8:30 a.m. and require the new data to be available by then.

Which change most directly addresses the requirement?

  1. Keep the 8:00 a.m. schedule because a scheduled time guarantees that the refresh will finish before the next half hour.
  2. Move the refresh earlier and monitor completion history, because the schedule determines eligibility to start rather than a guaranteed finish time. (correct answer)
  3. Add a second schedule at 8:15 a.m. because overlapping refresh attempts guarantee that the first successful job finishes by 8:30.
  4. Switch to an incremental refresh because every incremental refresh is guaranteed to finish within the interval before dashboard access.
Explanation: When working with Tableau's extract refresh system, the key concept to understand is that a scheduled refresh determines when a job becomes eligible to run — it does not guarantee a completion time. Backgrounder availability, source system performance, and queue depth all affect how long the job actually takes. Because the refresh can take 35–50 minutes and starts at 8:00 a.m., it could finish anywhere between 8:35 and 8:50 — after executives need the data. The direct fix is to move the schedule earlier (say, 7:00–7:10 a.m.) so the job has sufficient runway to finish before 8:30, and to monitor completion history to validate that the new window reliably works. That's exactly what B recommends, making it the correct answer. A is wrong because it assumes a scheduled start time guarantees an on-time finish — a fundamental misconception. The schedule only queues the job; actual completion depends on runtime factors outside your control. C introduces a dangerous misunderstanding: running overlapping refresh jobs doesn't accelerate completion. In fact, Tableau will typically skip or queue a second refresh if one is already running, and competing backgrounder jobs can slow things down further. There is no "first successful job wins" mechanism that helps here. D conflates refresh type with refresh speed. While incremental refreshes can be faster, Tableau makes no guarantee that any incremental refresh finishes within a specific time window — so this doesn't solve the scheduling problem reliably. Study tip: On Tableau exam questions about scheduling, always ask yourself: does this feature control when a job starts, or when it finishes? Schedules control the former — never the latter.

Question 2

A nightly extract refresh fails repeatedly because the source database is unavailable. Tableau subsequently indicates that the refresh task has been suspended or disabled. The database is now online, but the next scheduled time passes without a new attempt.

What action is required to restore normal scheduled processing?

  1. Wait for the following schedule because a suspended refresh automatically becomes active as soon as its source responds.
  2. Open the workbook once in a browser because loading a view automatically reactivates every failed refresh task it uses.
  3. Correct or verify the underlying connection, then explicitly resume or re-enable the refresh task and monitor its next run. (correct answer)
  4. Delete the extract history because retained failure records prevent the scheduler from recognizing that the source is available.
Explanation: When Tableau detects repeated extract refresh failures, it doesn't just log the errors and keep trying — it actively suspends or disables the refresh task to prevent resource waste and alert administrators that intervention is needed. Understanding this behavior is key to answering questions about Tableau's scheduler and extract management. Because the suspension is a deliberate, human-intervention-required state, the fix must also be deliberate. You need to do two things: confirm the underlying connection is valid (so you're not re-enabling a task that will immediately fail again), and then explicitly resume or re-enable the refresh task through Tableau Server or Tableau Cloud. Once re-enabled, the task will run at its next scheduled time — or you can trigger a manual run to verify the fix. This is exactly what C describes, making it the correct answer. A is wrong because suspended tasks do NOT self-heal. Tableau does not poll the source and automatically reactivate the task when connectivity returns. The suspension is persistent until a human intervenes — waiting for the next schedule will accomplish nothing. B is wrong because opening a workbook in a browser loads a cached or live view but has absolutely no effect on the scheduler's task state. Viewing a dashboard and managing extract refresh schedules are entirely separate system functions. D is wrong because deleting extract history is unrelated to the scheduler's behavior. Tableau does not consult failure history to decide whether to resume a suspended task — the suspension flag itself must be cleared through the task management interface. Your study tip: on Tableau exam questions, watch for the phrase "suspended" or "disabled" as a signal that manual re-enablement is always required — nothing automatic restores it.

Question 3

An analyst creates an extract from a CSV file stored in a folder on the analyst's laptop and publishes the workbook. A refresh schedule is configured on the server. The analyst later replaces the local CSV with a newer file, but the published data does not change after the scheduled run.

Which change would most reliably allow scheduled refreshes to use the updated file?

  1. Increase the schedule frequency because the server will eventually discover the replacement file on the analyst's local laptop.
  2. Embed the analyst's Tableau password because Tableau authentication grants the backgrounder access to local operating-system folders.
  3. Rename the local replacement file to match the workbook because matching names allow the server to retrieve files from publisher devices.
  4. Store the file in a network location reachable by the refresh environment, or use an appropriate connectivity agent for the private file. (correct answer)
Explanation: When you see a question about scheduled extract refreshes failing, the core concept to focus on is where the data source lives relative to Tableau Server's backgrounder process. The backgrounder is the server component that executes scheduled refreshes — and it can only reach data sources it has network access to at refresh time. Publishing a workbook from a local CSV embeds a snapshot of that data as an extract, but the connection path still points to your laptop's local file system. Tableau Server's backgrounder has no ability to reach into a private laptop drive — it doesn't matter how often the schedule runs or what credentials are involved. Storing the file in a network-accessible location (such as a shared network drive, cloud storage, or a UNC path), or using a connectivity agent like Tableau Bridge for private network sources, gives the backgrounder a path it can actually reach during the scheduled run. That's why D is correct. A is wrong because increasing refresh frequency changes nothing about access — the server still cannot see your local file system, so it will repeatedly fail to find updates regardless of how often it tries. B is wrong because Tableau Server credentials authenticate Tableau users, not the operating system of the publisher's machine. No password grants the server remote access to a laptop's local folders. C is wrong because file naming is irrelevant here. Tableau Server has no mechanism to "pull" files from a publisher's device by matching names — that's simply not how the architecture works. As a study tip: always ask yourself who runs the refresh and what can they reach? The answer is always the server's backgrounder, and it only reaches network-accessible resources.

Question 4

A workbook uses a live connection to a supported cloud database. The database is updated throughout the day. A site administrator looks for an extract refresh schedule on the workbook but finds none.

Which explanation is most accurate?

  1. The workbook is misconfigured because all published database connections require an extract schedule before users can see updated values.
  2. The absence is expected because a live connection queries the source when views are requested, rather than refreshing a stored extract. (correct answer)
  3. The schedule is hidden because live connections automatically create a daily full extract that only administrators can manage.
  4. The workbook must first be downloaded because live connections can be refreshed only through Tableau Desktop's extract commands.
Explanation: When a question involves Tableau connection types, your first instinct should be to distinguish between live connections and extracts — they behave very differently, and that difference is exactly what's being tested here. A live connection works by sending a query directly to the data source every time a user loads a view. Because the data is never copied into Tableau's storage, there is nothing to "refresh" on a schedule — the connection simply fetches whatever is currently in the database at that moment. This is why the site administrator finds no extract refresh schedule: none is needed or created. Answer B correctly captures this by explaining that live connections query the source on demand rather than maintaining a stored extract. Answer A is wrong because it invents a requirement that doesn't exist. Published workbooks with live connections work perfectly without any extract schedule — the schedule is a feature of extracts, not a prerequisite for all database connections. Answer C introduces a fictional behavior: live connections do not silently generate a hidden daily extract. No such automatic extract is created behind the scenes, regardless of who is looking. Answer D misrepresents how extract commands work. Even if you wanted to convert a live connection to an extract, that action can be performed in Tableau Cloud or Tableau Server, not exclusively in Tableau Desktop. As a study tip, remember the core distinction: live = query on demand, extract = stored snapshot with a refresh schedule. On the Tableau exam, any answer that blurs this boundary — by claiming live connections need schedules or secretly create extracts — is almost certainly a trap.

Question 5

An orders extract uses an increasing Order ID as its incremental refresh field. New orders are inserted daily, but fulfillment staff can also correct older orders and delete canceled orders. Daily incremental refreshes complete successfully, yet corrections and deletions are missing from Tableau.

Which refresh strategy most appropriately balances refresh duration with data completeness?

  1. Continue only incremental refreshes because a successful incremental run updates every source row whose values have changed.
  2. Run daily full refreshes and disable incremental refreshes because the two refresh types cannot be used for one extract.
  3. Run incremental refreshes frequently and schedule periodic full refreshes to reconcile updates and deletions in older rows. (correct answer)
  4. Change the incremental field to Order Date because any date-based field automatically detects updates and physical deletions.
Explanation: Whenever you see a question about Tableau extract refreshes, focus on what incremental refresh actually does — and what it cannot do. Incremental refresh works by appending rows where the incremental field (here, Order ID) is greater than the maximum value already in the extract. It only ever adds new rows; it never revisits existing ones. This means updates to older rows and deleted rows are completely invisible to an incremental refresh, even when those refreshes complete without errors. That's exactly why C is correct. Scheduling frequent incremental refreshes keeps new orders flowing into the extract with minimal load time, while periodic full refreshes rebuild the entire extract from the source — capturing corrections to older orders and removing rows for canceled orders that were deleted. This hybrid strategy balances speed (incremental) with accuracy (full), which is the practical standard for sources that have inserts, updates, and deletes. Answer A is wrong because a successful incremental refresh does not update changed values in existing rows — it only appends rows with a higher incremental field value. "Successful" just means no errors occurred, not that all changes were captured. Answer B contains a false premise: Tableau absolutely allows you to use both refresh types on the same extract. Disabling incremental refreshes entirely would also sacrifice the speed benefit the question asks you to preserve. Answer D is wrong on two counts — switching to Order Date doesn't change the fundamental behavior of incremental refresh, and no incremental field, date-based or otherwise, automatically detects updates or physical deletions. As a study tip, remember: incremental = append only. Any time a question involves updates or deletes to existing records, a full refresh must be part of the solution.

Question 6

An analyst can refresh an extract successfully in Tableau Desktop while connected to the corporate network. After the workbook is published, its scheduled refresh fails on Tableau Server with a connection timeout. The database credentials are confirmed to be valid.

What is the best next troubleshooting step?

  1. Verify that the Tableau Server execution environment can reach the database and has any required drivers, firewall access, and network routes. (correct answer)
  2. Increase the workbook's dashboard cache duration so the scheduled refresh has more time to establish the database connection.
  3. Grant the analyst permission to download the workbook because download permission controls whether backgrounders can contact databases.
  4. Recreate the extract locally because a successful Desktop refresh proves that Tableau Server has identical database connectivity.
Explanation: When a scheduled extract refresh fails on Tableau Server but succeeds in Tableau Desktop, you're dealing with an environment mismatch — not a credentials problem, not a workbook problem. The key insight is that Tableau Desktop runs in your environment (your machine, your network, your drivers), while Tableau Server's backgrounder process runs in a completely separate environment with its own network paths, firewall rules, and installed drivers. Since the question already confirms credentials are valid, the logical next step is to investigate what's different about the Server environment itself. A is correct because a connection timeout points directly to a network-layer or driver issue on the Server side. You need to verify that the Tableau Server backgrounder can actually reach the database host — checking firewall rules, network routes, and whether the appropriate database driver is installed on the Server machine. These are the exact causes of a timeout when credentials are known-good. B is wrong because dashboard cache duration controls how long Tableau Server stores cached query results for end users — it has absolutely nothing to do with how long a backgrounder waits to establish a database connection during a refresh. This conflates two unrelated settings. C is wrong because download permissions govern whether users can save a copy of a published workbook to their machine. They have no bearing on whether the Server's backgrounder process can contact a database. This answer invents a relationship that doesn't exist. D is wrong because a successful Desktop refresh proves nothing about Server connectivity. The two environments are independent — this is precisely the misconception the question is testing. Study tip: On Tableau Server troubleshooting questions, always ask: "Is this a user/permissions issue, a credentials issue, or an environment issue?" A timeout after confirmed-valid credentials almost always points to the environment — network, firewall, or drivers on the Server itself.

Question 7

A workbook named Executive Sales connects to a separately published data source named Certified Sales. Certified Sales contains an extract. The workbook contains calculations and dashboards but no independent extract of the sales data. Users report that the dashboards show yesterday's values.

Where should the administrator configure the scheduled refresh that updates the values used by the workbook?

  1. On Executive Sales only, because workbook schedules automatically refresh every published data source referenced by the workbook.
  2. On both items, because the data source refreshes its rows while the workbook refresh copies those rows into each dashboard.
  3. On Certified Sales, because the extract belongs to the published data source and connected workbooks use its refreshed results. (correct answer)
  4. On Executive Sales only, because a workbook must refresh its calculations after the published data source has been updated.
Explanation: When you see a question about refreshing data in Tableau Server or Cloud, focus on where the extract actually lives. An extract is a snapshot of data stored as a physical file — and that file belongs to whoever owns it. In this scenario, the extract is embedded in the Certified Sales published data source, not in Executive Sales. The workbook simply connects to Certified Sales like a live query; it holds no extract of its own. This means C is correct. Scheduling a refresh on Certified Sales updates the extract file sitting on the server. When users open Executive Sales afterward, the workbook queries the already-refreshed published data source and immediately sees current values. The refresh happens at the data source level, and all connected workbooks benefit automatically. A is wrong because workbook schedules do not cascade down to refresh connected published data sources. A workbook schedule would only matter if the workbook itself contained an embedded extract — which this one explicitly does not. B is wrong because it invents a two-tier refresh model that doesn't exist. Dashboards do not store rows of data separately from the extract; they render results from whatever data source they're connected to. There is no "copy rows into each dashboard" step. D is wrong for a similar reason as A — it assumes the workbook must participate in refreshing calculations post-update. Tableau recalculates workbook calculations at query time using the current extract data; no separate workbook refresh schedule is needed for that to happen. Study tip: On Tableau exam questions about refreshes, always ask "where is the extract stored?" — that's where the schedule belongs.

Question 8

A scheduled extract refresh has succeeded for several months. Immediately after the database team rotates the password for the account embedded in the published connection, every scheduled run fails with an authentication error. The extract design and database address have not changed.

What should the content owner do first?

  1. Create a new refresh schedule because existing schedules retain the old database password in each scheduled task.
  2. Update the published connection's saved credentials, verify the connection, and then rerun or resume the refresh task. (correct answer)
  3. Download and republish the workbook because authentication errors indicate that the existing extract has become corrupted.
  4. Change the refresh from incremental to full because a full refresh requests a new database authentication session.
Explanation: When a scheduled extract refresh suddenly fails with an authentication error right after a password rotation, you're dealing with a credential management problem, not a structural or design problem. The extract, the schedule, and the database address are all intact — only the stored password is now stale. In Tableau Server and Tableau Cloud, published data sources store embedded credentials that are used to authenticate during scheduled refreshes. When a database password changes, those stored credentials become invalid. The fix is straightforward: navigate to the published connection, update the saved credentials with the new password, verify the connection succeeds, and then rerun or resume the failed refresh task. That's exactly what B describes, and it's the correct first step. A is wrong because schedules don't store passwords at all — credentials are stored at the data source or connection level, not inside individual scheduled tasks. Creating a new schedule would accomplish nothing. C confuses an authentication failure with data corruption. An authentication error means Tableau couldn't log in to the database — it never even reached the extract data. The extract file itself is fine; there's nothing to redownload or republish. D misrepresents how authentication works. Switching from incremental to full refresh doesn't trigger a fresh login session or bypass stored credentials — both refresh types use the same embedded credentials. The type of refresh is irrelevant to authentication failures. As a study tip, remember that on Tableau exam questions involving "suddenly fails after an infrastructure change," your first instinct should be to isolate what changed — in this case, credentials — and address only that layer.

Question 9

A company publishes an extract-based data source to Tableau Cloud. The underlying database is available only from the company's private network, and security policy prohibits exposing the database directly to the internet. Users need the extract refreshed every morning without leaving Tableau Desktop open.

Which configuration best supports the required scheduled refresh?

  1. Install Tableau Bridge on a network-connected host, configure an appropriate pool, and assign the data source to that pool. (correct answer)
  2. Keep Tableau Desktop running on the publisher's computer and configure Tableau Cloud to invoke Desktop at the scheduled time.
  3. Convert the data source to a live connection so Tableau Cloud can bypass the private-network restrictions during scheduled queries.
  4. Upload the extract again with embedded database credentials so Tableau Cloud can directly reach the private database.
Explanation: Whenever you see a question about refreshing extract-based data sources that live behind a private network firewall, your first instinct should be to ask: how does Tableau Cloud reach a database it can't see directly? That's the core concept being tested here — Tableau Bridge. Tableau Bridge is a lightweight client you install on a machine inside your corporate network. It maintains an outbound connection to Tableau Cloud, acting as a secure relay so Cloud can trigger extract refreshes against databases that are never exposed to the internet. By installing Bridge on a network-connected host, creating a pool, and assigning the published data source to that pool, you get fully automated, scheduled refreshes — no one needs to be logged in or have Desktop open. That's exactly why A is correct. B is a trap because Tableau Cloud has no mechanism to "wake up" or invoke Tableau Desktop on a remote machine. Desktop is an authoring tool, not a server process — leaving it open accomplishes nothing for cloud-scheduled refreshes. C misunderstands the privacy constraint. Switching to a live connection doesn't grant Tableau Cloud magical access to a private network; if anything, a live connection makes the problem worse because every query would need to reach the database in real time, which the firewall still blocks. D fails for the same fundamental reason — embedding credentials doesn't change network topology. Tableau Cloud still cannot route traffic to a host that's firewalled off from the internet, regardless of what credentials are stored. A useful pattern to remember: anytime a Tableau Cloud question involves a private/on-premises database, Bridge is almost always the right answer.

Question 10

A business-critical extract is owned by an employee who is leaving the company. Its scheduled refresh uses that employee's personal OAuth authorization to access the cloud data source. The organization wants the refresh to continue while minimizing dependence on individual accounts.

Which governance action is most appropriate before the employee's account is deactivated?

  1. Transfer content responsibility, replace the personal authorization with an approved managed credential, and test the scheduled refresh to confirm it succeeds under the new owner. (correct answer)
  2. Leave ownership unchanged, because published schedules permanently preserve the departing employee's OAuth access token even after the account is deactivated and the credential is revoked.
  3. Export the employee's OAuth token and attach it to the schedule under another owner's account, since the existing authorization will remain valid as long as it is associated with an active user.
  4. Disable failure notifications for the refresh task, because credential revocation affects alert delivery only and does not interrupt the scheduled refresh connection itself.
Explanation: When a question involves employee offboarding and data source credentials in Tableau, you should immediately think about two overlapping risks: content orphaned without an owner, and broken authentication that silently kills scheduled refreshes. These are separate problems that must both be solved before the account goes dark. The right move is option A. Transferring content ownership assigns a new responsible party so the extract isn't left in an unmanaged state. More critically, replacing the personal OAuth authorization with a managed credential — such as a service account or an organization-controlled embedded credential — decouples the refresh from any single employee's identity. Testing the schedule afterward confirms the fix actually works end-to-end, not just on paper. This combination addresses governance, reliability, and verification in a single coordinated action. Option B is dangerously wrong. OAuth tokens tied to a deactivated account are revoked when that account is disabled; Tableau does not preserve or cache them permanently. Schedules will immediately begin failing once the credential is invalidated. Option C describes something that isn't possible in Tableau's architecture. OAuth tokens are issued to specific users, are not transferable between accounts, and cannot be "exported and reattached." Attempting this would expose a security vulnerability even if it were technically feasible. Option D reflects a fundamental misunderstanding. Disabling failure notifications doesn't protect the refresh connection — it simply silences the alerts that would tell you the refresh is broken. The underlying credential failure still occurs; you'd just stop hearing about it. As a study tip, remember that on Tableau governance questions, the correct answer almost always addresses both the ownership layer and the authentication layer — fixing only one is a trap the distractors are designed to exploit.