Tableau Quiz: Live Vs Extract
15 questions · exam conditions
0:00
Live Vs ExtractQuestion 1 of 15

A huge source table is used with an extract. Which limitation must the team accept?

Queries will run slower
The source is queried live
Extract cannot be filtered
The data can become stale
← Back to quizzes

Tableau Quiz

Tableau Quiz: Live Vs Extract

Practice Live Vs Extract 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 Live Vs Extract, 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 huge source table is used with an extract. Which limitation must the team accept?

  1. Queries will run slower
  2. The source is queried live
  3. Extract cannot be filtered
  4. The data can become stale (correct answer)
Explanation: An extract is a local snapshot, so the data isn't refreshed automatically; it reflects the last refresh and can go stale. A huge source actually argues for an extract: queries run faster against an optimized local copy, not slower. Live-querying the source is the live connection limitation, not extract. Extracts also can be filtered at creation.

Question 2

With a live connection, dragging a filter across millions of rows will most likely:

  1. Send all rows to Tableau once
  2. Run one query per adjustment (correct answer)
  3. Refresh the data extract first
  4. Load a cached result instead
Explanation: With a live connection, every time you move the filter, Tableau sends a new query to the underlying database; dragging across millions of rows means many small adjustments, each producing its own query. The tempting wrong answer is that all rows are sent to Tableau once, but a live connection doesn't pull entire tables - it queries the database and returns only the relevant results.

Question 3

To reduce source load but keep data almost current, choose:

  1. Live connection to source
  2. Extract refreshed every 5 min (correct answer)
  3. Extract refreshed once daily
  4. Extract, never refreshed
Explanation: An extract pulls data out of the source, so refreshing every 5 minutes reduces live queries while staying nearly current. The tempting wrong choice is a live connection: it is current but keeps hitting the source, so it doesn't reduce source load. Daily or never refresh cuts load more, but the data isn't almost current.

Question 4

Which condition favors a live connection even if it is slower?

  1. Current source values matter (correct answer)
  2. Users run reports repeatedly
  3. Extract refreshes hourly
  4. Source is offline at night
Explanation: Live connections query the source directly, so they reflect real-time values when freshness is critical. The tempting wrong choice is users run reports repeatedly, but that favors an extract for speed and performance, not a live connection. Hourly refreshes and an offline source also describe extract scenarios.

Question 5

An extract is refreshed at 2 a.m.; the source goes offline at 3 a.m. What happens?

  1. It shows current live data
  2. It must wait for refresh
  3. It opens with 2 a.m. data (correct answer)
  4. It becomes a live connection
Explanation: Because an extract is a saved snapshot, your workbook loads the last refreshed data regardless of what happens to the source later. The source going offline at 3 a.m. doesn't affect the already-created 2 a.m. file. The tempting mistake is thinking it shows current live data, but an extract isn't a live connection, so it can't fetch newer or real-time values.

Question 6

An analyst creates an extract containing customer records and publishes it to Tableau Server. The analyst later loses permission to the original database, but the published extract has not been refreshed or removed. A colleague still has permission to view the published data source in Tableau Server.

What should an administrator expect?

  1. The colleague can continue querying the extract because its stored data is governed by Tableau permissions until it is replaced or removed. (correct answer)
  2. The colleague immediately loses access because every extract query revalidates the creator's current permissions against the original database.
  3. The extract remains accessible, but all customer fields automatically become null when the creator's database permission is revoked.
  4. The data source automatically changes to a live connection and prompts the colleague for database credentials on the next interaction.
Explanation: When you see a question about Tableau extracts and permissions, the key distinction to keep in mind is that an extract is a snapshot of data stored within Tableau's own infrastructure — it is not a live window into the source database. Understanding this separation between the extract file and the original data source is everything here. Because an extract is a self-contained copy published to Tableau Server, access to it is governed entirely by Tableau Server permissions, not by the creator's current standing with the underlying database. Once published, the extract lives independently. So if the analyst who created it loses database access, that has zero effect on the extract already sitting on the server. A colleague with proper Tableau Server permissions — like view access to the published data source — can continue querying it without interruption. That makes A the correct answer. B is a common misconception: it conflates extracts with live connections. Live connections do route queries through the original database and can be affected by credential changes, but extracts don't re-query the source at all during normal use — only during a scheduled refresh. C invents behavior that simply doesn't exist in Tableau; revoking database permissions has no mechanism to nullify field values inside an already-published extract. D describes an automatic failover to a live connection, which Tableau does not do — switching connection types is a deliberate, manual action, not an automated response to a permissions change. A useful rule of thumb: extract = copy, live = conduit. On the Tableau exam, whenever you see a scenario involving permission changes or database access loss, ask yourself which connection type is in play — that single distinction usually unlocks the correct answer.

