Tableau Quiz: Publishing To Server
10 questions · exam conditions
0:00
Publishing To ServerQuestion 1 of 10

An analyst has a Creator site role and can sign in to Tableau Server. The analyst can open the Finance project but receives a permissions error when attempting to publish a new workbook there.

What is the most likely additional requirement for the analyst to publish successfully?

The analyst must receive the Download Workbook capability on every existing workbook in the Finance project.
The analyst must receive the Publish capability on the Finance project, because the Creator site role alone does not guarantee project-level publishing access.
The analyst must become the Project Leader of the Finance project before publishing any new content there.
The analyst must be granted the View capability on the local workbook file before connecting to Tableau Server.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Publishing To Server

Practice Publishing To Server 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 Publishing To Server, giving you a quick way to practice the rules, question types, and explanations that matter most for Tableau.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

An analyst has a Creator site role and can sign in to Tableau Server. The analyst can open the Finance project but receives a permissions error when attempting to publish a new workbook there.

What is the most likely additional requirement for the analyst to publish successfully?

  1. The analyst must receive the Download Workbook capability on every existing workbook in the Finance project.
  2. The analyst must receive the Publish capability on the Finance project, because the Creator site role alone does not guarantee project-level publishing access. (correct answer)
  3. The analyst must become the Project Leader of the Finance project before publishing any new content there.
  4. The analyst must be granted the View capability on the local workbook file before connecting to Tableau Server.
Explanation: When troubleshooting publishing errors in Tableau Server, you need to think in two layers: site role and project-level permissions. A site role like Creator sets the ceiling of what a user can potentially do — it doesn't automatically grant access to every project. Project permissions are configured separately and can restrict or allow specific capabilities like View, Publish, or Delete within individual projects. This is exactly what's happening in the scenario. The analyst has a Creator site role, which is a prerequisite for publishing, but the Finance project's permissions haven't been configured to allow this analyst to publish there. The missing piece is the Publish capability at the project level — confirming that B is correct. Site role alone is never sufficient; the project must also grant publishing rights. A is wrong because downloading existing workbooks is completely unrelated to your ability to publish new content. Those are separate capabilities that address different actions entirely. Conflating them is a common trap. C is a trap that overstates what's required. Project Leader is a powerful role, but it is not the only way to gain publish access. A user can be granted the Publish capability directly without becoming a Project Leader. The question asks for the most likely requirement, not the most powerful solution. D describes a concept that doesn't exist in Tableau's permission model. Local file permissions on your desktop have no bearing on what you can do within Tableau Server — Tableau Server manages its own access controls independently. Study tip: Always think of Tableau permissions as a two-key system — site role unlocks the door to the building, but project permissions control access to each room.

Question 2

A live database connection works in Tableau Desktop on an analyst's computer. The workbook publishes successfully, but users receive a connection error when opening it on Tableau Server. The analyst's computer reaches the database through a local VPN.

Which issue should be investigated first?

  1. Whether all viewers have Tableau Desktop installed so their computers can execute the published workbook's live queries.
  2. Whether the workbook was published with Show Sheets as Tabs enabled for every worksheet that queries the database.
  3. Whether the published workbook contains an extract refresh schedule, even though its data connection remains live.
  4. Whether Tableau Server has the required driver, network route, and database authentication independent of the analyst's computer. (correct answer)
Explanation: When a workbook works locally but breaks after publishing to Tableau Server, you're being tested on a fundamental architecture concept: Tableau Server executes live queries independently, using its own network stack, drivers, and credentials — not the analyst's machine. The analyst's computer reaches the database through a local VPN. That VPN tunnel, the database drivers installed locally, and any saved credentials exist only on that machine. Once the workbook is published, Tableau Server becomes the query engine. If Server can't reach the database (no network route, missing driver, or invalid credentials), users get exactly the connection error described. That's why D is the right first investigation — it targets the three most common root causes of this exact failure pattern: driver installation on Server, network accessibility from Server's environment, and database authentication configured for Server's service account. A is a misconception about how Tableau works. Viewers never need Tableau Desktop; Server handles all query execution on their behalf. B is a red herring — "Show Sheets as Tabs" is a publishing display option that controls workbook navigation, not data connectivity. It has no effect on whether a live connection succeeds or fails. C conflates two separate concepts: extract refresh schedules apply to extracts, not live connections. A live connection has no refresh schedule, so this setting is irrelevant to the error. A useful pattern to remember: whenever you see "works on my machine, fails on Server," your first mental checklist should be driver → network → credentials, all evaluated from Server's perspective, not the analyst's.

