What you will be able to do
- Explain why dbt grants environment access by environment type, and what that means for a project with several General environments
- Tell apart the actions that environment write access allows from those it does not, including creating environments and editing environment variables
- Set up environment write access on a group, choosing a supported permission set and the right environment selection
- Match common personas to environment access and work out a user's effective access when several groups or a Read-Only license are involved
Key concept
Environment write access — A setting on a group's permission row that gives the group's permission set write access to jobs and runs in chosen environment types of a project. In every other environment, the same users have read-only access.
1.Environment types are the unit of access
Access control on environments decides who can change what runs where. If a developer can create and run jobs in Production, they can rebuild the tables the rest of the company treats as the source of truth. A developer who can only do that in Staging cannot. dbt draws this line with environment-level permissions: an admin grants write permission to groups and service tokens for particular environment types within a project.
Every dbt project has exactly one development environment, which drives the Studio IDE and the dbt platform CLI. A project can also have any number of deployment environments, which drive job runs (see [creating deployment environments](lesson:3.5)). Deployment environments come in three types. Counting development, there are four environment types, and each type has its own limit on how many a project can have.
| Environment type | What it determines settings for | How many per project |
|---|---|---|
| Development | Studio IDE or dbt platform CLI | 1 |
| Production | dbt Job runs | 1 |
| Staging | dbt Job runs | 1 |
| General | dbt Job runs | Any number |
Access is granted on the environment type, never on a single named environment. Take a project with two General environments, one for experiments and one for a nightly export. Both always have the same access, because a grant cannot pick one of them. Production, Staging and Development have one environment each, so for those types the type and the environment are the same thing.
Within an environment, access covers everything. Jobs and runs are both environment resources, and you cannot give a user access to jobs but not to runs. The feature also cannot create custom roles with permissions for each resource type. All it controls is whether a given group can write to a given type of environment.
A user's license sits above all of this. User license types always override group permission sets, so a user with a Read-Only license cannot perform administrative actions even when they belong to an Account Admin group. A group's environment write access can never lift a Read-Only user above read-only.
Checkpoint 1 of 7· Match them up
Match each environment type to how it is described
Tap a term, then the definition that fits it.
General is the only type a project can have more than one of. That is why a grant on the General type always covers every General environment in the project.
“Mixed use environments. No limit on the number per project.”Source: docs.getdbt.com
Checkpoint 2 of 7· Exam question
A user at an Enterprise dbt Cloud account holds a Read-Only license but has also been added to the Owner group, which carries the Account Admin permission set. When this user opens a production-critical project, what access do they actually end up with?
Correct answer: A — The user retains view-only access to environments and jobs because license type always overrides the permissions granted by group membership.
- A. Correct: in dbt Cloud, license type is evaluated before any group or permission-set access, so a Read-Only license caps the user to viewing environments and jobs regardless of which group's permission set is attached, including Account Admin.
- B. Incorrect: an Account Admin permission set only grants broad access when the user's license type also allows it; the license ceiling is enforced first, so Owner group membership cannot unlock write actions for a Read-Only licensee.
- C. Incorrect: dbt Cloud does not require permission-set and license alignment for login to succeed; a Read-Only user can log in and use any group they belong to, they simply cannot perform write actions.
- D. Incorrect: the Read-Only license restriction is not scoped to production alone; it limits the user to view-only access across the development environment and every deployment environment alike.
2.What write access grants, and what stays read-only
Environment write access is one specific power: creating, editing and deleting jobs and runs inside an environment. It does not let anyone create or delete the environments themselves. That takes a permission set with broader project access, such as Account admin (unrestricted access to every feature) or Admin (unrestricted access to existing projects). A Developer with write access to Staging can build and trigger as many Staging jobs as they like, but they cannot delete the Staging environment.
In an environment where a user has no write access, the environment is read-only. It is not hidden. In one onboarding example, an analyst is given the Analyst role on a single project with access to the Development, Staging and General environments. When they log in, Production still appears in the list. They can view it but change nothing, while in Staging they have full access. Environment-level permissions only offer write or read-only. There is no setting in between that decides which features inside an environment a user can reach.
Write access raises a permission set above its normal limits. The Analyst permission set, for example, has read-only access to jobs by default. Assign it to a group with Environment write access set to All environments, and every member can then create, edit and delete jobs in every environment of the projects the group covers. Only set environment write access when you mean to grant that. To give users only what their permission set already includes, leave every box unchecked.
The Database admin permission set shows where the raised access stops. With environment write access, a Database admin can write to jobs and runs, but environment variables stay read-only: they can override a variable's value on a job, but cannot create, edit or delete variables on the environment. Environment-level permissions are also separate from account-level RBAC and are configured in a different workflow. Group-based [role-based access control](lesson:5.6) and the [permission sets](lesson:5.2) themselves are covered in their own lessons.
Checkpoint 3 of 7· Check yourself
A group has the Developer permission set with environment write access to Staging only. Which of these can its members NOT do?
Write access covers creating, editing and deleting jobs and runs. It never covers creating or deleting environments. Production stays visible, but only as read-only.
“However, they don't grant users access to create or delete environments themselves.”Source: docs.getdbt.com
Checkpoint 4 of 7· Exam question
Which two statements accurately describe how dbt Cloud separates access control between the development environment and deployment environments within a single project? (Select two.)(Select 2)
Correct answers: A, B — Every project has exactly one development environment, and each developer authenticates to it using their own individually configured warehouse credentials.; A project can contain multiple deployment environments such as Staging and Production, sharing connection and credential settings configured at the environment level.
- A. Correct: dbt Cloud allows exactly one development environment per project, and each developer sets their own personal credentials under their profile so that IDE sessions use individually scoped warehouse access.
- B. Correct: unlike the single development environment, a project can have any number of deployment environments, and their connection and credential settings are configured once at the environment level rather than per person.
- C. Incorrect: deployment environments do not inherit a developer's personal credentials from the development environment; they are configured with their own environment-level connection settings independent of any individual's setup.
- D. Incorrect: dbt Cloud caps every project at a single development environment regardless of team size, so multiple developers share that one environment while each still uses their own personal credentials within it.
3.Configuring environment write access on a group
Environment write access is set on a group, under the group's permission rows. To configure it you need write permission to the Groups & Licenses settings of the account. Permissions can only be assigned to groups, never to individual users. To change one person's environment access, you change which groups they belong to.
Only five permission sets offer the environment option: Database admin, Git admin, Team admin, Analyst and Developer. The others are left out for one of two reasons. Some already have access to everything, such as Account admin. Others, such as Account viewer, can never have write access to environments. If you pick an unsupported set, the environment field does not appear at all. That is often the first sign you chose the wrong permission set. Job Admin is not on the list either; the persona guidance simply notes that it has access to all environments by default.
The Developer default is the one to watch. The Enterprise permissions table, which lists what each permission set can do, gives the Developer set read-only access to the configs for environments, jobs and runs. Once the set is added to a group, though, the Environment write access field defaults to All environments, so an unchanged Developer row can write to Production. Analyst, Database admin, Git admin and Team admin rows get read-only environment access by default unless you choose otherwise. (The setup page words the default more generally, as All environments for whichever supported set you pick.) The field allows several selections. If you clear every selection, the group is read-only.
One group can hold several rows with the same permission set, as long as each row has a different project scope or a different environment selection. For example, a single group could have Developer with write access to all environments in a sandbox project, plus Developer with write access to Development and General only in the finance project.
Checkpoint 5 of 7· Check yourself
An admin creates a group and selects the Account viewer permission set, then looks for the Environment write access field. What do they find?
The environment field exists only for the five supported sets. For any other set it is not shown, so write access cannot be configured on that row.
“If you select a permission set that is not supported, the environment permission option will not appear.”Source: docs.getdbt.com
4.Mapping personas and resolving overlapping grants
For a single project, the recommended pattern is to restrict Production and give groups write access to Development, Staging or General, where they can safely create and run jobs. Each persona then maps to a role plus a set of environment types. Only the people who actually deploy get Production.
| Persona | Role | Environment write access |
|---|---|---|
| Developer | Developer | Development and General |
| Testing/QA | Developer | Development, Staging, and General |
| Production deployment | Developer, or Job Admin | All environments (Job Admin has this by default) |
| Analyst | Analyst | None: read-only for discovery and troubleshooting |
The same mapping works across many projects. If a user has the same role in every project, apply the environment access across all projects. If access differs between projects, add more rows to the group. A developer working on three finance projects needs only Development and General access in those three, and nothing in the others.
Groups combine by taking the most access. If a user belongs to several groups, the group that grants the most access wins. Adding someone to a carefully restricted group therefore does nothing while another group still gives them more. This is why the default groups should be deleted in favour of your organisational groups: Owner and Member carry elevated defaults (Account admin for Owner, broad Admin-like privileges for Member), and Everyone, though customizable, adds every new user by default. Before deleting them, move every user, including yourself, into the right organisational groups.
Service tokens are a grant target too. Environment write access can go to a service token as well as a group, and some permission sets can be assigned to tokens, such as Account admin. Others cannot: v2 Migration Admin is for user accounts only.
A license is one limit that no group can override. User license types always override group permission sets. A user with a Read-Only license cannot perform administrative actions, even if they are in an Account Admin group. The IT license behaves the same way from the other side: IT-licensed users do not inherit rights from any permission set, and every IT user has the same access across the account whatever their groups say. A user's effective environment access therefore depends on three things: their license, the most generous group they belong to, and that group's environment selection.
Checkpoint 6 of 7· Check yourself
Priya has a Developer license. She is in a group with the Developer permission set and write access to Development and General. She is also still in a group with the Developer permission set and write access to All environments. What is her effective access to Production?
When groups overlap, the most generous grant wins. To restrict Priya, she has to be removed from the broader group. Adding her to a narrower one is not enough.
“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 7 of 7· Exam question
A CI/CD pipeline needs a dbt Cloud service token to trigger jobs across five different projects that all belong to the same Enterprise account. The platform team wants the token to follow least-privilege practice while still working reliably for every project it touches. What is the correct approach to scoping this token's permission set?
Correct answer: A — Assign the token the Job Admin permission set scoped to only the five specific projects the pipeline touches, rather than granting it access to every project in the account.
- A. Correct: service tokens support scoping a permission set to a specific list of projects rather than the whole account, so pairing Job Admin with exactly the five touched projects gives the pipeline the write access it needs without over-provisioning.
- B. Incorrect: Account Admin scoped account-wide grants far more than job-triggering capability across five projects, violating least privilege and exposing every other project in the account to the automation.
- C. Incorrect: personal access tokens are tied to an individual user's identity and permissions rather than being account-level credentials, so using several of them for a shared automated pipeline is the wrong token type for this system-level use case.
- D. Incorrect: IP allowlisting only restricts which network locations can present a token; it does not grant write capability, so a Read-Only permission set would still prevent the pipeline from triggering jobs regardless of the allowed IPs.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Adding the Developer permission set to a group leaves it read-only on environments until you grant write access.Why is that wrong?
When the Developer role is added to a group, the Environment write access field defaults to All environments, which includes Production. You have to narrow it on purpose.
2.Write access to an environment type lets a group create or delete environments of that type.Why is that wrong?
Environment write access covers creating, editing and deleting jobs and runs only. Creating or deleting environments needs an elevated permission set.
Covered in What write access grants, and what stays read-only
3.You can give a group write access to one particular General environment and keep another General environment read-only.Why is that wrong?
Grants apply to environment types, not to individual environments. Every General environment in the project gets the same access.
Covered in Environment types are the unit of access
4.A user with an IT license gets their environment access from the permission sets of the groups they belong to.Why is that wrong?
IT-licensed users do not inherit rights from any permission set. Every IT user has the same access across the account, whatever group permissions are assigned.
Covered in Mapping personas and resolving overlapping grants
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“You can only select environment types, and can’t specify a particular environment within a project.”
↩︎ Environment types are the unit of access“Access to a given environment gives the user access to everything within that environment.”
↩︎ Environment types are the unit of access“Environment-level permissions do not allow you to create custom roles and permissions for each resource type in dbt.”
↩︎ Environment types are the unit of access“Environment write permissions grant access to create, edit, and delete runs and jobs within an environment.”
↩︎ What write access grants, and what stays read-only“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.”
↩︎ Configuring environment write access on a group“we recommend restricting access to the Production environment”
↩︎ Mapping personas and resolving overlapping grants“Production Deployment: Developer role with write access to all environments or Job Admin which has access to all environments by default.”
↩︎ Mapping personas and resolving overlapping grants“If the user has the same roles across projects, you can apply environment access across all projects.”
↩︎ Mapping personas and resolving overlapping grants“Environment-level permissions give dbt admins the ability to grant write permission to groups and service tokens for specific environment types within a project.”
↩︎ Key concept“the Environment write access field defaults to All environments, which grants broader environment permissions than the table implies.”
↩︎ Exam trap 1“You can only select environment types, and can’t specify a particular environment within a project.”
↩︎ Exam trap 3“Mixed use environments. No limit on the number per project.”
↩︎ Checkpoint“However, they don't grant users access to create or delete environments themselves.”
↩︎ Checkpoint“the Environment write access field defaults to All environments, which grants broader environment permissions than the table implies.”
↩︎ Prediction - 2.
“Each dbt project can have only one development environment, but there is no limit to the number of deployment environments”
↩︎ Environment types are the unit of access - 3.
“User license types always override their assigned group permission sets.”
↩︎ Environment types are the unit of access“The Production environment is visible, but it is read-only, and they have full access in the Staging environment.”
↩︎ What write access grants, and what stays read-only“To grant users only the permissions inherent to their set, leave this setting blank (all boxes unchecked).”
↩︎ What write access grants, and what stays read-only“User license types always override their assigned group permission sets.”
↩︎ Mapping personas and resolving overlapping grants“IT licensed users do not inherit rights from any permission sets.”
↩︎ Mapping personas and resolving overlapping grants“Customize the permissions to fit your organizational needs.”
↩︎ Mapping personas and resolving overlapping grants“This elevated access doesn't grant users the ability to create or delete environments.”
↩︎ Exam trap 2“IT licensed users do not inherit rights from any 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 - 4.
“The environment-level permissions are write or read-only access.”
↩︎ What write access grants, and what stays read-only“Environment-level permissions are not the same as account-level role-based access control (RBAC) and are configured separately from those workflows.”
↩︎ What write access grants, and what stays read-only“you must have write permissions to the Groups & Licenses settings of your dbt account”
↩︎ Configuring environment write access on a group“Only the following permissions sets can have environment-level permissions configured”
↩︎ Configuring environment write access on a group“If none are selected, the group will have read-only access.”
↩︎ Configuring environment write access on a group“The default is All environments, but you can select multiple.”
↩︎ Configuring environment write access on a group“If you select a permission set that is not supported, the environment permission option will not appear.”
↩︎ Checkpoint - 5.
“It elevates job and run permissions to write, but leaves environment variables read-only.”
↩︎ What write access grants, and what stays read-only“Unrestricted access to every feature.”
↩︎ What write access grants, and what stays read-only“Read-only access to the underlying configs for environments, jobs, runs, and Git.”
↩︎ Configuring environment write access on a group“v2 Migration Admin — Assign to user accounts only. Cannot be assigned to service tokens.”
↩︎ Mapping personas and resolving overlapping grants