- A Creator user has View-only permissions on a project. Can they publish there?
Answer: No; project permission blocks
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.
- Which assignment of responsibilities is consistent with these administrative roles?
Answer: Marcus can create the new site and review the HR site; Elena's authority is limited to Sales.
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.
- How is Jordan's effective Web Edit permission evaluated?
Answer: Web Edit is allowed because an explicit user Allow is evaluated before conflicting group rules.
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.
- Which approach best follows the principle of least privilege?
Answer: Place the users in a group and grant that group Project Leader for the designated project.
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.
- What is Priya's effective permission for Download Full Data?
Answer: Denied, because a group Deny takes precedence over an Allow from another group.
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.
- What is the appropriate outcome under this configuration?
Answer: The owner cannot customize the workbook rules; permissions must be managed at the project level.
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.
- After the group membership change is reflected, what access should Lee have to the workbook?
Answer: Lee loses View access because the former group rule no longer applies and access defaults to denied.
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.
- Which conclusion best explains the different results?
Answer: The View capability opens the workbook but does not override user-based restrictions enforced by the data source.
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.
- User is in Group A (Allow View) and Group B (Deny View). Effective access?
Answer: Deny overrides; no View
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.
- A workbook owner who is not an admin wants to change permissions. Can they?
Answer: Yes; owners can manage
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.
- Group G has View on a parent project; child has no rules. Child access?
Answer: Inherits View from parent
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.
- Which change most directly enables the required action while preserving Mateo's current site role?
Answer: Allow Publish on the destination project for Mateo or an appropriate group.
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.
- What should the administrator expect when the user attempts to edit the workbook in the browser?
Answer: The user cannot edit because the site role sets the maximum capabilities permissions can grant.
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.
- What should the administrator expect for the existing workbook?
Answer: Its rules remain independently customizable, so the changed project defaults need not alter the existing workbook.
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.