Question 7

A source contains ten years of transaction-level data. An executive workbook needs only the most recent two years and displays results exclusively by month, region, and product category. Executives accept a nightly snapshot, but extract size and dashboard speed are concerns.

Which strategy best aligns the extract with the workbook's actual analytical requirements?

  1. Create a transaction-level extract of all ten years so future detail remains available even though the workbook does not currently use it.
  2. Create a transaction-level extract limited to two years and hide unused fields so that Tableau automatically rolls up the stored rows to the displayed level.
  3. Use a live connection to all ten years because live connections automatically surface only the aggregated data displayed in each view.
  4. Create a filtered, aggregated extract covering two years at the month, region, and product-category grain, then schedule a nightly refresh. (correct answer)
Explanation: When designing a Tableau extract, you should always match the extract's grain and scope to what the workbook actually needs — not what it might need someday. Three levers matter here: row filter (limit date range), field filter (remove unused columns), and aggregation (pre-roll data to the displayed level of detail). Using all three together produces the smallest, fastest extract possible. Option D is correct because it applies all three levers precisely. Filtering to two years eliminates 80% of the rows upfront. Aggregating to the month/region/category grain collapses potentially millions of transactions into a compact summary table. A nightly scheduled refresh satisfies the accepted latency. The result is a small, fast extract perfectly sized to the workbook's actual requirements. Option A fails because storing ten years of transaction-level detail serves no purpose the workbook uses. Larger extracts mean slower queries and longer refresh times — you're paying a real performance cost for hypothetical future value. Option B contains a critical misconception: hiding fields in Tableau does not cause it to automatically aggregate the underlying stored rows. Hidden fields are simply excluded from views, but the rows remain at full transaction grain, so the extract stays large and slow. Option C misunderstands live connections — they query the full underlying dataset on demand and do not filter or aggregate automatically based on what's displayed. A live connection to ten years would be slower, not smarter. Study tip: On extract design questions, always ask: what is the displayed grain, and what is the time scope the workbook actually uses? The ideal extract matches both exactly — never store more than the analysis requires.

Question 8

A manufacturing dashboard is used during overnight database maintenance. Users may view data from the previous successful daily load during that period, but the dashboard must remain available even when the production database cannot accept queries.

Which design best supports this availability requirement?

  1. Use a live connection with embedded credentials because stored credentials allow queries while the database is unavailable.
  2. Use a live connection with workbook caching because cached results guarantee every dashboard interaction remains available offline.
  3. Use a live connection and increase the query timeout so Tableau waits until database maintenance has been completed.
  4. Use a refreshed extract so the last stored snapshot can remain queryable during temporary source-database downtime. (correct answer)
Explanation: When a question describes a scenario where the data source may become temporarily unavailable, your focus should shift to data independence — how can Tableau serve the dashboard without relying on a live connection to the source system? This is exactly what extracts are designed for. An extract is a snapshot of your data stored locally within Tableau (as a .hyper file). Once refreshed, it exists independently of the source database. So when overnight maintenance takes the production database offline, users can still query that extract freely — they simply see data from the last successful refresh, which the passage explicitly allows. Option D is the correct design because it matches both requirements: the dashboard stays available, and users see the most recent valid data load. Option A fails because embedded credentials solve an authentication problem, not an availability one. If the database cannot accept queries at all, credentials are irrelevant — there is simply no database to authenticate against. Option B confuses Tableau's workbook-level caching with true offline capability. Workbook caching speeds up repeated interactions during an active session but does not make the dashboard queryable when the underlying live connection is broken. Option C is perhaps the most tempting trap: increasing query timeout just makes Tableau wait longer for an unresponsive database. It does not resolve the downtime — it only delays the inevitable failure, often frustrating users in the process. Your study takeaway: whenever a question mentions source-system downtime or offline availability, think extract first. Live connections of any kind — regardless of credentials, caching, or timeouts — depend on the source being reachable.

Question 9

A Tableau Server site is connected to a database across a high-latency wide-area network. With a live connection, each filter action is slow even though the database executes the SQL quickly. Data changes once each night, and transferring the required data once per day is acceptable.

