Tableau Quiz: Permissions And Roles
14 questions · exam conditions
0:00
Permissions And RolesQuestion 1 of 14

A workbook owner who is not an admin wants to change permissions. Can they?

No; admins only manage
Yes; owners can manage
Yes; if owner has Edit
Only if also a Viewer
← Back to quizzes

Tableau Quiz

Tableau Quiz: Permissions And Roles

Practice Permissions And Roles 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 Permissions And Roles, 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 workbook owner who is not an admin wants to change permissions. Can they?

  1. No; admins only manage
  2. Yes; owners can manage (correct answer)
  3. Yes; if owner has Edit
  4. Only if also a Viewer
Explanation: Being the workbook owner gives you permission to manage it, even if you aren't a site admin. Ownership includes the ability to set who can view, edit, or interact with the workbook. The tempting wrong answer is "Yes; if owner has Edit," because Edit access alone lets you change content, not manage permissions. Ownership, not Edit, is what grants that control.

Question 2

Group G has View on a parent project; child has no rules. Child access?

  1. Inherits View from parent (correct answer)
  2. Denied until child rule set
  3. View only with explicit rule
  4. Access depends on site role
Explanation: A child project with no permission rules automatically inherits the parent project's permissions, so Group G keeps View. Permissions flow downward until a child rule overrides them. The tempting mistake is thinking no child rule means denial, but Tableau defaults to inheritance, not a blank slate.

Question 3

User is in Group A (Allow View) and Group B (Deny View). Effective access?

  1. Deny overrides; no View (correct answer)
  2. Allow overrides; View
  3. Both cancel; no access
  4. Only Group A applies
Explanation: Tableau applies the most restrictive permission, so a Deny rule always overrides an Allow rule. Since Group B denies View, you don't get View even though Group A allows it. The tempting mistake is thinking Allow overrides because permissions accumulate, but Deny wins.

Question 4

A Creator user has View-only permissions on a project. Can they publish there?

  1. No; ownership is required
  2. Yes; Creator role is enough
  3. Yes; View includes Publish
  4. No; project permission blocks (correct answer)
Explanation: Publishing requires write or publish permission on the project, not just the Creator site role. View-only permission lets you see content but does not grant the ability to create or overwrite, so your project permissions block the publish. The tempting mistake is assuming the Creator role alone is enough; Creator matters for capabilities, but project-level permissions still control where you can publish.

Question 5

A user has the Viewer site role. An administrator explicitly allows the user the Web Edit capability on a workbook. The user can already open the workbook.

What should the administrator expect when the user attempts to edit the workbook in the browser?

  1. The user can edit because a user-specific Allow overrides the limitations of the site role.
  2. The user cannot edit because the site role sets the maximum capabilities permissions can grant. (correct answer)
  3. The user can edit but cannot save because Viewer permits editing without saving changes.
  4. The user cannot edit unless the same capability is also allowed for the All Users group.
Explanation: When working through Tableau permissions questions, always remember that site roles define the ceiling — they set the maximum level of capability any user can have, regardless of what individual permissions say. In Tableau, permissions work through a two-layer system: site roles establish an absolute upper boundary on what a user can do, and capabilities (set on content like workbooks or projects) operate within that boundary. A Viewer site role is intentionally limited — it does not include the ability to Web Edit. No matter what capability an administrator explicitly grants at the content level, the site role's ceiling cannot be exceeded. So even with an explicit Allow on Web Edit, the Viewer user will still be blocked from editing. Answer B is correct. Answer A is the most tempting distractor. It's true that explicit user-level Allows can override group-level Deny permissions — but that rule applies to resolving permission conflicts within the same layer, not to overriding site role restrictions. Confusing these two concepts is one of the most common traps on this topic. Answer C misrepresents how the Viewer role works. Viewers cannot enter edit mode at all — there's no partial editing behavior where they can modify but not save. Answer D introduces the All Users group as a requirement, which is irrelevant here. Whether a capability is granted to a group has no bearing on the site role ceiling that applies to this individual user. The key study tip: on any Tableau permissions question, ask yourself "Does the site role even allow this capability?" before evaluating the explicit permissions. If the site role blocks it, the conversation ends there.

