What you will be able to do
- Explain how dbt RBAC grants access through group membership rather than to individual users
- Predict a user's effective access when they belong to several groups or hold a restrictive license
- Configure a group's projects, permission sets and environment write access
- Map IdP groups to dbt groups so SSO logins assign and revoke access automatically
Key concept
Role-based access control (RBAC) — In dbt, access to features is decided by which groups a user belongs to. Each group carries permission sets scoped to projects and environments, and the user's license sets a ceiling that no group can raise.
1.How RBAC grants access through groups
Every dbt user has two things that decide what they can do: a license and a set of permissions. The license applies to the whole account. Permissions are finer-grained and switch on specific features in specific projects. RBAC is the part you control day to day, because permissions come only from group membership. On Enterprise and Enterprise+ plans, this lets one person be an administrator on their own team's project and only a viewer on the project next door.
The group is the only place you can assign a permission. There is no screen for granting a permission set straight to a user. You attach permission sets to a group, and the group's members inherit them. Every user must belong to at least one group. A group can hold more than one permission set, and when several assignments overlap, the one granting more access applies.
Because the most generous grant applies, adding someone to a stricter group never takes access away. If a user is in a group that can edit jobs and also in a group that can only view them, they can edit. To restrict someone, you take them out of the broad group. Putting them in a narrow one is not enough.
A new group starts out empty, and dbt does not fill in a sensible default for it. Until you assign a permission set to a group you created, its members can see their user profile and nothing else. When a new hire reports that dbt shows them nothing, this is usually the reason: they were put in a new group that never got a permission set.
Checkpoint 1 of 8· Check yourself
An analyst belongs to a group with the Job viewer permission set and also to a group with the Job admin permission set on the same project. What can they do with jobs there?
When permissions come from several groups, dbt applies the most permissive one. A stricter group only restricts a user who is in no broader 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
Checkpoint 2 of 8· Exam question
A dbt Cloud admin adds Priya to the Account Admin group so she can manage jobs and connections for the finance team's project. Priya's account was provisioned with a Read-Only license during the last SCIM sync. When Priya logs in, what access will she actually have on the finance project?
Correct answer: B — Priya is limited to read-only visibility on the finance project, because her Read-Only license overrides the permission set granted by the Admin group.
- A. This reverses the precedence order dbt Cloud actually enforces. License type sits above group membership in the hierarchy, so an Admin group cannot elevate a user beyond what their license permits.
- B. This is correct because license type always overrides the permission set inherited through group membership. A Read-Only license restricts the user to viewing artifacts regardless of any Admin group they belong to.
- C. There is no automatic downgrade mechanism that substitutes a project-scoped role for a broader group assignment. The license simply restricts the effective access to read-only rather than remapping the group's permission set.
- D. A Read-Only license does not block login. The user can still authenticate and browse the account; their actions are limited to viewing rather than editing or triggering jobs.
2.Default groups and why to replace them
dbt creates three groups with every new account, and the person who created the account is added to all three. These groups make setup quick, but they don't suit RBAC. Two of them automatically add every new user, and one of those two gives broad access.
| Group | Default permissions | New users added automatically? |
|---|---|---|
| Owner | Account Admin permission set; permissions cannot be changed | No |
| Member | Member permission set, with the same privileges as the Admin permission set | Yes |
| Everyone | Customisable to fit your organisation | Yes |
The Member group is the problem for least-privilege setups. Its permissions are broad: the only features it withholds are those that can change billing or security. Since dbt adds every new user to it, each invitee starts with that broad access whatever other groups you put them in. The fix is to create your own organisational groups, move users into them, and then delete the defaults.
dbt protects you from removing every administrator by mistake. You can't delete the Owner group until at least one other user is in a group with the Account Admin permission set, or until a user holds an IT license. Reassign yourself before you start deleting default groups. You also can't change your own group membership; another user has to do it.
Checkpoint 3 of 8· Check yourself
A new contractor is invited and added to a custom group that has only the Job viewer permission set. The default groups are unchanged. Why can the contractor still edit project settings?
dbt adds new users to the Member and Everyone groups by default. Member's broad permissions win over the narrower custom group, so least-privilege setups replace the default groups.
“Default permissions are broad, restricting only access to features that can alter billing or security.”Source: docs.getdbt.com
3.Configuring a group's access and permissions
You create and edit groups under Account settings → Groups & Licenses. You need write permission on that settings area. The part that controls access is the group's Access & Permissions section, where you click Add permission and make three choices:
- Permission set: the role members get, such as Analyst, Developer or Job admin. [Permission sets](lesson:5.2) are compared in their own lesson. - Projects: the projects the set applies to. All projects is the default. - Environment write access: the environment types in those projects where members can create, edit and delete jobs and runs.
A group can have several rows that use the same permission set with different scope. For example, the Developer set can have write access to Development and General in a team's own projects, and a second row with no write access in a neighbouring project. That gives one group admin-level reach on the project it owns and read-only access elsewhere.
Environment write access is the setting most likely to give more than you intended. Only Analyst, Database admin, Developer, Git admin and Team admin accept it. If you clear every box, the group is read-only in all environments. Ticking boxes raises a read-only set such as Analyst to full write on jobs and runs, though it still can't create or delete environments. The Developer role behaves differently: adding it to a group sets environment write to All environments by default, so remove Production deliberately. How environment types relate to access is covered in [environment access control](lesson:3.1).
Checkpoint 4 of 8· Match them up
Match each Access & Permissions choice to its effect
Tap a term, then the definition that fits it.
Each row in Access & Permissions combines a permission set, a project scope and environment write access. Leaving environments unselected means read-only, and extra rows let one set have different scopes.
“Each row can use the same permission set with different project and environment selections.”Source: docs.getdbt.com
4.Mapping IdP groups to dbt groups
Groups that you maintain by hand get out of date as soon as people change teams. SSO mappings solve this by linking a group in your identity provider (Okta, Microsoft Entra ID, Google Workspace and others) to a dbt group. When a user signs in through the IdP, dbt reads their IdP groups and updates their dbt group memberships, and therefore their permissions, to match. Setting up the SSO application itself is covered in [SSO for dbt Enterprise](lesson:5.5).
You create a mapping on the group itself. Open or create the group and type the IdP group name into its SSO field, spelled exactly as it is in the IdP. If the name differs at all, dbt places no one in the group, and it does not report an error. dbt Labs recommends mapping one IdP group to one dbt group and giving both the same name, often with a shared prefix such as DBT_GROUP_.
For RBAC to work with SSO, switch off automatic membership. Any group with Add all new users by default enabled takes in every new SSO user, whatever IdP groups they belong to. Everyone and Member have this enabled out of the box. Disable it on every group, so that membership comes only from the mappings.
Membership changes when the user logs in, not when the IdP changes. A new SSO user joins mapped groups on their first login, and an existing user's groups change on their next one. If you change someone's IdP groups, ask them to log out and back in. A group with no SSO mapping is unmanaged: logins never change it, and admins add and remove its members by hand. Adding a mapping makes the group managed from then on.
A worked case shows how the parts fit together. A new analyst, Euclid Ean, is added in Okta to an IdP group called The Big Project. The dbt group with that name in its SSO field has the Analyst permission set, the Jaffle Shop project, and write access to the Development, Staging and General environments. Euclid's first SSO login requires them to verify their email. After that, they see only Jaffle Shop. They have full access in Staging, and they can see Production but only read it.
Checkpoint 5 of 8· Check yourself
New Okta users are landing in a dbt group with no permissions beyond their profile, even though they are in the Okta group DBT_GROUP_Finance. The dbt group's SSO field reads dbt_group_finance. What is wrong?
dbt matches the IdP group name exactly. A name that differs, even only in letter case, means users are never placed in the mapped group. Enabling Add all users by default would also undermine RBAC.
“If the name is not the same, the users will not be properly placed into the group.”Source: docs.getdbt.com
Checkpoint 6 of 8· Exam question
Which statement correctly describes the IT license type in dbt Cloud?
Correct answer: A — It grants Security Admin and Billing Admin permissions directly on the user and does not inherit any permission sets from the groups the user belongs to.
- A. This matches how the IT license works: it fixes Security Admin and Billing Admin permissions directly on the user, and unlike a Developer license, it does not pick up any additional permission sets from group membership.
- B. The IT license is narrower than Account Admin; it is bounded to security and billing administration plus connection editing, not unrestricted access to every account feature.
- C. This license type is only available on the Starter, Enterprise, and Enterprise+ plans, and it does not consume a seat the way a Developer license does.
- D. Inheriting the highest-access group permission set describes how a Developer license can behave, not the IT license, which keeps a fixed set of permissions regardless of group assignment.
Sources1
5.Where licenses cap RBAC
Group permissions work inside the limits of a license and can never go beyond them. A Read-Only user in an Account Admin group still can't perform administrative actions. The IT and Read-Only licenses ignore permission sets entirely: every holder of either license has the same fixed access across the account, whatever groups they belong to. Only Developer and Analyst licenses let permission sets take full effect.
This changes how you troubleshoot RBAC. When someone can't do what their group should allow, check their license before you look at their groups. How IdP groups set the license itself is a separate mechanism, covered in [license mappings](lesson:5.3). If you use SCIM, license assignment can also be handled at provisioning time in the IdP.
Checkpoint 7 of 8· Check yourself
Which change actually lets a Read-Only-licensed user, who is in a Developer-permission group, start editing models in the Studio IDE?
Read-Only users don't inherit rights from permission sets, so no group change helps. Only a license that permits development, such as Developer, does.
“Read-only licensed users do not inherit rights from any permission sets.”Source: docs.getdbt.com
Checkpoint 8 of 8· Exam question
Deshawn is a member of two dbt Cloud groups that are both scoped to the same 'Core Analytics' project: the 'Reporting' group carries the Job Viewer permission set, and the 'Pipeline Owners' group carries the Job Admin permission set. Deshawn holds a Developer license. When he opens the Core Analytics project, what access does he have to jobs?
Correct answer: A — Job Admin access, because when a user belongs to multiple groups scoped to one project, the permission set with the higher access level takes precedence.
- A. This is correct because a Developer license inherits group permission sets, and when multiple groups grant different levels of access to the same project, the more permissive permission set applies.
- B. Join order has no effect on which permission set applies. dbt Cloud resolves overlapping group access by access level, not by chronology of group membership.
- C. Overlapping group memberships do not create a blocking conflict. dbt Cloud is designed to resolve multiple permission sets on the same project rather than lock the user out.
- D. There is no averaging mechanism, and the resolution does not default to the more restrictive set; the higher-access permission set is the one that applies.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.You can give one user a permission set directly from their user profile.Why is that wrong?
Permissions are assigned only at the group level. To give a user a permission set, add them to a group that has it.
Covered in How RBAC grants access through groups
2.Adding a user to a restrictive custom group limits their access, even while they are still in the default Member group.Why is that wrong?
The most permissive group wins. To restrict a user you must remove them from broad groups such as Member.
Covered in Default groups and why to replace them
3.Changing a user's IdP group immediately changes their dbt permissions.Why is that wrong?
SSO-mapped memberships are updated when the user logs in. Existing users pick up the change on their next login.
Covered in Mapping IdP groups to dbt groups
4.A Read-Only user placed in an Account Admin group can perform admin actions.Why is that wrong?
The license overrides group permission sets, so the Read-Only restriction still applies.
Covered in Where licenses cap RBAC
5.Adding the Developer permission set to a group leaves environments read-only unless you tick environment boxes.Why is that wrong?
For the Developer role, Environment write access defaults to All environments when it is added to a group, which includes Production.
Covered in Configuring a group's access and permissions
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Licenses are account-wide, and permissions provide more granular access or restrictions to specific features.”
↩︎ How RBAC grants access through groups“Every user in dbt must be assigned to at least one group.”
↩︎ How RBAC grants access through groups“or users assigned will not have access to features beyond their user profile”
↩︎ How RBAC grants access through groups“By default, dbt adds new users to this group.”
↩︎ Default groups and why to replace them“We recommend creating your own organizational groups so you can customize the permissions.”
↩︎ Default groups and why to replace them“You'll need a different user to make changes to your own user's group membership.”
↩︎ Default groups and why to replace them“Create new groups from the Groups & Licenses section of the Account settings.”
↩︎ Configuring a group's access and permissions“This elevated access doesn't grant users the ability to create or delete environments.”
↩︎ Configuring a group's access and permissions“SSO Mappings connect an identity provider (IdP) group membership to a dbt group.”
↩︎ Mapping IdP groups to dbt groups“New SSO users join any groups with the Add all new users by default option enabled.”
↩︎ Mapping IdP groups to dbt groups“Add an SSO mapping to an unmanaged group and it becomes managed”
↩︎ Mapping IdP groups to dbt groups“The Production environment is visible, but it is read-only, and they have full access in the Staging environment.”
↩︎ Mapping IdP groups to dbt groups“you can integrate user license distribution into the user provisioning process through your IdP”
↩︎ Where licenses cap RBAC“Role-based access control (RBAC) allows you to grant users access to features and functionality based on their group membership.”
↩︎ Key concept“you only assign them at the group level”
↩︎ Exam trap 1“Keep in mind that if a user belongs to multiple groups, the most permissive group will take precedence.”
↩︎ Exam trap 2“New SSO users will be added to the group upon login, and existing users will be added to the group upon their next login.”
↩︎ Exam trap 3“If a user is assigned licenses and permissions from multiple groups, the group that grants the most access will take precedence.”
↩︎ Checkpoint“Default permissions are broad, restricting only access to features that can alter billing or security.”
↩︎ Checkpoint“Group memberships are updated whenever a user logs into dbt via a supported SSO provider.”
↩︎ Prediction“If the name is not the same, the users will not be properly placed into the group.”
↩︎ Checkpoint - 2.
“A dbt group can be associated with more than one permission set. Permission assignments with more access take precedence.”
↩︎ How RBAC grants access through groups - 3.
“This safety ensures that an account admin is always available to manage group changes.”
↩︎ Default groups and why to replace them“If none are selected, the group will have read-only access.”
↩︎ Configuring a group's access and permissions“Each row can use the same permission set with different project and environment selections.”
↩︎ Checkpoint - 4.
“IT licensed users do not inherit rights from any permission sets.”
↩︎ Where licenses cap RBAC“a user with a Read-Only license cannot perform administrative actions, even if they belong to an Account Admin group.”
↩︎ Exam trap 4“User license types always override their assigned group permission sets.”
↩︎ Prediction“Read-only licensed users do not inherit rights from any permission sets.”
↩︎ Checkpoint
Also cited
“when added to a group, the Environment write access field defaults to All environments”
↩︎ Exam trap 5