Question 3

A production workbook already has subscriptions and links distributed to users. Its publisher has corrected several calculations in Tableau Desktop. The workbook's project, name, and published view names will remain unchanged.

Which action is most appropriate when the existing production item should be updated rather than duplicated?

  1. Publish the workbook under a new name, then delete the original item so Tableau automatically redirects all existing references.
  2. Publish the workbook to another project, then move the original workbook over the new copy to merge both items.
  3. Publish to the same project with the same workbook name and confirm that the existing workbook should be overwritten. (correct answer)
  4. Download the existing workbook from Server and rename its local file before publishing the corrected workbook beside it.
Explanation: When you need to update a published workbook without breaking existing subscriptions, saved links, or embedded references, the key concept is in-place overwriting. Tableau Server identifies workbooks by their project location and name — so publishing to the exact same destination replaces the content while preserving everything attached to that item's identity. That's precisely why C is correct. Publishing to the same project with the same workbook name prompts Tableau to ask whether you want to overwrite the existing workbook. Confirming the overwrite updates the content — corrected calculations and all — while keeping the workbook's URL, subscriptions, and shared links fully intact. Users experience a seamless update with no broken references. A is a trap because Tableau does not automatically redirect references when you delete an item. Deleting the original breaks every existing subscription and link, and the new workbook starts with a clean slate — meaning all that distribution work is lost. B describes a workflow that doesn't exist in Tableau. You cannot "move one workbook over another to merge them." Moving a workbook changes its project location, which changes its URL, and there is no merge functionality between two separate published items. D is counterproductive. Renaming the local file before publishing creates a new workbook with a different name on the server, leaving the original outdated workbook sitting alongside it. You'd end up with duplicates rather than an update — exactly the outcome the question tells you to avoid. A useful rule of thumb: if the goal is to update without duplicating, same project + same name + overwrite is always the right path on the Tableau exam.

Question 4

A team must test a redesigned connection and renamed fields for a widely used published data source. Overwriting the production source immediately could break dependent workbooks, and the team wants a controlled validation period before deployment.

Which publishing strategy best limits risk to current consumers?

  1. Overwrite the production data source first, then rely on revision history to recover previous metadata if dependent workbooks fail.
  2. Publish the redesigned source under a distinct name or to a test project, validate it with test workbooks, and overwrite production only after confirming success. (correct answer)
  3. Embed the redesigned source in one production workbook, because embedded sources automatically propagate changes back to the shared published source.
  4. Deny Connect on the production source, overwrite it with the redesigned version, and restore access once users report whether their workbooks function correctly.
Explanation: When managing published data sources in Tableau, the core principle is protecting existing consumers from unintended breakage. Anytime you see a question about modifying a shared data source with dependent workbooks, ask yourself: "What happens to everyone already connected if this change goes wrong?" The safest path — and the logic behind answer B — is staging your changes in isolation before touching production. By publishing the redesigned source under a new name or to a test project, you create a sandbox where you can validate connections, field renames, and calculated fields against test workbooks. Only after confirming everything works do you overwrite the production source. This gives you a controlled validation window with zero disruption to current users. Answer A sounds like it has a safety net, but revision history is a recovery tool, not a prevention tool. You'd still break dependent workbooks first and scramble to fix them afterward — exactly the risk the scenario asks you to avoid. Answer C contains a fundamental misconception: embedded data sources are copies stored inside a workbook and do not propagate changes back to a published shared source. Embedding something in one workbook changes nothing for other consumers. Answer D is particularly harmful — revoking Connect permissions on a live production source disrupts all current users immediately, and using their error reports as your QA process is reactive chaos, not controlled validation. Study tip: On Tableau exam questions about publishing strategy, watch for answers that treat "fixable after the fact" as equivalent to "safe." The exam consistently rewards approaches that prevent disruption over approaches that merely recover from it.