Question 6

Jordan has a site role that supports web editing and is not an owner or administrator. On a workbook, Jordan is explicitly allowed Web Edit as an individual. Jordan also belongs to the Contractors group, which is denied Web Edit. No other relevant rules exist.

How is Jordan's effective Web Edit permission evaluated?

  1. Web Edit is denied because any group Deny always overrides every user-specific Allow.
  2. Web Edit is allowed because an explicit user Allow is evaluated before conflicting group rules. (correct answer)
  3. Web Edit is denied because Contractors is more specific than an individual permission rule.
  4. Web Edit is unspecified because conflicting user and group rules cancel one another.
Explanation: When Tableau evaluates effective permissions, the key rule to internalize is the conflict resolution hierarchy: explicit user-level rules take priority over group-level rules. This question tests whether you understand that hierarchy rather than assuming the most restrictive setting always wins. In Jordan's case, there are two competing rules: an explicit Allow on Web Edit granted directly to Jordan as an individual, and a Deny on Web Edit applied to the Contractors group. Because Tableau evaluates the explicit user Allow first, Jordan receives Web Edit access — the group Deny never gets the chance to override it. This makes B the correct answer. The permission resolves cleanly in Jordan's favor precisely because the individual rule sits higher in the evaluation order. Answer A is the most tempting trap — it assumes Deny always wins universally, which is only true when rules exist at the same level. A group Deny does not automatically override a user-level Allow. Answer C flips the logic entirely by treating groups as more specific than individuals, when in fact the opposite is true — individual rules are more targeted and therefore evaluated first. Answer D misapplies a "cancellation" idea that doesn't exist in Tableau's permission model; conflicting rules at different levels don't neutralize each other, they resolve according to hierarchy. A useful rule of thumb: in Tableau permissions, think "specific beats broad." An individual rule is more specific than a group rule, so it wins in a conflict. When you see a question pitting a user-level setting against a group-level setting, always check the hierarchy before assuming the most restrictive rule prevails.

Question 7

A project is configured with locked content permissions. A workbook owner wants to give one colleague additional access by changing permissions directly on that workbook. The owner is not a project leader or administrator.

What is the appropriate outcome under this configuration?

  1. The owner can change the workbook rules because ownership always overrides a project's lock.
  2. The owner can add an individual Allow, but cannot modify any permission assigned to groups.
  3. The owner cannot customize the workbook rules; permissions must be managed at the project level. (correct answer)
  4. The owner can unlock only that workbook while leaving permissions locked for the remaining content.
Explanation: Whenever you see a question involving locked projects in Tableau, the central concept is simple: locking a project removes the ability for individual content owners to customize permissions on their own content. That lock exists precisely to enforce consistency across everything inside the project. When a project is configured with locked content permissions, Tableau centralizes all permission management at the project level. This means that only project leaders and site administrators can modify permissions — not workbook owners acting independently. So the correct answer is C: the owner cannot change workbook-level rules and must escalate the request to someone with project leader or admin privileges. A is a common trap. Ownership does grant certain privileges in Tableau (like moving or deleting content), but it does not override a project lock when it comes to permissions. Ownership and permission management are separate concerns — don't conflate them. B describes a nuanced scenario that might seem plausible, but it's incorrect in the context of a locked project. Once the project is locked, neither group-based nor individual permission rules can be edited at the workbook level by the owner. There's no partial access granted to owners in this scenario. D is fictional behavior. Tableau does not allow a workbook owner to "unlock" a single item within a locked project while leaving everything else locked. The lock is a project-level setting, not a per-item toggle available to owners. Study tip: When you see "locked content permissions," immediately think: permissions flow down from the project, and only admins or project leaders can make changes. Owner ≠ administrator.

Question 8

A department maintains one governed project containing many workbooks and data sources. Two designated users must manage permissions and content within that project, but they must not administer other projects or the entire site. Their site roles support the required content-management capabilities.

