Tableau Quiz: Dashboard Versioning
10 questions · exam conditions
0:00
Dashboard VersioningQuestion 1 of 10

A finance dashboard uses a live connection to a database whose transactions can be corrected after month-end. The board requires analysts to reproduce both the calculations and the displayed values from each quarterly release. Tableau revision history is enabled for the published workbook.

Which versioning approach best satisfies the board's requirement?

Retain workbook revisions and rely on database audit logs to reconstruct each quarter when a prior release is requested.
Archive each released workbook with a dated, immutable data snapshot while maintaining the current published workbook separately.
Export each dashboard to PDF and retain the current workbook because the PDF preserves the released calculations.
Retain each database snapshot and overwrite the workbook because the snapshots preserve the released visualization logic.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Dashboard Versioning

Practice Dashboard Versioning 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 Dashboard Versioning, 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 finance dashboard uses a live connection to a database whose transactions can be corrected after month-end. The board requires analysts to reproduce both the calculations and the displayed values from each quarterly release. Tableau revision history is enabled for the published workbook.

Which versioning approach best satisfies the board's requirement?

  1. Retain workbook revisions and rely on database audit logs to reconstruct each quarter when a prior release is requested.
  2. Archive each released workbook with a dated, immutable data snapshot while maintaining the current published workbook separately. (correct answer)
  3. Export each dashboard to PDF and retain the current workbook because the PDF preserves the released calculations.
  4. Retain each database snapshot and overwrite the workbook because the snapshots preserve the released visualization logic.
Explanation: When auditing requirements demand that analysts reproduce both the calculations and the displayed values from a prior release, you need two things preserved independently: the workbook logic (formulas, views, layout) and the exact data it was running against. Neither alone is sufficient. Option B is the right approach because archiving an immutable data snapshot alongside the released workbook freezes the complete picture at that moment in time. Since the database allows post-month-end corrections, the live data will drift after each quarterly release. A dated snapshot prevents that drift from corrupting historical reproductions, while keeping the snapshot separate from the current published workbook lets ongoing work continue uninterrupted. Option A is tempting but flawed: Tableau's revision history preserves workbook versions, and database audit logs can theoretically reconstruct past states — but "theoretically" is the problem. Audit logs track changes, not snapshots; reconstructing a prior data state from them is error-prone, labor-intensive, and may not be possible if the audit log is incomplete or if corrections were applied without logging. Option C fails because a PDF captures the image of the dashboard, not the underlying calculations. A board requirement to reproduce calculations cannot be met by a static image — you cannot re-run, validate, or audit the logic from a PDF. Option D inverts the problem. Snapshots preserve data, not visualization logic. Overwriting the workbook destroys the calculation definitions, making it impossible to verify how numbers were derived. Study tip: On versioning questions, always ask separately — is the data preserved? Is the logic preserved? The correct answer must protect both.

Question 2

Release 2 changed a published data source by replacing Margin with Margin_Adjusted. Workbook revision W2 uses Margin_Adjusted, while prior revision W1 uses Margin. After deployment, the organization decides to roll back the entire release. The data source and workbook have independent revision histories.

What is the most reliable rollback procedure?

  1. Restore W1 only because a workbook revision automatically restores the data source revision used when it was published.
  2. Restore the prior data source and then W1 within a controlled maintenance window, validating the compatible pair afterward. (correct answer)
  3. Restore W1 first and leave the current data source in place because Tableau remaps renamed fields during revision restoration.
  4. Restore the prior data source only because W2 will automatically substitute Margin for the missing adjusted field.