Question 5

Three workbooks use separate local connections to the same sales database. The governance team wants one connection definition, one set of credentials, and centrally managed metadata. Changes to the governed connection should be available to all three workbooks without republishing each workbook.

Which publishing approach best meets the governance team's requirements?

  1. Package each workbook with its local connection and publish all three workbooks to the same governed project.
  2. Publish one workbook first, then download its packaged connection and add that connection separately to the other workbooks.
  3. Publish the connection as a shared data source, replace each local connection with that published source, and then publish the workbooks. (correct answer)
  4. Embed identical database credentials in each workbook and use matching workbook descriptions to identify the governed connection.
Explanation: When a question asks about centralizing connection management so that changes propagate automatically without republishing workbooks, you should immediately think about published data sources in Tableau. A published (shared) data source lives on Tableau Server or Cloud as its own independent object — it holds the connection definition, credentials, and metadata in one place. Any workbook connected to it inherits updates the moment they're made. That's exactly why C is correct. By publishing the connection as a shared data source and then pointing all three workbooks to it, you satisfy every requirement: one connection definition, one credential store, centrally managed metadata, and automatic propagation of changes to all downstream workbooks without touching each workbook individually. A misses the core need. Packaging local connections inside each workbook keeps the connection definitions siloed inside those files. Changes to one workbook's connection don't affect the others, and you'd have to republish each workbook manually to update anything. B is a procedural workaround, not a governance solution. Copying a packaged connection file across workbooks still creates three separate local connections — you haven't centralized anything. Each copy is independent after the initial setup. D doesn't create any actual technical link between the workbooks. Matching descriptions are metadata labels for human readers, not a mechanism Tableau uses to synchronize credentials or connection definitions. Embedding credentials in each workbook also increases security exposure rather than reducing it. A helpful pattern to remember: on Tableau exam questions, any time you see the words "centrally managed," "single source," or "changes without republishing," the answer almost always involves a published data source.

Question 6

A workbook contains an extract from a password-protected database. It is published successfully, but its scheduled refresh fails because the database requests interactive authentication. Security policy permits a dedicated database service account to be stored for refreshes.

Which publishing configuration most directly supports unattended scheduled refreshes?

  1. Publish the extract with Prompt User authentication and ask each viewer to enter the service account password.
  2. Convert the extract to a live connection so Tableau Server no longer needs database authentication during refreshes.
  3. Embed the permitted service-account credentials for the connection and configure an appropriate server refresh schedule. (correct answer)
  4. Sign in to Tableau Server with a personal access token and use that token as the database password.
Explanation: When a scheduled refresh fails due to interactive authentication, the core issue is that Tableau Server needs stored credentials it can use autonomously — no human present, no prompts, no manual input. Think of this as the "unattended handshake" problem: the server must be able to authenticate to the database on its own, on a schedule, without anyone intervening. Embedding the service-account credentials directly in the published data source connection solves this cleanly. When you embed credentials, Tableau Server stores them securely and presents them automatically during each scheduled refresh. Since the security policy explicitly permits a dedicated service account for this purpose, option C is both technically correct and policy-compliant. The refresh runs unattended exactly as designed. Option A fails immediately because "Prompt User" authentication requires a human to interactively supply credentials at refresh time — the opposite of unattended. Scheduled jobs have no mechanism to respond to a credential prompt, so the refresh would simply fail again. Option B misunderstands the problem. Switching to a live connection doesn't eliminate authentication requirements; the server still needs to authenticate to the database for every query. Worse, live connections introduce latency and don't resolve the underlying credential storage issue. Option D confuses two completely separate systems. A personal access token authenticates you to Tableau Server — it has nothing to do with the database's authentication system and cannot serve as a database password. Study tip: On Tableau exam questions about refresh failures, always ask: "Who authenticates to what?" Tableau Server authenticating to itself (PAT) and Tableau Server authenticating to a database (embedded credentials) are entirely different layers — don't let the word "authentication" conflate them.