Which change most directly addresses the source of the interactive delay?

  1. Retain the live connection and disable caching so each filter action retrieves a newly transmitted result from the database.
  2. Retain the live connection and reduce the database query timeout so slow network responses terminate more quickly.
  3. Create a nightly extract on Tableau Server so the wide-area transfer occurs during refresh rather than during each interaction. (correct answer)
  4. Create an extract but store it beside the remote database so dashboard interactions continue crossing the same network path.
Explanation: Whenever you see a question about slow dashboard performance, your first instinct should be to diagnose where the bottleneck actually lives. Here, the passage explicitly tells you two things: the database executes SQL quickly, and the network is high-latency. That distinction is the entire key to the question. Since the delay comes from data traveling across a slow wide-area network on every filter interaction, the fix is to eliminate that repeated crossing — not to optimize the query itself. Option C does exactly this: a nightly extract pulls the data once across the WAN during a scheduled refresh, then stores it on Tableau Server. From that point forward, every filter action queries a local extract file, so interactive speed is no longer held hostage by network latency. Because data only changes once per night, a daily extract schedule perfectly matches the business requirement. Option A makes things worse, not better. Disabling caching forces more round-trips across the slow network, compounding the very problem you're trying to solve. Option B targets query timeout, which is a dead end — the database is already fast; the delay is in transmission, not execution time. Shortening the timeout would only cause more failures, not faster responses. Option D creates an extract but stores it next to the remote database, so dashboard interactions still cross the same high-latency WAN path. It captures none of the performance benefit of a local extract. A reliable study tip: on performance questions, always separate query speed from data transfer speed. They look similar but require completely different solutions, and Tableau exams love to blur that line.

Question 10

A workbook calculation invokes a proprietary database function through pass-through SQL. The function uses the database session context and must be reevaluated whenever a user changes a dashboard parameter. Tableau's extract engine does not implement an equivalent function.

Which connection choice best preserves the required calculation behavior?

  1. Use a live connection so parameter-driven queries can invoke the proprietary function in the source database at interaction time. (correct answer)
  2. Use an extract because Tableau automatically translates every proprietary database function into an equivalent extract-engine function.
  3. Use an extract and refresh it after publication because refreshes make unsupported source functions available during later interactions.
  4. Use either connection because connection type affects data freshness but never affects where calculations are evaluated.
Explanation: Whenever you see a question about pass-through SQL or proprietary database functions, ask yourself one critical question: where does this calculation actually execute? Pass-through functions (written with RAWSQL or similar syntax) are sent directly to the source database engine — Tableau never interprets them itself. This means the behavior is entirely dependent on maintaining a live connection to that database. A is correct because a live connection routes every query — including parameter-driven ones — back to the source database at the moment of interaction. The proprietary function runs in its native environment, with full access to session context, exactly when the user triggers it. This preserves the calculation's behavior completely. B is wrong because Tableau makes no such guarantee. Extracts use Tableau's own Hyper engine, which implements a defined set of functions. If the source function has no Hyper equivalent (as the passage explicitly states), Tableau cannot translate it — it simply fails or errors. There is no automatic translation layer for proprietary functions. C is wrong for a similar reason. Refreshing an extract copies data from the source into Hyper — it does not copy the source database's function library. After a refresh, queries still run against Hyper, where the unsupported function remains unavailable. D is wrong because connection type absolutely affects where calculations are evaluated, not just data freshness. Live connections calculate at the source; extracts calculate in Hyper. For any calculation that depends on source-specific functionality, this distinction is decisive. Your study tip: when a question mentions RAWSQL, pass-through functions, or "the extract engine does not support," that's your signal that only a live connection can guarantee correct behavior.

Question 11

A database applies row-level security using each viewer's database identity. Security assignments can change during the day and must take effect on the viewer's next dashboard query. The organization wants the database—not a replicated Tableau entitlement table—to remain the authoritative policy engine.

Which connection and authentication approach best meets the requirement?

  1. Use an extract with workbook filters because database security changes automatically update those filters without requiring a refresh.
  2. Use a nightly-refreshed extract with one shared service account so the database policy is reevaluated for each viewer interaction.
  3. Use a live connection authenticated as each viewer so the database enforces its current row-level policy on every query. (correct answer)
  4. Use a live connection with one shared service account because Tableau substitutes each viewer's database identity at query time.