Explanation: When managing Tableau deployments, the critical concept here is revision history independence: workbooks and published data sources each maintain their own separate version histories, and Tableau does not automatically synchronize them during a rollback. Because the data source and workbook have independent histories, restoring W1 alone does nothing to reverse the field change at the data source level. W1 still expects Margin, but if the current data source still exposes Margin_Adjusted, the workbook will break with broken field references. Answer B is correct precisely because it treats the rollback as a coordinated, two-step operation: first restore the prior data source (bringing Margin back), then restore W1, and validate that the two versions are compatible before returning to production. Doing this inside a controlled maintenance window prevents users from encountering a half-rolled-back state. Answer A is wrong because Tableau has no mechanism that automatically restores a data source revision when you restore a workbook revision — those histories are entirely independent, and assuming otherwise is a common trap. Answer C compounds this mistake by adding a false claim: Tableau does not automatically remap renamed fields during revision restoration. If Margin is missing, it simply breaks. Answer D inverts the dependency — restoring only the data source leaves W2 in place, and W2 is designed around Margin_Adjusted. There is no automatic substitution logic that would redirect the workbook to Margin. The study tip to carry forward: whenever a question involves rolling back across both a workbook and a published data source, always think in terms of a compatible pair. Neither component alone is sufficient — you must restore and validate both together.

Question 3

After a data warehouse release, a dashboard's conversion rate increases sharply. The workbook was not republished, but the governed data source changed a join and converted one key from text to number. The business team is unsure whether the increase is a valid correction or a defect.

What should the dashboard owner do first as part of controlled version maintenance?

  1. Restore the oldest workbook revision because a large metric change proves that the dashboard calculation was altered.
  2. Accept the increase because an unchanged workbook guarantees that any new result is an intended data correction.
  3. Compare old and new data-source versions in a test copy, validate record matching and KPIs, then approve or roll back. (correct answer)
  4. Republish the unchanged workbook under a new name so the metric increase becomes a documented dashboard version.
Explanation: When a governed data source changes underneath a published workbook, you're dealing with a version control and data validation problem — not just a simple publish/unpublish decision. The key principle here is that any unexplained metric shift requires investigation before acceptance or rejection, because the root cause could be either a legitimate data fix or an unintended defect. The safest and most professional first step is C: create a test copy, compare the old and new data-source versions side by side, validate that record counts and key identifiers match correctly, and confirm whether KPIs behave as expected. Only after that structured validation can you confidently approve the change or initiate a rollback. This is exactly what controlled version maintenance looks like in practice — isolate, test, then decide. A is wrong because a large metric change alone does not prove the workbook calculation changed — in this scenario, the workbook wasn't touched at all. Restoring the oldest revision without investigation could discard a legitimate data correction. B is wrong because an unchanged workbook does not guarantee a correct result; upstream data-source changes (like a type conversion or join modification) absolutely affect downstream metrics, regardless of whether the workbook was republished. D is wrong because republishing the workbook under a new name doesn't address the underlying question of whether the data itself is valid — it just creates naming noise without any actual validation. Study tip: On Tableau exam questions about data governance, watch for scenarios where the workbook and the data source change independently. Always ask: what changed, where, and has it been validated? Investigation before action is the hallmark of controlled maintenance.

Question 4

A governed published data source contains a field named Customer Tier, which is used by 25 production workbooks. The data engineering team wants to replace it with Customer Segment. Immediately removing the old field would break several workbooks, and teams cannot migrate simultaneously.

Which release sequence provides the safest versioned migration?

  1. Rename the field in place, publish the data source, and restore affected workbooks from revision history after failures occur.
  2. Add the new field while retaining the old field, migrate and validate workbooks, then deprecate the old field in a later release. (correct answer)
  3. Remove the old field, add a workbook alias with its former name, and republish all workbooks without changing calculations.
  4. Duplicate every workbook first, remove the old field immediately, and direct users to whichever workbook version still opens.
Explanation: When managing shared data sources in Tableau, the core challenge is backward compatibility — making changes without breaking dependent workbooks that you don't control all at once. Think of this like versioned API releases: you never remove something consumers depend on until they've had time to migrate. The safest approach is exactly what answer B describes. By adding Customer Segment alongside the existing Customer Tier, both fields coexist in the published data source simultaneously. Teams can migrate their workbooks on their own schedule, validate that calculations and dashboards work correctly, and only then is the old field deprecated in a later, planned release. This phased rollout eliminates forced simultaneous migration and gives you a clean rollback path at every stage. A is reactive rather than proactive — renaming in place immediately breaks any workbook referencing the original field name, and relying on revision history to recover from failures is damage control, not a migration strategy. C introduces a fundamental misunderstanding: a "workbook alias" isn't a Tableau feature that substitutes for a data source field. Removing the field breaks downstream calculations regardless of what you name things at the workbook level. D is chaotic governance — duplicating workbooks and letting users self-select which version "still opens" creates version sprawl, data inconsistency, and no clear migration endpoint. A useful rule of thumb: add before you remove. On Tableau governance questions, whenever a field or data source component is shared across many workbooks, the correct sequence is always to introduce the replacement first, validate, then retire the old component in a separate release.