Which approach best follows the principle of least privilege?

  1. Assign both users a site administrator role so they can manage the designated project.
  2. Make each user the owner of every workbook and data source in the designated project.
  3. Place the users in a group and grant that group Project Leader for the designated project. (correct answer)
  4. Allow the users to publish into the project without granting project-management capabilities.
Explanation: When you see a question about access control in Tableau, anchor your thinking to the principle of least privilege: grant users exactly the permissions they need — no more, no less — and apply those permissions as efficiently as possible. The scenario calls for two users who can manage content and permissions within one specific project, without touching other projects or site-level settings. Tableau's Project Leader role is purpose-built for this: it gives designated users full control over a single project's content and permissions while keeping them completely out of site administration. Placing both users in a group and assigning that group Project Leader for the designated project is the cleanest, most maintainable implementation — C is the correct answer. A violates least privilege immediately. Site Administrator grants control over the entire site, far exceeding what these users need. This is the classic "give them the master key when they only need one room" trap. B is a common misconception. Workbook and data source ownership grants certain content-specific rights, but it does not confer permission-management capabilities across the project. You'd also have to update ownership every time new content is added — it's both insufficient and operationally fragile. D falls short in the opposite direction. Publish access alone doesn't include the ability to manage permissions or govern other users' content within the project, so it fails to meet the stated requirements. As a study tip, remember that Tableau's permission hierarchy flows site → project → content. When a question restricts scope to a single project, Project Leader is almost always the right fit — it's scoped precisely at the project level by design.

Question 9

A project uses customizable content permissions. Its default rules allow the Operations group to view newly published workbooks. A workbook was published under those defaults and later received its own workbook-level permission rules. An administrator now changes the project's default rules to deny Operations access but does not apply the change to existing content.

What should the administrator expect for the existing workbook?

  1. Its rules remain independently customizable, so the changed project defaults need not alter the existing workbook. (correct answer)
  2. Its rules immediately become denied because project defaults always override existing content permissions.
  3. Its rules become locked automatically because a Deny was added at the project level.
  4. Its rules are deleted, requiring the workbook owner to recreate every permission entry.
Explanation: When Tableau uses customizable content permissions, the key distinction to understand is the relationship between project-level default rules and content-level rules that have already been customized. Default rules govern what permissions are automatically assigned when new content is published. Once a piece of content receives its own explicit permission rules, it steps outside that default inheritance — it becomes independently managed. That's exactly what happened here: the workbook was initially published under the project defaults, but it later received its own workbook-level rules. At that point, it decoupled from the project defaults. When the administrator updates the project's default rules and chooses not to apply those changes to existing content, the workbook's individually configured permissions remain exactly as they were. Answer A is correct — the workbook retains its own rules, unaffected by the change to project defaults. Answer B describes how a locked project behaves, not a customizable one. In a locked project, project-level rules do override content permissions — but that's a fundamentally different permission mode. Don't conflate the two. Answer C introduces a fictional behavior: adding a Deny at the project level does not automatically convert a customizable project to locked status. Locking is a deliberate configuration choice, not a side effect of adding a Deny rule. Answer D is simply fabricated — Tableau never silently deletes existing content-level permission entries when project defaults change. Study tip: Always anchor your thinking to the permission mode first — customizable vs. locked. In customizable projects, content-level rules are sovereign once set. In locked projects, the project rules are sovereign. Many Tableau permission questions hinge entirely on knowing which mode applies.

Question 10

Priya belongs to both the Finance group and the Temporary Staff group. On a workbook, Finance is allowed Download Full Data, while Temporary Staff is denied that capability. Priya has no user-specific rule and has a site role capable of downloading data.

What is Priya's effective permission for Download Full Data?

  1. Allowed, because membership in any group with an Allow is sufficient for access.
  2. Allowed, because the Finance rule represents the workbook's primary business audience.
  3. Denied, because a group Deny takes precedence over an Allow from another group. (correct answer)
  4. Unspecified, because opposing group rules must be resolved by a content owner.