Explanation: When a question pairs "row-level security" with "must take effect immediately" and "database remains the authority," you should focus on two variables: connection type (live vs. extract) and authentication identity (viewer vs. shared account). Both matter, and only one combination satisfies all three requirements simultaneously. A live connection authenticated as each individual viewer is the correct approach (C). Because the connection is live, every query hits the database in real time — there's no cached snapshot that could lag behind a policy change. Because Tableau passes each viewer's own database credentials, the database engine evaluates its current row-level security rules for that specific identity on that specific query. The database stays authoritative, changes are immediate, and no Tableau-side entitlement table is needed. Choice A fails on two counts: extracts are static snapshots, and workbook filters are a Tableau-side enforcement mechanism, not a database-side one. Policy changes in the database do not automatically ripple into extract filters — a refresh is always required. Choice B uses a nightly-refreshed extract, which directly contradicts "must take effect on the viewer's next dashboard query" throughout the day. A single shared service account also bypasses per-user database identity entirely, so the database cannot apply individual row-level policies. Choice D describes a live connection, which is promising, but the shared service account is the fatal flaw. The database sees only one identity regardless of who is actually viewing the dashboard, so its row-level policy cannot distinguish between users — defeating the entire purpose. As a study tip: whenever you see row-level security controlled by the database, the answer almost always requires both a live connection and per-viewer authentication. Changing either one breaks the chain.

Question 12

A dashboard queries a cloud data warehouse. The underlying data changes only after a nightly ETL process. During business hours, hundreds of users apply filters, causing repeated warehouse queries and variable response times. Users agree that one consistent post-ETL snapshot per day is sufficient.

Which design most directly improves interactivity while preserving the agreed data currency?

  1. Use a live connection and shorten Tableau's query-cache lifetime so every filtering action reaches the warehouse.
  2. Create an extract after the nightly ETL and direct daytime dashboard interactions to the refreshed extract. (correct answer)
  3. Use a live connection and add more dashboard filters so the warehouse receives smaller but more frequent queries.
  4. Create an extract before the nightly ETL and refresh workbook thumbnails after the ETL process finishes.
Explanation: When a question pairs data freshness requirements with performance under heavy user load, you should immediately think about the live connection vs. extract tradeoff. The key question is: does the use case actually need real-time data, or just reliably current data? Here, the data only changes once per day after an ETL process, and users have explicitly agreed that one daily snapshot is sufficient. That means you can avoid the warehouse entirely during business hours. The optimal design is B: schedule an extract refresh immediately after the nightly ETL completes, then serve all daytime filter interactions from that extract. Tableau extracts are highly optimized columnar files stored locally (or on Tableau Server/Cloud), so filtering is nearly instantaneous and never touches the warehouse. You get consistent, post-ETL data and fast interactivity — both requirements satisfied cleanly. A is a trap because shortening the query-cache lifetime does the opposite of helping — it forces more warehouse queries, worsening the variable response times that are already the problem. C compounds the same mistake: adding more filters doesn't reduce warehouse load, it increases query frequency. Smaller queries don't solve the bottleneck of repeated round-trips to a cloud warehouse under concurrent user load. D is subtly wrong in its timing — creating the extract before the ETL means you're capturing stale, pre-update data, which violates the requirement for a post-ETL snapshot. Refreshing thumbnails afterward is cosmetic and unrelated to query performance. A useful pattern to remember: whenever a question describes infrequent data changes + heavy interactive use, that's almost always a signal that an extract with a scheduled refresh is the right tool.

Question 13

A retailer's fraud-monitoring dashboard must show committed transactions no more than two minutes after they enter the operational database. The database can return dashboard queries in about ten seconds, but administrators do not want analytical traffic competing with checkout transactions. A read-only replica is available and remains synchronized within thirty seconds.

Which connection strategy best satisfies both the freshness and workload requirements?

  1. Use a live connection to the read-only replica so interactions query recently committed data without loading the primary database. (correct answer)
  2. Use an extract from the primary database and perform a full refresh every two minutes to maintain transaction-level accuracy.
  3. Use an hourly incremental extract from the replica and enable workbook caching to keep the dashboard within the freshness target.
  4. Use a live connection to the primary database and schedule workbook subscriptions every two minutes to distribute current results.