Question 5

A regulated team enables Tableau revision history and concludes that no additional release records are necessary. Six months later, an auditor asks who approved a dashboard release, which governed data source revision it used, and what data snapshot supported the reported totals.

Which additional practice would have best supported the audit request?

  1. Maintain a release manifest linking approvals, workbook and data-source versions, deployment dates, and retained data snapshots. (correct answer)
  2. Retain only screenshots of each release because they preserve approval status, dependency versions, and the underlying data state.
  3. Increase the workbook revision limit because each Tableau revision automatically records business approvals and database snapshots.
  4. Store developers' local filenames because naming conventions reliably establish approval, dependency, and publication history.
Explanation: When you see audit-readiness questions on the Tableau exam, ask yourself: what information does Tableau's built-in revision history actually capture, and what gaps remain? Revision history tracks workbook edits, but it does not record who gave business approval, which specific data source version a release depended on, or what the underlying data looked like at publish time. That's the core gap this question is testing. A release manifest closes all three gaps simultaneously. It's a dedicated record — think a structured log or document — that explicitly links the approver's name, the workbook version, the governed data source revision, the deployment date, and a retained data snapshot. When the auditor asks all three questions six months later, a release manifest gives you a single traceable artifact to answer each one. That's why A is the correct and complete solution. B is wrong because screenshots capture only a visual moment — they don't encode approval metadata, dependency version identifiers, or the actual data state that produced reported totals. They look like evidence but lack technical traceability. C is wrong because increasing the workbook revision limit only preserves more edit history; Tableau revisions never automatically log business approvals or database snapshots. More revisions ≠ more governance. D is wrong because local filenames are informal, inconsistent, and entirely outside Tableau's governed environment. A naming convention is not a record — it can't prove who approved a release or which data snapshot was used. For the exam, remember: when a question involves auditability, look for the answer that addresses all audit dimensions — approval, dependency, and data provenance — not just one.

Question 6

An analyst develops a workbook in a newer Tableau Desktop release than the organization's Tableau Server version. The workbook uses several recently introduced features. Production cannot be upgraded before the scheduled dashboard release.

What should the analyst do before treating the workbook as a deployable version?

  1. Use an appropriate older-version export option, then test the exported workbook because unsupported features may change or be removed. (correct answer)
  2. Change the workbook filename to include the target server version number, then publish because Tableau reads the filename to determine which features to enable.
  3. Publish the newer workbook directly to the server because Tableau Server automatically upgrades or translates every unsupported feature to a compatible equivalent.
  4. Downgrade only the data source connection string to match the server version because workbook calculations and dashboard layout features are version-independent.
Explanation: When working across mismatched Tableau versions, the core principle to remember is this: Tableau Desktop can save workbooks in older formats, but that process is lossy — features introduced after the target version may not survive the conversion intact. This is exactly the kind of version compatibility scenario the Tableau exam loves to test. The right move is captured in A: use Tableau Desktop's "Export as Previous Version" option to produce a workbook compatible with the server's installed release, then thoroughly test it. Why test afterward? Because newer features — certain chart types, calculation functions, or formatting options — may be silently dropped, altered, or replaced with placeholders. Testing confirms the workbook still behaves as intended before it goes to production. B is a fabricated behavior. Tableau does not read filenames to determine which features to enable. Renaming a file changes nothing about its internal XML structure or feature set — this answer is pure fiction designed to catch students who don't know how Tableau actually handles versioning. C is dangerously wrong. Tableau Server does not automatically translate or upgrade unsupported features. If you publish a workbook built with features the server version doesn't recognize, those elements will fail or disappear — there is no magic compatibility layer. D is a partial-truth trap. Version compatibility affects far more than just connection strings. Calculations, viz types, dashboard layout features, and more are all tied to the workbook's version specification. Changing only the connection string leaves most compatibility issues unresolved. Study tip: Whenever you see version mismatch scenarios on the Tableau exam, think "downgrade + test" — both steps are required, not just one.

