What you will be able to do
- Tell account-level permission sets apart from project-level ones, and pick the pre-built set that fits a persona
- Assign a permission set to a group with the right project scope and environment write access
- Predict a user's effective access when they belong to several groups or hold an IT or Read-Only license
Key concept
Permission set (group-assigned) — A permission set is a named bundle of access to dbt features, such as Admin, Developer or Job viewer. You attach it to a group, never to a person, and users get it by being members of that group.
1.Permission sets, groups and precedence
A permission set decides what a user can do inside a dbt account: edit jobs, open the IDE, invite people, read billing. On the Enterprise and Enterprise+ plans, dbt ships a catalogue of pre-built sets so you never have to compose access from individual switches. Each set falls on one side of a split. Account-level sets cover administration of the account itself: inviting users, configuring SSO, creating groups. Project-level sets cover the configuration and upkeep of the projects themselves: configuring environments, using the IDE, running jobs.
The split describes what a set is mainly for. It does not wall the two areas off from each other. An account-level set can still reach project features, and a project-level set can still reach account features. Admin is a project-level set, for example, yet it can invite members. A few sets, such as Cost Insights Admin and Cost Insights Viewer, are deliberately both levels. Judge a set by its actual access, not by its label.
Every assignment goes through a group. You cannot give a permission set to an individual user. To change one person's access, you change their group memberships. A group can carry more than one permission set, and a user can sit in more than one group. When assignments overlap, the one with more access takes precedence. Adding someone to a restrictive group therefore never narrows what a broader group already gave them. To restrict a user, you have to remove them from the permissive group.
Checkpoint 1 of 8· Check yourself
A contractor should be able to run jobs and see the results, nothing more. They are already in a group that holds the Developer set. What gives them only job-runner access?
You can't attach permissions to a user, only to groups. Where groups overlap, the one with more access wins, so the contractor has to leave the Developer group.
“If a user is assigned licenses and permissions from multiple groups, the group that grants the most access will take precedence.”Source: docs.getdbt.com
2.Choosing the right pre-built set
Picking a set means matching a persona to the narrowest bundle that still lets them do their job. Most of the exam-relevant distinctions are about what a set *cannot* do. The table below compares the main sets for assignment.
| Permission set | Level | Main access | Notable limit |
|---|---|---|---|
| Account admin | Account | Unrestricted access to every feature | Recommended for as few users and groups as possible |
| Admin | Project | Unrestricted access to existing projects; can invite members and assign access | Can't create new projects or groups |
| Account Viewer | Account | Read-only access to all settings, projects, environments, runs and audit logs | No access to the IDE |
| Analyst | Project | Full IDE access and personal adapter and Git credentials | Read-only environment configs; can view jobs but not edit them |
| Analyst read | Project | Read-only access to connections, projects, environments and Catalog metadata; can edit own credentials | No read access to jobs or runs; no Studio IDE or CLI |
| Developer | Project | Create, edit and test dbt code in the IDE | Read-only access to environment, job, run and Git configs |
| Database admin | Project | Write access to data platform configurations within environments; Semantic Layer configs | Environment variables stay read-only |
| Git admin | Project | Create Git integrations and environment variables; edit project settings | No access to the IDE |
| Job admin | Project | Create and edit jobs, runs, environment variables and data warehouse configs | Read-only access to project configs |
| Job creator | Project | Create, edit and run jobs within assigned projects and environments | Cannot create or delete environments or edit environment variables |
| Job runner | Project | Run jobs; read-only access to jobs | No other access to dbt features |
| Job viewer | Project | Read-only access to job results, status and logs | Cannot initiate or modify jobs |
| Metadata | Project | Read-only access to metadata for models, runs, sources and tests (Discovery API integrations) | No access to modify, execute or manage jobs, repositories or users |
| Billing admin | Account | Unrestricted access to the Billing section | Only other access is read access to public models |
The four job sets form a ladder of access. Job viewer watches. Job runner also triggers runs. Job creator also builds and edits jobs within its assigned scope. Job admin also edits environment variables and warehouse configs. For a scheduler role, choose the lowest rung that still works. Admin is the set people most often overestimate: it controls existing projects completely and can invite and assign users, but it can't create new projects or groups.
Inviting users is not limited to Admin. On Enterprise-tier accounts, Account admin, Admin, Project creator and Security admin can all invite, and the inviter needs a Developer or IT license. The IT license itself carries Security Admin and Billing Admin permissions.
Two names cause confusion. The Developer permission set is the main set for people working in the IDE. It is a different thing from the Developer license, which is a billable seat. A user can hold the license without the set, and the reverse.
Checkpoint 2 of 8· Match them up
Match each persona to the narrowest permission set that fits
Tap a term, then the definition that fits it.
Database admin is limited to data platform configurations. Job runner can only run jobs and read them. Account Viewer reads everything, audit logs included, and changes nothing. Billing admin is confined to the Billing section.
“Helpful for scenarios where your data warehouse admins only need access to dbt to configure data platform settings within environments.”Source: docs.getdbt.com
Checkpoint 3 of 8· Exam question
A dbt Cloud admin adds a contractor to the Account Admin group so the contractor can help triage failing jobs, but assigns the contractor a Read-Only license because the contractor should never modify code or configuration. When the contractor logs in and tries to edit a deploy job's commands, what happens?
Correct answer: B — The contractor stays blocked from editing the job, because a Read-Only license enforces view-only access to jobs and runs across the entire account no matter which group permission set is assigned.
- A. This is incorrect because license type always overrides group permission sets in dbt Cloud's RBAC model. Account Admin group membership does not restore write access once a Read-Only license is attached to the user.
- B. This is correct because a Read-Only license enforces view-only access to artifacts and the deploy section account-wide, and that restriction is not lifted by any group permission set the user also belongs to.
- C. This is incorrect because environment write access overrides the default read-only behavior of certain project-level permission sets like Analyst, not the account-wide restriction imposed by a Read-Only license.
- D. This is incorrect because dbt Cloud has no ticket-based sign-off mechanism gating edits for Read-Only licensed users; the restriction is enforced directly and permanently by the license type.
3.Assigning a set: project scope and environment write access
You assign a set in a group's Access & Permissions section, under Account settings → Groups & Licenses. Each row there makes three decisions: which projects the group can access, which permission set its members get in those projects, and which environments they can write to. Every row needs all three, so the same set can mean very different access in two groups. Analysts could edit jobs in their own project and only view a neighbouring one, for example.
Projects are chosen per row, and All projects is the default. When one set needs different reach in different places, click Add permission again and add another row with the same set but a different project scope or environment selection. A single group can then hold, for example, Developer with broad write access on one project and Developer with read-only access on the rest.
Default groups come pre-wired, and new groups do not. Owner gets Account admin. On Enterprise plans, Member gets a Member set that doesn't appear in the settings but has the same privileges as Admin. A group you create yourself starts with nothing. Until you give it a permission set, its members can reach nothing beyond their user profile. New users can be missing access even though their group membership looks correct, and an empty group is the usual reason.
Checkpoint 4 of 8· Put it in order
Put the steps for giving a group the Analyst read set in order
- 1.Give the group a descriptive name
- 2.Click Add permission and select the Analyst read permission set
- 3.Click Save
- 4.Select the projects the permission set should apply to
- 5.Go to Account settings → Groups & Licenses
You open Groups & Licenses, name the group, add the permission row, narrow its projects (All projects is the default), and save.
“Click Add permission and select the Analyst read permission set.”Source: docs.getdbt.com
Environment write access is the part of a row that most often grants more than intended. The field appears only for five sets: Database admin, Git admin, Team admin, Analyst and Developer. Account admin already has everything, and sets such as Account viewer cannot be given write access, so they have no such field. Ticking an environment type lifts the set's read-only limit on jobs and runs in that environment. It never lets users create or delete environments. If you leave every box unchecked, the group stays read-only there. The model behind environment types is covered in [environment access control](lesson:3.1).
The Developer set has a default that surprises people. The permissions table lists Developer as read-only on environment settings, yet when you add Developer to a group, Environment write access starts at All environments. That includes Production. If developers should not create production jobs, you must narrow the field, for example to Development and General.
Checkpoint 5 of 8· Check yourself
An admin adds the Developer set to a new group for all projects and saves without touching Environment write access. What can members do with jobs in Production?
For Developer, the Environment write access field defaults to All environments, which allows writing jobs and runs. Environment write access never lets users create or delete environments.
“the Developer role has read-only access to environment settings, but when added to a group, the Environment write access field defaults to All environments”Source: docs.getdbt.com
Checkpoint 6 of 8· Exam question
A user belongs to two groups: Analytics Team, which grants the Analyst permission set scoped to the Marketing project only, and Platform Team, which grants the Developer permission set scoped to all projects. The user holds a Developer license. Which two statements correctly describe the access this user ends up with?(Select 2)
Correct answers: A, C — The user receives Developer-level access across all projects, because when a user belongs to multiple groups, the group granting the more permissive permission set and scope wins.; The user retains full IDE access to create, edit, and run models in any project, since the Developer license combined with the Platform Team group unlocks that capability account-wide.
- A. This is correct because when a dbt Cloud user belongs to multiple groups, the permission set and scope granting the most access takes precedence over more restrictive group memberships.
- B. This is incorrect because dbt Cloud resolves overlapping group memberships by taking the most permissive combination of permission set and scope, not the most restrictive one.
- C. This is correct because the Developer license permits full IDE, CLI, and job access, and the Platform Team group's Developer permission set scoped to all projects extends that capability everywhere.
- D. This is incorrect because overlapping group permission sets never lock an account; dbt Cloud simply merges them by granting whichever access is broadest across the user's groups.
4.When the license overrides the set
A permission set only works up to the limit of the user's license. License types always override group permission sets. A Developer license can be granted any set, so for Developer-licensed users the set really does decide their access. The IT and Read-Only licenses go further: their holders inherit no rights from any permission set. Every IT user has the same fixed access across the account (Security Admin, Billing Admin and editing Connections), whatever groups they are in. Read-Only users are the same, with fixed read-only access. New users get a Developer license unless it is changed manually, through SSO [license mappings](lesson:5.3), or through SCIM.
Read-Only users have two narrow exceptions, and both go through a group. Analyst read lets a Read-Only user manage their own warehouse credentials and use the dbt MCP server, without changing their license. Cost Insights Viewer is needed before a Read-Only user can see Cost Insights at all. In both cases, users have no access until they are added to a group that holds the set.
Enterprise and Enterprise+ accounts that already have Read-Only users can turn on granular permissions to restrict which projects those users see, set group by group. Users stay Read-Only: the setting controls project access, not permissions. Once enabled, it cannot be turned off. Afterwards, a Read-Only user keeps project access only if they are in a group with a Read-Only permission set that covers all projects. A user in no such group, or in one whose set covers only some projects, loses access to the uncovered projects. Analyst read is the set built for this: read-only access to connections, projects, environments and Catalog metadata, with no write access, and it applies to All projects by default. Before you enable the setting, put every Read-Only user in a group with such a set. Newer accounts have this behaviour by default.
Checkpoint 7 of 8· Check yourself
A Read-Only analyst needs to see estimated cost and savings data. What gives them that access?
A Read-Only license alone does not include Cost Insights, and permission sets are granted only through groups. The IT license has no access to Cost Insights.
“A Read-Only license is not enough to view Cost Insights. Assign this permission set through a group.”Source: docs.getdbt.com
Checkpoint 8 of 8· Exam question
A dbt Cloud Enterprise admin wants a compliance specialist to manage SSO settings, IP restrictions, and billing invoices, but the specialist must never touch the dbt IDE, CLI, or any project's code. Which license and permission approach fits this requirement?
Correct answer: B — Assign the specialist an IT license, which carries fixed Security Admin and Billing Admin rights across the account without inheriting or needing any group permission set.
- A. This is incorrect because a Developer license grants IDE and CLI access alongside any assigned permission set, which fails the requirement that the specialist never touch code.
- B. This is correct because the IT license is purpose-built with fixed Security Admin and Billing Admin permissions and does not grant IDE, CLI, or code access, and it ignores group permission sets entirely.
- C. This is incorrect because Read-Only licenses do not inherit rights from group permission sets; the Security Admin permission set on the group would be ignored and the user would stay read-only.
- D. This is incorrect because Analyst licenses are legacy and no longer available for new assignment, and this approach still risks granting IDE access the specialist should not have.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Giving someone the Developer permission set is the same as giving them a Developer license.Why is that wrong?
The Developer set is a project-level bundle of IDE and code access. The Developer license is a billable seat. You assign them separately.
Covered in Choosing the right pre-built set
2.The Admin permission set can create new projects and new groups.Why is that wrong?
Admin has unrestricted access to existing projects and can invite and assign users, but it can't create new projects or groups.
Covered in Choosing the right pre-built set
3.A newly created group with members but no permission set gives them the same access as the Member group.Why is that wrong?
Only the default groups come with sets. Members of a custom group with no set can reach nothing beyond their user profile.
Covered in Assigning a set: project scope and environment write access
4.Putting a Read-Only or IT licensed user in an Account Admin group makes them an account admin.Why is that wrong?
The license always overrides the group's permission sets. IT and Read-Only users inherit no rights from any set.
Covered in When the license overrides the set
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Account-level permissions are primarily for account administration (inviting users, configuring SSO, and creating groups).”
↩︎ Permission sets, groups and precedence“Project-level permissions are for the configuration and maintenance of the projects themselves (configuring environments, accessing IDE, and running jobs).”
↩︎ Permission sets, groups and precedence“Account permission sets may have access to project features, and project permission sets may have access to account features.”
↩︎ Permission sets, groups and precedence“Cost Insights Admin is both an account-level and project-level set.”
↩︎ Permission sets, groups and precedence“A dbt group can be associated with more than one permission set. Permission assignments with more access take precedence.”
↩︎ Permission sets, groups and precedence“Unrestricted access to existing projects, but can't create new projects.”
↩︎ Choosing the right pre-built set“More limited than Job admin, which can edit environments, environment variables, and data platform configurations.”
↩︎ Choosing the right pre-built set“Metadata is intended to be a read-only Discovery API integration permission set.”
↩︎ Choosing the right pre-built set“On Enterprise-tier plans, you can assign Analyst read to Read-Only users.”
↩︎ When the license overrides the set“This is the primary permission set for users working in the IDE and should not be conflated with the Developer license.”
↩︎ Exam trap 1“Can invite new members and assign access but can't create groups.”
↩︎ Exam trap 2“Helpful for scenarios where your data warehouse admins only need access to dbt to configure data platform settings within environments.”
↩︎ Checkpoint“A Read-Only license is not enough to view Cost Insights. Assign this permission set through a group.”
↩︎ Checkpoint - 2.
“you can’t assign permissions at the user level.”
↩︎ Permission sets, groups and precedence“you might allow one group of analysts to edit jobs in their project, but only let them view related projects”
↩︎ Assigning a set: project scope and environment write access“Enterprise plans: By default, dbt assigns the Owner group an Account Admin permission set, and the Member group a Member permission set”
↩︎ Assigning a set: project scope and environment write access“This elevated access doesn't grant users the ability to create or delete environments.”
↩︎ Assigning a set: project scope and environment write access“Read-only licensed users do not inherit rights from any permission sets.”
↩︎ When the license overrides the set“IT licensed users do not inherit rights from any permission sets.”
↩︎ When the license overrides the set“Read-Only users keep their project access only if they're in a group with a Read-Only permission set that covers all projects.”
↩︎ When the license overrides the set“Access stays Read-Only: This setting controls access to projects, not permissions (users remain Read-Only).”
↩︎ When the license overrides the set“It's permanent: Enabling this setting is a one-time, irreversible change.”
↩︎ When the license overrides the set“The permissions are more granular than licenses, and you only assign them at the group level; you can’t assign permissions at the user level.”
↩︎ Key concept“or users assigned will not have access to features beyond their user profile”
↩︎ Exam trap 3“User license types always override their assigned group permission sets.”
↩︎ Exam trap 4“If a user is assigned licenses and permissions from multiple groups, the group that grants the most access will take precedence.”
↩︎ Checkpoint“Click Add permission and select the Analyst read permission set.”
↩︎ Checkpoint“Every IT licensed user has the same access across the account, regardless of the group permissions assigned.”
↩︎ Prediction - 3.
“Enterprise-tier accounts — must have admin, account admin, project creator, or security admin permissions.”
↩︎ Choosing the right pre-built set - 4.
“You can configure multiple rows for the same permission set within a group when each row has different project scope and/or environment write access.”
↩︎ Assigning a set: project scope and environment write access“the Developer role has read-only access to environment settings, but when added to a group, the Environment write access field defaults to All environments”
↩︎ Checkpoint - 5.
“Only the following permissions sets can have environment-level permissions configured: Database admin Git admin Team admin Analyst Developer”
↩︎ Assigning a set: project scope and environment write access“If none are selected, the group will have read-only access.”
↩︎ Assigning a set: project scope and environment write access - 6.
“New users are assigned a Developer license unless you change it manually using SSO license mappings, or using SCIM.”
↩︎ When the license overrides the set