Explanation: When a user belongs to multiple groups with conflicting permissions in Tableau, a specific rule determines the outcome: a Deny at the group level overrides an Allow from another group. This is the core of Tableau's permission precedence model, and questions like this are testing exactly that hierarchy. In Priya's case, she belongs to Finance (which has an Allow for Download Full Data) and Temporary Staff (which has a Deny). Because these two group-level rules conflict, Tableau resolves the tie in favor of the Deny — meaning Priya's effective permission is Denied. Her site role and the absence of a user-specific rule don't change this outcome, because no user-level rule exists to override the group-level conflict. Answer C is correct. Answer A is the most tempting distractor — it reflects how some systems work (any Allow is sufficient), but Tableau does not use a "most permissive wins" model at the group level. Answer B introduces a concept — business audience priority — that simply doesn't exist in Tableau's permission framework. Tableau has no mechanism for declaring one group's intent more important than another's. Answer D is wrong because Tableau resolves conflicting group rules automatically with the Deny-wins rule; no manual intervention from a content owner is required or triggered. Study tip: Memorize Tableau's permission precedence order: User-level rules beat group-level rules, and among group rules, Deny beats Allow. A common trap is assuming "most permissive wins" — that's the intuition, but it's the opposite of how Tableau handles group conflicts.

Question 11

A workbook uses a governed data source that applies user-based row-level security. Dana and Rui are both allowed View on the workbook and have the same Viewer site role. Dana sees all regions, while Rui sees only the West region.

Which conclusion best explains the different results?

  1. The View capability opens the workbook but does not override user-based restrictions enforced by the data source. (correct answer)
  2. The Viewer site role randomly limits rows when multiple users open the same published workbook.
  3. Rui must have an implicit Deny on View because users with View always see identical underlying rows.
  4. Dana's View permission is automatically stronger because access to more rows increases the permission level.
Explanation: Whenever you see a question mixing permissions and row-level security (RLS), keep two separate layers in mind: (1) site/content permissions that control access to the workbook, and (2) data-source-level security that controls which rows a user sees inside it. These layers operate independently, and confusing them is the most common trap on this topic. Answer A is correct because it captures exactly how governed data sources with user-based RLS work. When a data source is configured with row-level security, it filters data based on the authenticated user's identity — after the workbook opens. Dana and Rui both have View, so they can both open the workbook. But the data source recognizes them as different users and returns different rows accordingly. View capability is purely a gate to the content; it says nothing about what data flows through once the gate is open. B is wrong because Tableau's RLS is deterministic, not random — the same user always sees the same rows based on configured rules. C is wrong because Rui clearly can open the workbook, which means there is no Deny on View; the restriction is at the data level, not the permission level. D is wrong because permissions are binary capabilities (allowed or denied) — seeing more data does not elevate or strengthen a View permission. A useful study reminder: permissions govern access; RLS governs data. On the Tableau exam, whenever two users have identical permissions but see different data, the answer almost always points to the data source's security configuration, not to anything wrong with their permissions.

Question 12

Lee has an Explorer site role and receives View access to a workbook only through membership in the Regional Analysts group. Lee is removed from that group. There is no individual rule for Lee and no Allow from any other group.

After the group membership change is reflected, what access should Lee have to the workbook?

  1. Lee retains View access because permissions already obtained from a group persist for the user.
  2. Lee's access is unchanged because removing a user from a group only affects future content published by that group.
  3. Lee retains View access because the Explorer site role automatically grants access to all published workbooks.
  4. Lee loses View access because the former group rule no longer applies and access defaults to denied. (correct answer)
Explanation: When a question describes a user's access coming entirely from group membership, your first instinct should be to ask: "What happens to that access if the group connection is severed?" That question is at the heart of how Tableau's permission model works. Tableau evaluates permissions dynamically. When Lee tries to access the workbook, Tableau checks all active rules — individual rules and group rules Lee currently belongs to. Because Lee's View permission came solely from the Regional Analysts group, removing Lee from that group eliminates the only rule that was granting access. With no individual rule and no other group rule in play, there is nothing left to generate an "Allow." Tableau's default behavior in the absence of an explicit Allow is to deny access. So D is correct: Lee loses View access once the group change takes effect. Choice A is wrong because permissions are not "banked" or permanently attached to a user after being granted through a group. The moment group membership ends, so does the inherited rule. Choice B confuses how group removal works — it has nothing to do with future publishing activity; it immediately removes the user from any rules tied to that group. Choice C reflects a very common misconception worth memorizing: site roles set a permission ceiling, not a floor. Explorer means Lee can have up to Explorer-level access, but it does not automatically grant access to any specific workbook. Content permissions still must be explicitly configured. A useful rule of thumb: on permission questions, always separate site role (what a user is allowed up to) from content permissions (what a user is actually granted). Confusing the two is the most common trap in this topic area.