Question 7

A certified sales data source must adopt a new allocation model. The new model changes the meaning of Regional Revenue, so existing dashboards could remain technically functional while displaying materially different values. Some business units need three months to approve the new definition.

Which governance strategy best versions this semantic change?

  1. Replace the certified data source immediately and use workbook revision history if a business unit disputes the resulting values.
  2. Remove certification from the existing source, change its calculation, and recertify it after all workbook refreshes finish successfully.
  3. Keep one data source, hide the changed field from older users, and let workbook owners infer which revenue definition applies.
  4. Publish a governed version 2 alongside version 1, document the semantic change, migrate consumers, and retire version 1 later. (correct answer)
Explanation: When a semantic change alters what a field means — not just how it's calculated — you're dealing with a versioning problem, not simply a refresh problem. The key question to ask yourself is: "Can existing consumers safely keep using the old definition while new consumers adopt the new one?" If yes, parallel versioning is the right governance pattern. That's exactly what D provides. Publishing a governed version 2 alongside version 1 lets business units on a three-month approval cycle continue working against a stable, certified source while early adopters migrate to the new definition. Documenting the semantic change creates an audit trail, and retiring version 1 only after migration is complete ensures no dashboard is silently broken. A is dangerous because replacing the certified source immediately exposes all existing dashboards to the new definition without warning. Revision history is a recovery tool, not a governance strategy — it forces business units into a reactive, dispute-driven process rather than a controlled migration. B sounds procedural but has a critical flaw: removing certification, changing the calculation, and recertifying based on successful refreshes treats a semantic change as if it were only a technical one. A refresh completing without errors doesn't validate that the new meaning is correct or approved. C is arguably the worst option. Hiding fields from users and expecting them to "infer" which revenue definition applies is the opposite of governed data — it creates ambiguity, erodes trust, and violates the transparency that certification is supposed to provide. Your study takeaway: on Tableau governance questions, watch for scenarios where a change affects meaning rather than just structure. Semantic changes almost always call for parallel versioning and explicit migration paths, not in-place replacement.

Question 8

A Tableau site retains only a limited number of content revisions. A dashboard is republished frequently for minor formatting changes, but policy requires the organization to reproduce every approved year-end release for seven years.

Which maintenance plan best addresses the risk created by the revision limit?

  1. Restrict publishing rights so that only administrators can publish, reducing the total number of revisions created and preserving older year-end versions within the configured limit.
  2. Increase publishing frequency so approved year-end versions remain distributed throughout the available revision history and are less likely to be overwritten.
  3. Tag year-end revisions with a special label in Tableau so the platform identifies them as protected and excludes them from automatic revision-history pruning.
  4. Archive approved release artifacts and dependency records externally under retention controls instead of relying only on revisions. (correct answer)
Explanation: When a question describes a retention requirement that outlasts the platform's built-in revision history, your instinct should shift from "how do I configure Tableau better?" to "how do I preserve this data outside of Tableau?" That mental pivot is the key to this question. Tableau's revision history is a finite, rolling window — once you hit the configured limit, older revisions are automatically pruned. If a dashboard is republished frequently for minor tweaks, year-end versions will eventually fall off that window long before the seven-year policy requirement is met. The only reliable solution is D: exporting approved release artifacts (the packaged workbook, data source connections, and relevant metadata) to an external system governed by proper retention controls — file storage, a document management system, or similar. That way, preservation is completely decoupled from Tableau's revision cap. A is tempting because restricting publishing slows revision accumulation, but it doesn't stop it. Given seven years of ongoing publishing, even a reduced rate will eventually push year-end versions out of the history window. You're just delaying the problem. B is the opposite trap — increasing publishing frequency actually accelerates how quickly older revisions are overwritten. Distributing approved versions throughout history doesn't protect them; it just makes them harder to find before they disappear. C describes a feature that doesn't exist in Tableau. There is no native mechanism to flag a revision as "protected" and exempt it from pruning. Selecting this answer reflects a wishful-thinking trap common on platform-specific exams. When a retention requirement exceeds what any platform's native versioning can guarantee, always look for the answer that moves responsibility to an external, purpose-built archival system.