Question 7

A workbook uses a published data source. A user has permission to view the workbook, and the database credentials are embedded in the published data source. However, the user is denied the Connect capability on that published data source and cannot open the workbook successfully.

Which change most directly resolves the problem while avoiding unnecessary authoring privileges?

  1. Grant Web Edit on the workbook while leaving the published data source's Connect capability denied.
  2. Grant Connect on the published data source while continuing to restrict capabilities such as download or overwrite. (correct answer)
  3. Grant Download Workbook so the user can open a local copy that bypasses published data source permissions.
  4. Transfer ownership of the published data source to the user while leaving the Connect capability denied.
Explanation: Whenever you see a permission conflict in Tableau Server or Cloud, train yourself to identify the minimum change that resolves the access gap without granting broader privileges than necessary. Here, the root problem is clear: the user lacks the Connect capability on the published data source, which is required to load any workbook that references it — even if database credentials are already embedded. Granting Connect on the published data source (B) directly removes the blocker. You can do this while keeping all other capabilities — like Download, Overwrite, or Edit — denied. The user gets exactly what they need to view the workbook, nothing more. Looking at the distractors: A is tempting because Web Edit sounds like it might bypass the issue, but Web Edit is an authoring privilege that lets users modify the workbook in a browser. It doesn't override a denied Connect capability on the data source — the workbook still can't load its data. C suggests granting Download Workbook so the user can work locally, but this sidesteps the actual permission model and introduces unnecessary risk by letting the user export the workbook entirely. It also doesn't fix the root cause. D transferring ownership is a drastic administrative action — it changes who controls the data source, but ownership alone doesn't grant Connect if that capability remains explicitly denied. The user still can't connect. The study pattern to remember: capabilities on published data sources are evaluated independently from workbook permissions. A user must satisfy both layers. When troubleshooting access, always check the data source's Connect capability first — it's the most commonly overlooked permission in Tableau's layered model.

Question 8

A manager publishes only a dashboard from a workbook and clears Show Sheets as Tabs. One worksheet supporting the dashboard contains sensitive row-level details. The manager assumes users cannot access those details because the worksheet has no visible tab.

Which assessment is most accurate?

  1. Hiding worksheet navigation is not a security control; the publisher must enforce data security and restrict relevant viewing or download capabilities. (correct answer)
  2. Clearing Show Sheets as Tabs automatically removes all underlying worksheet data from the published workbook and its downloads.
  3. Publishing only the dashboard converts every supporting worksheet into an image, preventing users from accessing underlying data.
  4. Hidden worksheets are secured automatically, but only when the publisher embeds database credentials during the same operation.
Explanation: Whenever you see a question about Tableau publishing and access control, pause and ask yourself: does this configuration actually restrict data, or does it only change what's visible in the interface? That distinction is everything here. Hiding worksheet tabs is a cosmetic change, not a security measure. When a manager publishes only a dashboard and clears "Show Sheets as Tabs," the underlying worksheet data is still embedded in the workbook on Tableau Server or Cloud. A sufficiently motivated user can access that data through custom views, the REST API, or by downloading the workbook and opening it in Tableau Desktop. True data security requires explicit controls: row-level security at the data source, restricting the "Download" permission on the published content, or using filtered data sources. Answer A captures this precisely — hiding navigation provides no data protection, and the publisher must implement real security mechanisms. Answer B is wrong because clearing the tab setting does nothing to strip or remove underlying data from the workbook. The worksheets and their data remain intact. Answer C is a common misconception — publishing a dashboard does not convert supporting sheets into flattened images. The live data connections and underlying worksheets are preserved and can still be queried. Answer D invents a fictional security behavior; embedding database credentials affects authentication to the data source, not whether hidden worksheets become secured. A useful study habit: whenever a Tableau question mentions hiding, collapsing, or visually obscuring something, treat that as a UI change only — never a security guarantee. Real security in Tableau lives in permissions, row-level filters, and download restrictions.