Question 13

On Tableau Server, an organization has several sites. Elena administers the Sales site, while Marcus is a Server Administrator. A new site must be created, and permissions on content in an existing HR site must also be reviewed.

Which assignment of responsibilities is consistent with these administrative roles?

  1. Elena can create the new site, while Marcus needs explicit HR project permissions to review its content.
  2. Marcus can create the new site and review the HR site; Elena's authority is limited to Sales. (correct answer)
  3. Elena and Marcus can both create sites, but only an HR content owner can review HR permissions.
  4. Neither can create the site until the All Users group receives a site-management permission.
Explanation: When you see a question about Tableau Server administration, ground yourself in the permission hierarchy: Server Administrators have global authority across all sites, while Site Administrators are scoped exclusively to their assigned site. Marcus, as a Server Administrator, sits at the top of this hierarchy. He can create new sites, manage all existing sites (including HR), and review permissions anywhere on the server — no explicit content-level grants are needed because his role carries inherent, server-wide authority. Elena, as a Site Administrator for Sales, has full control within Sales but cannot act outside that boundary. She cannot create sites or touch the HR site's content or permissions. This makes B correct: Marcus handles both the new site creation and the HR site review, while Elena's authority stays within Sales — exactly what the role definitions dictate. A is wrong on both counts: Elena cannot create sites (that's a Server Administrator privilege), and Marcus doesn't need explicit project permissions — his server-level role already grants that access. C is wrong because Site Administrators like Elena cannot create sites at all; only Server Administrators can. The claim that "only an HR content owner" can review HR permissions also misrepresents how Server Admin authority works. D is a fabricated constraint — no such All Users group site-management prerequisite exists in Tableau Server's permission model. A useful study tip: on Tableau exam questions, always map each person to their role tier first (Server Admin → Site Admin → Project Leader → user), then ask what each tier inherently can and cannot do before evaluating any answer choices.

Question 14

Mateo has the Explorer (can publish) site role. He can view a destination project, but the project's permission rules deny him Publish. He needs to publish a new workbook into that project.

Which change most directly enables the required action while preserving Mateo's current site role?

  1. Allow Publish on the destination project for Mateo or an appropriate group. (correct answer)
  2. Upgrade Mateo to Creator while retaining the project's explicit Publish denial.
  3. Change Mateo to Viewer and allow Web Edit on an existing workbook.
  4. Allow Download Workbook on content already located in the destination project.
Explanation: Whenever you see a question about Tableau permissions, remember that access is governed by two independent gates: the site role (what a user can potentially do across the site) and project permission rules (what a user can actually do within a specific project). Both gates must be open for an action to succeed. Mateo already holds the Explorer (can publish) site role, which means his site-level capability allows publishing — that gate is open. The blocker is the project-level permission rule explicitly denying him Publish. The most direct fix is simply to remove or override that denial, which is exactly what A does. Granting Publish at the project level for Mateo or a group he belongs to aligns his project permissions with his existing site role capability, enabling the action without touching anything else. B is a trap because upgrading Mateo to Creator does nothing if the project still explicitly denies Publish. A higher site role cannot override a project-level denial — you'd be spending a license upgrade for zero gain. C is doubly wrong: Viewer is a lower role that cannot publish at all, and Web Edit applies to editing existing workbooks, not publishing new ones — it doesn't address Mateo's actual need. D targets Download Workbook, a completely unrelated permission that controls whether users can export content to their desktop; it has no bearing on the ability to publish. A useful rule of thumb: site role sets the ceiling, project permissions set the floor — if the floor has a hole (an explicit denial), raising the ceiling won't help. Always check both layers when troubleshooting access issues on the exam.