Question 9

A production dashboard is embedded in an internal portal and has hundreds of subscriptions. A corrected release must preserve its existing URL and consumer access. Administrators also require a quick return to the preceding release if validation fails.

Which publication plan best meets these requirements?

  1. Publish the correction under a new workbook name, then update the portal and recreate subscriptions after users validate it.
  2. Delete the production workbook, publish the corrected file with the old name, and use the Recycle Bin as rollback protection.
  3. Validate in a nonproduction location, then overwrite the production workbook with revision history enabled and confirm the release. (correct answer)
  4. Replace only the portal's embedded link with a local workbook file while retaining the published workbook for subscriptions.
Explanation: When managing published workbooks in Tableau Server or Cloud, the core challenge is balancing safe deployment with zero disruption to existing consumers. Anytime a question mentions preserving URLs, subscriptions, and needing rollback capability, you should immediately think about revision history and in-place publishing. Overwriting a workbook in its original project location — with the same name — preserves its LUID (the internal identifier Tableau uses to anchor embedded URLs and subscriptions). When revision history is enabled, Tableau automatically stores prior versions, giving administrators a one-click rollback path if validation fails. This is exactly what C describes: validate safely in a nonproduction environment first, then overwrite the production workbook in place, confident that history protects you. A breaks everything it's trying to save. Publishing under a new name creates a new LUID, which orphans the portal's embedded link and invalidates every subscription — you'd have to manually recreate hundreds of them, which is exactly the disruption the scenario forbids. B is dangerously unreliable. Deleting the workbook destroys its subscriptions outright before the Recycle Bin can help; the Recycle Bin also isn't a guaranteed, admin-controlled rollback mechanism the way revision history is. This approach introduces unnecessary risk. D creates a split state — the portal shows a local file while subscriptions point to the published workbook — meaning the two audiences see different content. This undermines data consistency and is operationally unsustainable. For the exam, remember this pattern: same URL + subscriptions + rollback = overwrite in place with revision history. That combination is always your signal to choose the in-place publish option.

Question 10

Two developers download the same production workbook. One revises parameters and calculations; the other redesigns device layouts. Each later publishes to the same workbook name. The second publication silently replaces the first developer's changes.

Which process change most directly prevents this versioning problem while supporting parallel work?

  1. Increase the number of retained revisions so Tableau can automatically merge changes from independently published workbook files.
  2. Give each developer a separate working copy and require an assigned integrator to combine, test, and promote one release candidate. (correct answer)
  3. Require both developers to publish more frequently so the latest production revision contains smaller sets of conflicting changes.
  4. Disable workbook downloads and have both developers edit the same published workbook simultaneously through web authoring.
Explanation: When a question describes two people unknowingly overwriting each other's work, you're being tested on version control and release management workflows — specifically, how teams coordinate parallel development without data loss. The root problem here isn't how often people publish or how many revisions Tableau retains — it's that there's no coordination gate between individual work and the shared production workbook. The fix that directly addresses this is B: giving each developer an isolated working copy and routing all changes through a single integrator. That person reconciles the two sets of changes, validates the combined result, and promotes only one approved version. This eliminates silent overwrites because no one publishes directly to production independently. A is tempting but wrong — Tableau's revision history lets you restore previous versions manually, but it has no automatic merge capability. More retained revisions don't prevent the collision; they just give you more history to sift through after the damage is done. C misunderstands the problem. Publishing more frequently doesn't prevent two developers from still overwriting each other — it just means the conflicts happen more often and in smaller batches. The race condition still exists. D would actually make things worse. Simultaneous web authoring on the same published workbook creates real-time conflicts with no structured resolution path, and disabling downloads removes a legitimate workflow tool entirely. Study tip: On Tableau exam questions about multi-developer workflows, look for answers that introduce a coordination mechanism (like an integrator or gated review process) rather than answers that just tweak frequency or storage settings — those treat symptoms, not causes.