Question 9

A production project has locked permissions managed at the project level. While publishing a workbook, its owner attempts to grant a contractor broader access than the contractor receives from the project's permission rules.

What should the owner expect after publishing the workbook?

  1. The locked project rules will govern the workbook, so an administrator must change the project rules or use another appropriate project. (correct answer)
  2. The workbook-specific permissions selected during publishing will override the project rules because the publisher owns the workbook.
  3. The contractor will receive temporary access until the project's next scheduled permission synchronization is completed.
  4. The workbook will inherit project permissions initially, but its owner can unlock only that workbook after publication.
Explanation: Whenever you see a question about Tableau permissions involving locked projects, focus on one core principle: locked projects centralize permission control, and that control is absolute. In Tableau, a project set to Locked means all content within it inherits permissions strictly from the project level — no exceptions for individual workbooks, and no exceptions for ownership. When a publisher tries to grant a contractor broader access during the publishing workflow, Tableau simply does not honor those overrides. The project rules win, every time. The only paths forward are for an administrator to modify the project-level permissions themselves, or to publish the workbook into a different project where appropriate access can be granted. That makes A the correct answer — it accurately reflects how locked project governance works and correctly identifies who has the authority to change it. B is wrong because workbook ownership does not grant the ability to override locked project permissions. Ownership affects things like the ability to move or delete a workbook, but it does not bypass project-level security controls. C is entirely fabricated. Tableau has no concept of "scheduled permission synchronization" — there is no temporary access window or synchronization cycle that governs permissions this way. D is a subtle trap. While it's true that workbooks in a Customizable project can have individual permissions adjusted post-publication, a Locked project does not allow any individual workbook to be "unlocked" separately. The lock applies to all content uniformly. Study tip: Memorize the two project permission modes — Locked and Customizable — and what each allows. Exam questions almost always hinge on that distinction.

Question 10

A company uses Tableau Cloud and wants to publish an extract based on a database located inside its private corporate network. The database cannot accept inbound connections from the public internet, but the extract must refresh nightly.

Which architecture best supports this publishing requirement?

  1. Publish the extract with a live connection and rely on each viewer's corporate VPN to route Tableau Cloud queries.
  2. Package the database driver inside the workbook so Tableau Cloud can open a direct route into the private network.
  3. Publish a static extract and configure a Tableau Cloud refresh schedule without deploying any network-side component.
  4. Configure Tableau Bridge within the private network and associate the supported published connection with Bridge refreshes. (correct answer)
Explanation: Whenever you see a question about Tableau Cloud connecting to data inside a private corporate network, your first instinct should be to think about the data movement problem: Tableau Cloud lives on the public internet, but private databases are deliberately shielded from it. Something inside the network must initiate the outbound connection — Tableau Cloud cannot reach inward. That "something" is Tableau Bridge. Installed on a machine within the corporate network, Bridge establishes an outbound connection to Tableau Cloud and acts as a relay, executing extract refreshes against the private database on Tableau Cloud's behalf. Because the connection originates from inside the firewall (outbound rather than inbound), no special firewall rules are needed. This is exactly what answer D describes, making it the correct choice. Answer A falls apart because a live connection routes every viewer query through Tableau Cloud's servers directly to the database — VPN access on a viewer's laptop doesn't help Tableau Cloud's infrastructure reach a private network. Answer B reflects a fundamental misunderstanding: database drivers are software libraries that format queries, not network tunnels. You cannot bundle a driver into a workbook and expect it to bypass firewall restrictions. Answer C is tempting because publishing a static extract is technically valid, but a static extract never refreshes automatically — without Bridge or equivalent infrastructure, the nightly refresh requirement simply cannot be met from Tableau Cloud alone. As a study tip, remember this pattern: private network + Tableau Cloud + scheduled refresh = Tableau Bridge. Any question that combines those three elements is pointing you toward Bridge as the architectural solution.