Explanation: When a question asks you to balance data freshness with workload isolation, you need to evaluate two dimensions simultaneously: how current the data needs to be, and which system bears the query load. The scenario sets two hard constraints — data no older than two minutes, and analytical queries kept off the primary database. A live connection to the read-only replica (A) satisfies both cleanly. The replica lags only thirty seconds, well within the two-minute window, and because it's a separate system, dashboard queries never compete with checkout transactions. This is the architectural sweet spot the question is designed around. The other options each fail at least one constraint. B uses a full extract refreshed every two minutes — even if the timing were reliable, full refreshes carry significant I/O overhead and pull directly from the primary database, violating the workload isolation requirement. C uses an hourly incremental extract, which immediately breaks the two-minute freshness target regardless of how clever the caching strategy is — you simply cannot serve fresh transactional data from an extract refreshed every 60 minutes. D connects live to the primary database, which protects freshness but directly contradicts the requirement to prevent analytical traffic from competing with checkout transactions; subscriptions don't change the underlying connection behavior. A useful pattern to remember: whenever a question mentions a read replica, it's almost always the right answer when you need both freshness and workload separation. Replicas exist precisely to offload read traffic. If you see live vs. extract questions, anchor your reasoning to the two axes — staleness tolerance and which system absorbs the load — before evaluating each option.

Question 14

A consultant must analyze project data on a laptop while traveling without network access. The source database is reachable before departure, and the consultant needs data current as of that departure time. The workbook must remain fully interactive during the trip.

Which preparation is most appropriate?

  1. Keep the live connection and save database credentials in the workbook so queries can run without a network route.
  2. Create and refresh an extract before departure, then ensure the workbook carries or can access that local extract. (correct answer)
  3. Keep the live connection and increase Tableau's cache duration so every possible offline query has a stored result.
  4. Publish the workbook with a live connection and download only static view images before leaving the network.
Explanation: Whenever you see a scenario involving offline or disconnected Tableau usage, the central question is: what data source type supports interactivity without a live network connection? That distinction — live connection vs. extract — is the heart of this question. Tableau extracts (.hyper files) are self-contained snapshots of data stored locally. When you refresh an extract before departing and embed or bundle it with the workbook, all filtering, drilling, and calculated field interactions run entirely against that local file — no database ping required. That's exactly what option B describes, making it the correct preparation for the scenario. Option A fails because credentials don't substitute for network connectivity. Even if Tableau stores your database password, it cannot execute a query against a server it cannot reach. Credentials authenticate you; they don't route packets. Option C misunderstands how Tableau's query cache works. The cache stores results of queries that have already been run, not pre-answers to every possible future interaction. You cannot guarantee that every conceivable filter combination was cached before departure, so offline interactivity remains broken. Option D gives you only static images — flat screenshots of views. Static images cannot be filtered, drilled into, or otherwise interacted with. The scenario explicitly requires the workbook to remain "fully interactive," which rules this out entirely. Study tip: On Tableau exam questions, watch for the word interactive in offline scenarios — it's your signal that a live connection won't work and an extract is the only viable path. Memorize the rule: extracts = portable, offline-ready data; live connections = network-dependent.

Question 15

A company uses a Tableau extract for an order dashboard. New orders are appended daily, but users can also correct the amount of an order or delete a duplicate order from any prior month. The dashboard must reflect all such changes each morning, and daytime queries must not reach the source.

Which approach most reliably meets these requirements?

  1. Retain the extract and run an incremental refresh nightly using the order creation date as the incremental field.
  2. Retain the extract and run a full refresh nightly so additions, historical corrections, and deletions are rebuilt. (correct answer)
  3. Change to a live connection overnight, then automatically convert the data source back to an extract each morning.
  4. Retain the extract and refresh only the workbook cache nightly because the corrected rows already exist in the extract.
Explanation: When Tableau extract questions describe data changes, your first move should be to categorize what kinds of changes are happening. Additions are easy — incremental refreshes handle those. But the moment corrections or deletions to historical records enter the picture, you need a strategy that rebuilds the entire dataset from scratch. A full nightly refresh (B) is the right approach here because it pulls every record fresh from the source, so amended order amounts and deleted duplicates are accurately reflected the next morning — regardless of which month they belong to. It also keeps the extract intact during business hours, meaning daytime queries hit the fast, local extract rather than the source system. Option A is a classic trap. An incremental refresh appends only rows where the incremental field (here, order creation date) is newer than the last refresh. A corrected order from three months ago has an old creation date, so it never gets picked up. Deletions are invisible to incremental refreshes entirely — a deleted row simply isn't appended, but the old version remains in the extract. Option C is impractical and unreliable. Toggling between live connections and extracts on a schedule isn't a supported, stable Tableau workflow, and it would still expose the source to queries during the conversion window. Option D misunderstands how extract caches work. Refreshing the workbook's query cache doesn't change the underlying extract data — corrected rows in the source system won't appear just because you cleared cached results. Study tip: On Tableau exam questions, whenever you see deletions or retroactive edits mentioned, eliminate incremental refresh immediately — full refresh is almost always the answer.