What you will be able to do
- Explain why a dbt platform warehouse connection is an account-level resource and how projects reach it through environments
- Decide when a project should use one connection and when it should use several
- Separate the shared details stored on a connection from the credentials set per environment or per user
- Prepare the warehouse side: allow dbt's IP addresses through the firewall and give the dbt user the privileges it needs
Key concept
Account-level connection — A warehouse connection in the dbt platform belongs to the account, not to a project. You create it once, and any project uses it by pointing one of its environments at it.
1.Warehouse connections live at the account level
dbt builds every model by running SQL against your data platform, so a project can't do anything until dbt can reach that platform. In the dbt platform, the details dbt uses to reach the warehouse are stored in a connection. A connection doesn't belong to any one project. It is an account-level resource: you click your account name, open Account settings, select Connections, and click New connection.
Because connections sit at the account level, projects can share them. If several projects all connect to the same warehouse, they should reuse one connection rather than each keep its own copy. That makes management simpler, because the warehouse's details live in one place. Creating and testing a connection for a particular project is covered in [creating and testing a connection](lesson:1.3).
Most platforms run on the v2 connection experience. Snowflake, Amazon Redshift, Databricks and Google BigQuery are available on v2, and ClickHouse is in private beta. A project on a platform that isn't on v2 yet can keep using v1 for now. If you have used dbt locally, you kept these details in a profiles.yml file. A dbt platform project doesn't need that file unless someone develops on their own machine instead of in the cloud UI.
| Connection | Available on v2 |
|---|---|
| Snowflake | Yes |
| Amazon Redshift | Yes |
| Databricks | Yes |
| Google BigQuery | Yes |
| ClickHouse | Private beta |
Checkpoint 1 of 9· Check yourself
Three dbt projects in one account all write to the same Snowflake warehouse. How should their connections be set up?
Connections are account-level and meant to be reused. When several projects share a warehouse, one connection keeps its details in one place.
“If multiple projects all connect to the same warehouse, you should re-use the same connection to streamline your management operations.”Source: docs.getdbt.com
Checkpoint 2 of 9· Exam question
A dbt Cloud Enterprise+ admin configures IP restrictions with only allow rules covering the office VPN CIDR block. The next day, the GitHub-triggered CI job for a pull request stops firing even though the PR was opened correctly. What is the most likely cause, and how should the admin fix it?
Correct answer: A — GitHub's webhook source IPs are missing from the allow list, so the inbound webhook call is rejected; add GitHub's published IP ranges to the allow list to restore CI triggering.
- A. An allowlist-only IP restriction denies every address not explicitly listed, and GitHub's webhook calls originate from GitHub's own IP ranges, not the office VPN. Adding those published ranges to the allow list is exactly what dbt's IP restriction guidance requires for git provider integrations.
- B. Enabling IP restrictions does not unlink a job from its deployment environment or connection; those associations are stored independently of network security settings, so recreating the job would not address a blocked webhook call.
- C. Creating an allow rule does not revoke existing service tokens. Service tokens are blocked by IP restrictions only when the request itself originates from a non-allowed IP, not automatically upon rule creation.
- D. Job trigger types are configuration fields set explicitly by an admin and are not reset by enabling account-level security features; the `github_webhook` trigger stays configured as-is.
2.Environments decide which connection a project uses
A project never attaches to a connection directly. Connections are assigned to a project through its environments. So a project with a development environment and a production environment can use one connection or two. If both environments point at the same connection, they share one warehouse instance. If you want production kept apart from non-production work, give the project two connections, one for each side.
This model replaces a common workaround. Some teams kept a single connection and used extended attributes on the production environment to override which warehouse instance it reached. Under account-level connections, the better design is a separate connection for that instance with the production environment wired to it, so the local override is no longer needed. Overrides you can't see from the connection list are easy to forget, and a connection that has its own name can be reused.
Naming matters once connections are shared across an account. Name each one after its server hostname plus what makes it distinct, such as its intended use (dev or prod) or its configuration, so that other projects can tell which one to reuse. Removing duplicates is usually good, with one exception. If two groups of users each need to maintain a connection to the same warehouse, keeping two identical connections lets each group change its own without affecting the other.
Deployment environments add one more layer. They reach a connection through a profile, which combines a connection with deployment credentials and extended attributes. Development environments don't use profiles, because each developer has their own credentials and configuration. Creating and configuring environments is covered in [creating a deployment environment](lesson:3.5).
Checkpoint 3 of 9· Check yourself
A production environment uses extended attributes to send its queries to a different warehouse instance than the shared connection points to. What is the recommended fix?
A dedicated connection for the production instance makes the local override unnecessary and gives that instance a reusable, named connection.
“you should instead create a new connection for that instance, and wire your production environment to it, removing the need for the local overrides”Source: docs.getdbt.com
Checkpoint 4 of 9· Put it in order
An account still has the messy connection list left over from project-level connections. Put the recommended clean-up stages in order.
- 1.Normalize: create new connections that replace local overrides, then test with jobs or Studio IDE sessions
- 2.Clean up: delete connections with 0 environments and rename the rest descriptively
- 3.Get granular: define each connection's intent and agree on a naming convention
- 4.Deduplicate: choose the surviving connections and point every relevant environment at them
Extended attributes are left alone during deduplication on purpose. They are removed only in the final normalization stage, once the connections they used to override exist.
“Do not update extended attributes at this stage”Source: docs.getdbt.com
Checkpoint 5 of 9· Exam question
Which of the following access paths are blocked by an Enterprise+ account's IP allowlist when a request originates from an IP address not on the list? (Select all that apply.)(Select 3)
Correct answers: A, B, C — Web UI login; Personal API token requests; Service token API requests
- A. IP restrictions block web interface login attempts from any address that is not on the allow list, showing an access-denied message to the user.
- B. Personal API tokens are blocked the same way as UI logins: a request from a non-allowed IP using a personal token is rejected regardless of the token's validity.
- C. Service token API requests are also gated by the allowlist; a valid service token cannot authenticate from an IP address that is not permitted.
- D. IP restrictions govern inbound access to dbt Cloud itself, not the outbound connections dbt Cloud makes to the warehouse on the account's behalf; that outbound traffic is unaffected by the allowlist.
3.What the connection holds and what credentials hold
A connection holds the details everyone who uses it shares. Credentials say who is connecting. For Snowflake, a new connection needs four fields. The Account field is the one people most often get wrong: it takes the account identifier, optionally with region and cloud, and not the full snowflakecomputing.com hostname.
| Field | Meaning | Example |
|---|---|---|
| Account | The Snowflake account to connect to | db5261993 or db5261993.east-us-2.azure |
| Role | The role to assume after connecting (mandatory) | transformer |
| Database | The logical database to connect to and run queries against | analytics |
| Warehouse | The virtual warehouse that runs the queries | transforming |
Credentials are set in two different places. Credentials for deployment environments (Production, Staging, General) are configured in the Connections area of Account settings. Each developer sets their own user credentials in the Credentials area of their user profile. The connection itself decides which authentication types those credentials can use, and that varies by platform.
| Platform | Supported authentication |
|---|---|
| Snowflake | User credentials, service account credentials, warehouse OAuth, external OAuth, key pair, MFA |
| BigQuery | User credentials, service account credentials, warehouse OAuth, external OAuth |
| Databricks | User credentials, service account credentials, warehouse OAuth |
| Redshift | User credentials only |
| ClickHouse | User credentials only |
On Snowflake, you can no longer create new credentials with a username and password in the dbt platform. New development and deployment credentials use key pair authentication by default. On Enterprise-tier plans, Snowflake OAuth is also available for user credentials once it has been configured on the connection. Setting these up is covered in [authenticating through OAuth](lesson:1.4), [rotating key pair authentication](lesson:3.3) and [when to use a service account](lesson:3.2).
Checkpoint 6 of 9· Check yourself
What do you enter in the Account field of a new Snowflake connection?
The Account field takes the account identifier, optionally with region and cloud. The full snowflakecomputing.com hostname is listed as an incorrect value.
“db5261993 or db5261993.east-us-2.azure”Source: docs.getdbt.com
Checkpoint 7 of 9· Match them up
Match each credential to where it is configured or what it defaults to
Tap a term, then the definition that fits it.
Deployment credentials are set centrally, user credentials are set by each person, and new Snowflake credentials default to key pair because new username and password credentials can't be created.
“Configure deployment environment (Production, Staging, General) credentials globally in the Connections area of Account settings.”Source: docs.getdbt.com
Sources4
4.Letting dbt through the firewall and into the database
dbt always connects to your warehouse from the fixed set of IP addresses listed on the Regions & IP addresses page. Those addresses need to be allowed in your firewall and included in any IP-based database grants. Otherwise jobs and development sessions can't reach the warehouse, even if every credential is correct. This rule only covers traffic into your warehouse. To send API requests from your network to dbt, you also need to allow the cloud.getdbt.com subdomain. Restricting which IPs can reach dbt itself is a different control, covered in [configuring the IP allowlist](lesson:1.2).
Once dbt can reach the warehouse, the user it connects as needs the right privileges. That user must be able to select from the raw data, create schemas and the tables and views inside them, and read system views such as information_schema to generate documentation. On Postgres, Redshift, Databricks and Snowflake, you give these through grants. On BigQuery, the "BigQuery User" role covers them. Another option is for a separate user to create the schema and grant the dbt user rights inside it, but letting dbt create its own schemas is simpler to run.
Snowflake spells this out in detail. The account, the user, a role assigned to that user, a warehouse, and the target databases and schemas must all exist before you connect. The privileges dbt needs are then granted through that role.
| Permission | Object | Why dbt needs it |
|---|---|---|
| USAGE | Warehouse | Execute queries |
| SELECT | Tables or views | Read existing data and sources |
| CREATE TABLE / CREATE VIEW | Schema | Materialize models as tables or views |
| USAGE | INFORMATION_SCHEMA | Query table and column metadata |
| CREATE SCHEMA | Database | Only if dbt should auto-create schemas |
Checkpoint 8 of 9· Check yourself
How do you give a dbt user on BigQuery the privileges to read raw data, create schemas and read metadata views?
BigQuery uses a role instead of a series of grants. Allowing dbt's IP addresses only opens the network path and gives no database privileges.
“On BigQuery, use the "BigQuery User" role to assign these privileges.”Source: docs.getdbt.com
Checkpoint 9 of 9· Exam question
At what level are data warehouse connections configured in dbt Cloud, and what does that scope enable?
Correct answer: A — Connections are configured as an account-level resource under Account Settings, which lets one connection be reused across multiple projects and environments.
- A. Warehouse connections live under Account Settings → Connections as an account-level resource, and are assigned to projects through environments, allowing a single connection to serve multiple projects.
- B. Connections are not scoped per project; they are created once at the account level and can be shared across projects rather than duplicated for each one.
- C. Individual developer credentials authenticate a specific user to a warehouse, but the underlying connection definition itself is an account-level object, not something tied to one developer's profile.
- D. Jobs reference a connection indirectly through the environment they run in; the connection itself is not defined or stored inside a job's run steps.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Each dbt project owns its warehouse connection, so two projects on the same warehouse need two connections.Why is that wrong?
Connections are account-level and can be reused across projects. Projects that share a warehouse should share one connection.
2.A project can only use one connection, so keeping production apart from development means overriding settings on one connection.Why is that wrong?
Connections are assigned through environments. To keep production apart, give the project more than one connection.
Covered in Environments decide which connection a project uses
3.Development environments reach their connection through a platform profile, just as deployment environments do.Why is that wrong?
Profiles apply only to deployment environments. Development environments rely on each developer's own credentials.
Covered in Environments decide which connection a project uses
4.Once dbt's IP addresses are allowed in the firewall, the network can also call the dbt API.Why is that wrong?
Those IPs only open the path from dbt into the warehouse. Calling the dbt API needs the cloud.getdbt.com subdomain allowed as well.
Covered in Letting dbt through the firewall and into the database
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Select Connections from the top left, and from there, click New connection.”
↩︎ Warehouse connections live at the account level“You can continue using v1 for that project in the meantime.”
↩︎ Warehouse connections live at the account level“Connections are assigned to a project via an environment.”
↩︎ Environments decide which connection a project uses“a project with 2 environments can target between 1 and 2 different connections.”
↩︎ Environments decide which connection a project uses“We recommend you name connections after the server hostname and distinct intent/domain/configuration.”
↩︎ Environments decide which connection a project uses“you may want to preserve two identical connections to the same warehouse”
↩︎ Environments decide which connection a project uses“dbt will always connect to your data platform from the IP addresses specified in the Regions & IP addresses page.”
↩︎ Letting dbt through the firewall and into the database“Be sure to allow traffic from these IPs in your firewall, and include them in any database grants.”
↩︎ Letting dbt through the firewall and into the database“Warehouse connections are an account-level resource. You can find them under Accounts settings > Connections.”
↩︎ Key concept“Warehouse connections can be re-used across projects.”
↩︎ Exam trap 1“If you want to separate your production environment from your non-production environment, assign multiple connections to a single project.”
↩︎ Exam trap 2“Using the dbt API requires allowing the cloud.getdbt.com subdomain.”
↩︎ Exam trap 4“If multiple projects all connect to the same warehouse, you should re-use the same connection to streamline your management operations.”
↩︎ Checkpoint“you should instead create a new connection for that instance, and wire your production environment to it, removing the need for the local overrides”
↩︎ Checkpoint“Do not update extended attributes at this stage”
↩︎ Checkpoint“Allowing these IP addresses only enables the connection to your data warehouse.”
↩︎ Prediction - 2.
“dbt platform projects don't require a profiles.yml file unless you're developing from your local machine instead of the cloud-based UI.”
↩︎ Warehouse connections live at the account level - 3.https://docs.getdbt.com/docs/platform/about-profilesOfficial docs
“dbt platform profiles define the connections, credentials, and attributes you use to connect to a data warehouse.”
↩︎ Environments decide which connection a project uses“Profiles don't apply to development environments because of the unique configurations and individual credentials applied.”
↩︎ Exam trap 3 - 4.
“Individual users configure their user credentials in the Credentials area of their user profile.”
↩︎ What the connection holds and what credentials hold“You cannot create new Snowflake credentials with username and password in dbt platform.”
↩︎ What the connection holds and what credentials hold“New development and deployment credentials default to key pair authentication.”
↩︎ What the connection holds and what credentials hold“A mandatory field indicating what role should be assumed after connecting to Snowflake”
↩︎ What the connection holds and what credentials hold“Before connecting, these objects must exist:”
↩︎ Letting dbt through the firewall and into the database“db5261993 or db5261993.east-us-2.azure”
↩︎ Checkpoint“Configure deployment environment (Production, Staging, General) credentials globally in the Connections area of Account settings.”
↩︎ Checkpoint - 5.
“read system views to generate documentation (i.e. views in information_schema)”
↩︎ Letting dbt through the firewall and into the database“We generally recommend granting your dbt user the ability to create schemas, as it is less complicated to implement.”
↩︎ Letting dbt through the firewall and into the database“On BigQuery, use the "BigQuery User" role to assign these privileges.”
↩︎ Checkpoint