What you will be able to do
- Explain what a deployment environment controls and how it differs from the single development environment
- Choose between the Production, Staging and General deployment types for a given purpose
- Create a deployment environment from Orchestration > Environments and fill in its general settings
- Complete both the deployment connection and the connection profile so jobs can actually run
Key concept
Deployment environment — A named set of settings in a dbt project that every job created inside it inherits: the dbt version, the code to run, where in the warehouse to build, and the credentials used to connect. A project can have any number of them, but only one may be the Production environment and only one may be Staging.
1.What a deployment environment controls
A job in dbt does not choose its own dbt version, branch or warehouse target. It inherits them from the environment it was created in. Every deployment environment fixes the version of dbt that runs the project, the warehouse connection information (including the target database and schema), the connection profile holding the credentials, and the version of your code to execute. It also records whether dbt State is enabled, which jobs in that environment can then inherit.
dbt has two kinds of environment, and they count differently. The development environment drives the Studio IDE and the dbt platform CLI, and a project has exactly one. Deployment environments drive job runs, and there is no limit on how many you create. That is why you add a new deployment environment, rather than a second development one, whenever you need another place for scheduled work, CI or a pre-production check. If you have used dbt v1, each environment is roughly one entry in profiles.yml, plus information about the repository so the right code is executed.
| Environment | Determines settings for | How many per project |
|---|---|---|
| Development | Studio IDE or dbt platform CLI | 1 |
| General (deployment) | dbt Job runs | Any number |
| Production (deployment) | dbt Job runs | 1 |
| Staging (deployment) | dbt Job runs | 1 |
Checkpoint 1 of 9· Check yourself
A project already has a development environment, one Production environment and two General environments. The team wants a Staging environment and a third General one. What happens?
General deployment environments are unlimited, and the project has no Staging environment yet, so it may add one. The only per-type caps are one Production, one Staging and one development environment.
“can have any number of General deployment environments, one Production deployment environment and one Staging deployment environment.”Source: docs.getdbt.com
Checkpoint 2 of 9· Exam question
A dbt Cloud project has both a Staging and a Production deployment environment, each with at least one successful job run recorded. A developer in Studio IDE enables the 'Defer to staging/production' toggle without setting the `--favor-state` flag. Against which environment's metadata will dbt resolve unbuilt upstream `ref()` calls by default?
Correct answer: A — Staging
- A. This is correct because dbt prefers Staging environment metadata over Production for deferral whenever a Staging environment with a successful run exists.
- B. This is incorrect as the default target: Production is only used as the fallback when no Staging environment with published metadata is available.
- C. This is incorrect because deferral resolves against another environment's already-built artifacts, not the developer's own in-progress development state.
- D. This is incorrect because deferral resolution follows the Staging-then-Production preference order, not recency of scheduling.
2.Choosing Production, Staging or General
The deployment type is the most important decision you make when creating the environment, because some platform features look for a specific type. Production is for transforming data and building pipelines for production use. Staging lets you work with production tools while limiting access to production data. General is a general-purpose environment for deployment development.
Production is the project's source of truth, and it is more than a label. Catalog and cross-project references depend on the designated production environment. Only one environment can be marked for final production workflows. Putting your real production runs in a General environment works in the sense that jobs run, but it is explicitly not recommended, and features that need a production environment won't treat it as one.
Checkpoint 3 of 9· Check yourself
Your nightly job builds the tables that BI dashboards and downstream projects rely on. Which deployment type should its environment use?
Final, source-of-truth data belongs in the single environment marked Production. Using a General environment for this purpose is not recommended.
“There can be only one environment marked for final production workflows and we don't recommend using a General environment for this purpose.”Source: docs.getdbt.com
Staging is worth creating when developers need deployment workflows without touching production data. It adds a validation layer where models can be deployed, tested and explored before they go live. It also lets developers create, edit and trigger ad hoc jobs while production stays locked down through [environment-level permissions](lesson:3.1). Staging gets its own view in Catalog, so pre-production data is visible next to prod. The simplest setup gives staging a long-lived branch, for example staging, that sits alongside main, and points the environment at it with a [custom branch](lesson:3.7).
Checkpoint 4 of 9· Exam question
An architect creates a new deployment environment named 'QA' and enables 'Only run on a custom branch', pointing it at the `release` branch instead of the connected repository's default branch. Which outcome accurately describes the effect of this setting on job runs in the QA environment?
Correct answer: A — dbt clones the `release` branch before each job run in QA, so builds reflect that branch's code instead of the default branch's code.
- A. This is correct because a deployment environment's custom branch setting changes which branch dbt clones before executing jobs, overriding the repository's default branch.
- B. This is incorrect because the custom branch setting changes the source code dbt clones, not the naming of the target schema, which is controlled separately.
- C. This is incorrect because dbt never performs git merges on behalf of a job; it only clones the branch configured for that environment.
- D. This is incorrect because the custom branch is simply cloned as-is on each run; dbt does not delete or recreate git branches as part of job execution.
Sources2
3.Creating the environment and its general settings
Every environment starts from the same entry point. Navigate to Orchestration > Environments, click Create Environment, and select Deployment as the environment type. The General Settings section follows, and its fields are shared by every environment type.
Checkpoint 5 of 9· Put it in order
Put the opening steps for creating a deployment environment in order.
- 1.Click Create Environment
- 2.Select Deployment as the environment type
- 3.Navigate to Orchestration > Environments
Environments are created from the Orchestration menu, and the environment type is chosen after Create Environment is clicked.
“To create a new dbt deployment environment, navigate to Orchestration > Environments and then click Create Environment.”Source: docs.getdbt.com
| Setting | Example value | What it decides |
|---|---|---|
| Environment name | Production | The environment name (any string) |
| Environment type | Deployment | Deployment or Development |
| Set deployment type | PROD | Production, Staging or General |
| dbt version | v1 Latest | The release track that dbt upgrades this environment along |
| Only run on a custom branch | ☑️ | Whether to use a branch other than the repository's default |
You don't pin dbt to a minor version here. You pick a release track, and dbt upgrades the environment automatically at that track's cadence. Account admins can set an org-wide default track for new projects, and project owners can override it per environment. That per-environment choice is what makes a cautious rollout possible: development and test environments on a faster track, production on a slower one, so new behaviour shows up before it reaches the source of truth. When a project has a staging environment, upgrade staging and work with it for a few days before upgrading production.
The branch setting decides which code a job runs. By default every environment uses the repository's default branch, usually main. In a deployment environment, a custom branch changes the branch that dbt clones before each job execution. The full branch behaviour, including what it does in development, is covered in [custom branches](lesson:3.7). If dbt State is enabled on your account, you can also turn it on here so that jobs in the environment inherit it.
Checkpoint 6 of 9· Check yourself
An Enterprise team wants production to get new dbt releases about a month after developers see them. Where is that controlled?
The release track is an environment setting. The cautious pattern puts production on v2 Extended while development stays on v2 Stable.
“Configure production environments to use v2 Extended (one month behind v2 Stable)”Source: docs.getdbt.com
4.Deployment connection and connection profile
A deployment environment can only run jobs once two separate settings are filled in. A common half-finished state is an environment with a connection and no profile: it saves, but its jobs can't run. The deployment connection says where dbt builds in the warehouse. The connection profile says how dbt authenticates. They are set at different scopes, and that affects who can change them and what gets reused.
| Setting | Scope | Controls |
|---|---|---|
| Deployment connection | Environment-level | Where dbt builds objects in your warehouse (database, schema, and warehouse) |
| Connection profile | Project-level (assigned to the environment) | How dbt authenticates, and the credentials it uses to connect |
Connections are created at the account level and then assigned to environments. A project can hold several connections of the same warehouse type, such as two Snowflake accounts, and some connection details can be overridden in the environment settings. Snowflake, for example, exposes Role, Database and Warehouse there. To move to a different warehouse type, create a new environment rather than editing the existing one. The credentials should belong to a dedicated user or service principal, not to a person; when to use one is covered in [service accounts](lesson:3.2). The target schema is a separate topic, covered in [default schemas](lesson:3.6).
Extended attributes cover anything the form doesn't show. They are a profiles.yml snippet set on the environment. Each attribute you supply replaces the same attribute from other sources, or adds it if it is missing. Postgres, Redshift, BigQuery and Spark don't show the environment's connection section at all, because their values are inferred from the connection, so extended attributes are how you override them. Keep secrets out of the text box by wrapping them in env_var.
Checkpoint 7 of 9· Fill the gap
Which function keeps the password out of the Extended Attributes text box and logs, resolving it at runtime instead?
dbname: jaffle_shop
schema: dbt_alice
threads: 4
username: alice
password: '{{ ? (''DBT_ENV_SECRET_PASSWORD'') }}'env_var reads the DBT_ENV_SECRET_PASSWORD environment variable at runtime, so the secret never appears in the text box. var reads project variables, not environment variables.
Source: docs.getdbt.comThat wrapping has one catch when the environment uses a connection profile. Profiles are environment-agnostic, so environment-scoped variables don't exist during a connection test. If an env_var in Extended Attributes is set only at the environment level, jobs still run, but the connection test fails. The fix is to give the variable a value in the Project default column under Orchestration > Environments > Environment variables. Variable scopes and precedence in general are covered in [environment variables](lesson:3.4).
Checkpoint 8 of 9· Check yourself
A new deployment environment's connection test fails, yet its jobs run fine. Extended Attributes contain password: '{{ env_var(''DBT_ENV_SECRET_PASSWORD'') }}', with the variable set only on this environment. What fixes the test?
Connection tests on a profile can't see environment-scoped variables. A project default value makes the variable available during the test.
“any env_var references in Extended Attributes must use project-scoped environment variables.”Source: docs.getdbt.com
Checkpoint 9 of 9· Exam question
A dbt Cloud service token used by a nightly CI integration needs to be rotated for security reasons. Which sequence of actions follows dbt's recommended rotation practice and avoids an integration outage?
Correct answer: A — Generate a new service token with the same permission set as the old one, update the CI system to use the new token, confirm the integration works, then delete the old token.
- A. This is correct because creating the replacement token first, verifying it works, and only then deleting the old one avoids a gap where the integration has no valid credential.
- B. This is incorrect because deleting the token before a replacement exists breaks the integration until the new token is generated and distributed, causing an outage.
- C. This is incorrect because narrowing permissions does not rotate the secret value itself, so a leaked or stale token value remains usable for authentication.
- D. This is incorrect because a system-level CI integration should authenticate with an account-owned service token, not a token tied to one person's individual permissions.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Once a deployment connection is assigned, the environment's jobs can run.Why is that wrong?
Jobs also need a connection profile assigned to the environment, which supplies the credentials dbt uses to authenticate.
Covered in Deployment connection and connection profile
2.Production data can live in a General environment, since every deployment type runs jobs the same way.Why is that wrong?
Source-of-truth data belongs in the single environment marked Production. Catalog and cross-project references depend on that environment, and using a General environment for this purpose is not recommended.
Covered in Choosing Production, Staging or General
3.Because deployment environments are unlimited, a project can have several Staging or Production environments.Why is that wrong?
Only General environments are unlimited. A project can have one Production environment, one Staging environment and one development environment.
Covered in What a deployment environment controls
4.An environment-scoped variable referenced in Extended Attributes works for both jobs and connection tests.Why is that wrong?
With connection profiles, connection tests can't see environment-scoped variables, so the variable needs a project default value.
Covered in Deployment connection and connection profile
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Each dbt project can have only one development environment, but there is no limit to the number of deployment environments”
↩︎ What a deployment environment controls“Deployment: determines the branch is cloned during job executions for each environment.”
↩︎ Creating the environment and its general settings“connection tests will fail if the referenced variable is only set at the environment level.”
↩︎ Deployment connection and connection profile“Determines the settings used when jobs created within that environment are executed.”
↩︎ Key concept“can have any number of General deployment environments, one Production deployment environment and one Staging deployment environment.”
↩︎ Exam trap 3“connection tests will fail if the referenced variable is only set at the environment level.”
↩︎ Exam trap 4“can have any number of General deployment environments, one Production deployment environment and one Staging deployment environment.”
↩︎ Checkpoint“any env_var references in Extended Attributes must use project-scoped environment variables.”
↩︎ Checkpoint - 2.
“The connection profile (the credentials dbt uses to connect)”
↩︎ What a deployment environment controls“Staging: Environment for working with production tools while limiting access to production data.”
↩︎ Choosing Production, Staging or General“This production environment is essential for using features like Catalog and cross-project references.”
↩︎ Choosing Production, Staging or General“Provide developers with the ability to create, edit, and trigger ad hoc jobs in the staging environment, while keeping the production environment locked down”
↩︎ Choosing Production, Staging or General“To create a new dbt deployment environment, navigate to Orchestration > Environments and then click Create Environment.”
↩︎ Creating the environment and its general settings“You can enable it on a deployment environment so that jobs in the environment can inherit the setting.”
↩︎ Creating the environment and its general settings“To change warehouse type, we recommend creating a new environment.”
↩︎ Deployment connection and connection profile“We recommend that the data warehouse credentials be for a dedicated user or service principal.”
↩︎ Deployment connection and connection profile“For all warehouses, use extended attributes to override missing or inactive (grayed-out) settings.”
↩︎ Deployment connection and connection profile“You need to complete both settings as a deployment connection on its own isn't enough for jobs to run.”
↩︎ Exam trap 1“This production environment is essential for using features like Catalog and cross-project references.”
↩︎ Exam trap 2“There can be only one environment marked for final production workflows and we don't recommend using a General environment for this purpose.”
↩︎ Checkpoint“You need to complete both settings as a deployment connection on its own isn't enough for jobs to run.”
↩︎ Prediction - 3.
“Individual project owners can then override that default per environment.”
↩︎ Creating the environment and its general settings“Configure production environments to use v2 Extended (one month behind v2 Stable)”
↩︎ Checkpoint