What you will be able to do
- Explain which traffic dbt IP restrictions block and what a blocked request looks like
- Predict the outcome of overlapping allowlist and blocklist rules
- Add allow and deny rules in CIDR notation and turn on enforcement without locking anyone out
- Allow dbt's own IP addresses on the warehouse side, including in Snowflake network policies
Key concept
An allowlist denies everything else — When IP restrictions are on and only an allowlist exists, dbt refuses every address outside the listed CIDR ranges. You only need a blocklist to block part of a range you have already allowed.
1.What IP restrictions control in dbt
IP restrictions decide which source addresses can reach your dbt account at all. They help an organisation meet security and compliance controls by letting in only approved networks, such as a corporate VPN, a contractor's office or a CI provider. You set them up under Account Settings → IP Restrictions. The feature is available on the Enterprise+ and Virtual Private tiers.
The restriction covers every way into the account, not only the login page. dbt refuses requests from a blocked address whether they come from a service token, an API call made with a personal user token, or a normal browser session in the UI. A valid token does not get past the network check, and this is what catches people out. A scheduled script that worked yesterday starts failing as soon as enforcement is turned on, even though its credentials never changed. Tokens themselves are covered in [service tokens for API access](lesson:5.1).
You can tell a blocked request by its error. A user who signs in from a restricted address sees "Access denied! Please contact your admin for more details.", whether they log in with email and password or with SSO. A service-token call gets HTTP 403 with the message "Forbidden: Access denied", and the response body sets account_access_denied to true. That 403 means the caller's IP is not on the allowlist. The fix is to add the integration's CIDR ranges, not to rotate the token.
"status": {
"code": 403,
"is_success": False,
"user_message": ("Forbidden: Access denied"),
"developer_message": None,
},Checkpoint 1 of 8· Check yourself
After IP restrictions are turned on, a nightly script that triggers jobs with a service token starts getting a 403 "Forbidden: Access denied". What is the right fix?
The 403 means the source IP is not on the allowlist. Service tokens and personal tokens are both blocked from restricted IPs, and no permission set gets around the network check.
“the following 403 response error indicates the IP is not on the allowlist.”Source: docs.getdbt.com
2.How allowlist and blocklist rules combine
Every rule is either Allow or Deny, which gives you two lists. Most accounts use only an allowlist, and that works on its own: dbt admits the listed ranges and refuses everything else, so you don't need a deny-all rule. A blocklist is useful when you need to shut out part of an allowed range, such as a VPN subnet the security team has flagged.
Overlapping rules are resolved by nesting, not by a fixed priority. A range can be on one list while a sub-range or single address inside it is on the other, and the narrower entry acts as the exception. A deny rule does not automatically beat an allow rule, and an allow rule does not automatically beat a deny rule. The one thing you cannot do is put the identical address on both lists: the second entry fails to save.
| Configuration | Result |
|---|---|
| Allowlist only (for example a corporate VPN range) | Listed ranges allowed; all other IPs denied |
| Wide range on allowlist, sub-range on blocklist | Wide range allowed except the sub-range, which is blocked |
| Wide range on blocklist, sub-range on allowlist | Wide range blocked except the sub-range, which is allowed |
| Identical address on both lists | The second entry fails to save |
Checkpoint 2 of 8· Match them up
Match each security requirement to the rule setup that meets it
Tap a term, then the definition that fits it.
An allowlist on its own denies everything not listed. You add exceptions as more Allow rules, and you only need a Deny rule to block a sub-range of an allowed range.
“you can add a blocklist if you want to deny specific IP addresses within your allowlist CIDR range.”Source: docs.getdbt.com
Checkpoint 3 of 8· Exam question
A dbt Cloud admin on an Enterprise+ plan opens Account Settings, goes to IP Restrictions, and creates only an Allow rule containing the corporate VPN's CIDR range, with no Deny rule configured anywhere in the account. After the admin enables the feature and saves, a data engineer tries to sign in to the dbt Cloud UI from home WiFi whose address falls outside that CIDR range. What happens?
Correct answer: A — The sign-in attempt is rejected, because configuring only an Allow list causes every address outside the listed ranges to be denied by default.
- A. This matches dbt Cloud's documented behavior: when only an Allow list is configured, any address not covered by a listed range is denied by default without needing a separate Deny rule.
- B. This is incorrect because a Deny rule is not a prerequisite for enforcement; an Allow-only configuration already produces default-deny behavior for unlisted addresses.
- C. This is incorrect because IP restrictions apply uniformly to UI sign-ins, service tokens, and personal API tokens together, not to the UI alone.
- D. This is incorrect because there is no documented time-based cache or retry window; enforcement is based on the current rule configuration, not a temporary lockout timer.
Sources1
3.Adding rules and turning on enforcement
You write rules in CIDR notation and group them under a name. On the IP Restrictions page, click Edit, then Add Rule. Give the rule a name and description, such as "Corporate VPN CIDR Range". Choose Allow or Deny, enter the ranges and click Save. One rule can hold several ranges, and Add IP range opens another field for the next one. You build a blocklist rule the same way with Deny selected, and it also accepts single addresses.
Checkpoint 4 of 8· Put it in order
Put the steps for adding an allowlist rule in order
- 1.Click Save
- 2.Click Edit on the IP Restrictions page
- 3.Add the ranges in CIDR notation
- 4.Click Add Rule
- 5.Add a name and description for the rule
- 6.Select Allow
You open the page for editing, create the rule, name it, choose Allow, add the ranges, and only then save.
“Add the ranges in CIDR notation. For example, 1.1.1.1/8 You can add multiple ranges in the same rule.”Source: docs.getdbt.com
Saving rules does not enforce them. Enforcement is a separate switch: once all your ranges are in, select Enable IP restrictions and click Save. Because these are two steps, you can build and review the full list before anything is refused.
dbt also stops admins from locking themselves out. If the address you are working from falls inside any blocklist range, dbt will not let you save or turn on IP restrictions. If you are locked out later because your own IP changed, contact support@getdbt.com to get back in.
The ranges people most often forget belong to systems that call dbt, not to people. Git integrations with GitHub, GitLab, Azure DevOps and other providers send traffic into dbt. Their IP addresses must be on the allowlist, or those integrations break as soon as enforcement starts. The same applies to any third-party tool that calls the API with a service token. The integrations themselves are covered in [git provider integrations](lesson:2.2).
Checkpoint 5 of 8· Check yourself
An admin adds a VPN allowlist rule and saves it. A colleague outside the VPN can still open dbt. Why?
Adding ranges only defines the lists. The restrictions take effect once Enable IP restrictions is selected and saved, and they apply to SSO logins too.
“Simply adding the IP ranges does not enforce IP restrictions.”Source: docs.getdbt.com
Checkpoint 6 of 8· Exam question
An account has an Allow rule covering 10.0.0.0/8 and a separate Deny rule covering the narrower block 10.20.0.0/16, which sits entirely inside that Allow range. A workstation at 10.20.5.9 tries to reach dbt Cloud. Which outcome matches dbt Cloud's documented handling of overlapping ranges?
Correct answer: A — The connection is blocked, because a Deny rule for a nested subset range takes precedence over the broader Allow rule that contains it.
- A. This matches the documented priority logic: when a narrower Deny range is nested inside a broader Allow range, the narrower Deny rule wins for the addresses it covers.
- B. This reverses the actual priority; the narrower, more specific range takes precedence over the broader one that contains it, not the other way around.
- C. This is incorrect because overlapping Allow and Deny ranges of different types are an expected and supported way to carve out exceptions; only identical duplicate addresses across the two lists are rejected.
- D. This is incorrect because there is no documented grace period; the priority outcome for overlapping ranges is immediate and not time-limited.
4.Allowing dbt's IP addresses at the warehouse
IP allowlisting also works in the other direction. Your dbt account connects to your data platform and git provider from a fixed set of IP addresses tied to its hosting region. If your warehouse has a firewall or network policy, it must let those addresses in. Add them to the firewall and to any database grants that restrict access by source IP. The connection itself is covered in [connecting the warehouse](lesson:1.1); this section covers only the network access it needs.
| Region | Access URL | IP addresses |
|---|---|---|
| AWS us-east-1 (N. Virginia) | ACCOUNT_PREFIX.us1.dbt.com | 52.45.144.63 54.81.134.249 52.22.161.231 52.3.77.232 3.214.191.130 34.233.79.135 |
| AWS eu-central-1 (Frankfurt) | ACCOUNT_PREFIX.eu1.dbt.com | 3.123.45.39 3.126.140.248 3.72.153.148 |
| Azure East US 2 (Virginia) | ACCOUNT_PREFIX.us2.dbt.com | 20.10.67.192/26 |
| Virtual Private dbt or Single tenant | Customized | Ask Support for your IPs |
dbt shows the exact list for your account. In an existing project, open Account Settings, select the project, click the name in the Connection field and scroll down to Settings. The first text block lists the IPs. In a new account, they appear during the Configure your environment step when you create a project. Single-tenant and Virtual Private accounts get their addresses from Support.
Allowing these addresses only opens the path from dbt to the warehouse. If people on a restricted network also need to send requests to the dbt API, that network must allow the cloud.getdbt.com subdomain as well.
Snowflake OAuth needs one more step. If your Snowflake account uses network policies, you may have to attach the network policy that contains the dbt IPs directly to the security integration created for dbt OAuth. Without it, Snowflake can refuse OAuth sign-ins from dbt even though the IPs are allowed elsewhere. The OAuth setup itself is covered in [Snowflake OAuth](lesson:1.4).
Checkpoint 7 of 8· Fill the gap
Which property attaches the policy that allows dbt's IPs to the Snowflake security integration?
ALTER SECURITY INTEGRATION <security_integration_name>
SET ? = <network_policy_name> ;The security integration takes a NETWORK_POLICY: the policy that already includes the allowlisted dbt IPs.
Source: docs.getdbt.comCheckpoint 8 of 8· Exam question
A finance analytics team enables IP restrictions on their Enterprise+ account with an Allow rule limited to the office network's CIDR range. Someone outside that network then tries several ways to reach the account. Select every access path below that the documented IP restriction actually blocks when the request originates from a disallowed address.(Select 3)
Correct answers: A, B, C — A browser sign-in attempt to the dbt Cloud web application, made directly from the disallowed address by the outside user.; An automated request authenticated with an account-level service token, sent to the API from the disallowed address.; A request authenticated with a user's personal API token, sent to the API from that same disallowed address.
- A. IP restrictions block UI sign-in attempts from disallowed addresses, so this path is correctly included as one that gets blocked.
- B. Service token requests are explicitly covered by IP restrictions, so a disallowed address is blocked even when the request is automated and properly authenticated.
- C. Personal API token requests are covered the same way as UI and service token access, so this path is also blocked when it originates from a disallowed address.
- D. This is the false statement: git provider webhook calls are not exempt, and their published IP ranges must be explicitly added to the Allow list or the inbound webhook traffic gets blocked like any other disallowed address.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.An allowlist does nothing until you add a deny-all rule to the blocklist.Why is that wrong?
An allowlist on its own already denies every IP outside its ranges. You only need a blocklist to deny sub-ranges inside an allowed range.
Covered in How allowlist and blocklist rules combine
2.API calls made with a service token or personal token get past IP restrictions because they are authenticated.Why is that wrong?
dbt blocks service tokens, API requests made with personal tokens, and the UI when they come from a blocked IP.
Covered in What IP restrictions control in dbt
3.Allowing the corporate VPN is enough, and git integrations keep working because dbt starts those connections.Why is that wrong?
Version control integrations send traffic into dbt, so you must add their IP addresses to the allowlist.
Covered in Adding rules and turning on enforcement
4.Allow and deny rules take effect as soon as you save them.Why is that wrong?
Enforcement starts only when you select Enable IP restrictions and save. You also can't turn it on while your own IP is inside a blocklist range.
Covered in Adding rules and turning on enforcement
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“To configure IP restrictions, go to Account Settings → IP Restrictions.”
↩︎ What IP restrictions control in dbt“This feature is available on the following dbt Enterprise tiers:”
↩︎ What IP restrictions control in dbt“IP restrictions block all service tokens, user requests made through the API (using personal user tokens), and the UI”
↩︎ What IP restrictions control in dbt“Access denied! Please contact your admin for more details.”
↩︎ What IP restrictions control in dbt“IPs in the allowlist can access dbt, and IPs in the blocklist are blocked from accessing dbt.”
↩︎ How allowlist and blocklist rules combine“If identical IP addresses are in both the allow and block configurations, the second entry fails to save.”
↩︎ How allowlist and blocklist rules combine“USA is on the allowlist and NY is on the blocklist — USA traffic is allowed, but IPs from NY are blocked.”
↩︎ How allowlist and blocklist rules combine“you can enable IP restrictions by selecting Enable IP restrictions and clicking Save.”
↩︎ Adding rules and turning on enforcement“Add multiple IP ranges by clicking the Add IP range button to create a new text field.”
↩︎ Adding rules and turning on enforcement“By default, if you only add an allowlist, dbt only allows IPs in the allowable range and denies all other IPs.”
↩︎ Key concept“you don't need to add a blocklist. By default, if you only add an allowlist, dbt only allows IPs in the allowable range”
↩︎ Exam trap 1“IP restrictions block all service tokens, user requests made through the API (using personal user tokens), and the UI”
↩︎ Exam trap 2“For any version control system integrations (GitHub, GitLab, ADO, and others) inbound into dbt, ensure you add their IP addresses to the allowed list.”
↩︎ Exam trap 3“If your IP address is in any of the blocklist ranges, you can't save or enable IP restrictions — this prevents accidental account lockouts.”
↩︎ Exam trap 4“USA is on blocklist and NY is on allowlist — Traffic from the USA is blocked, but IPs from NY are allowed.”
↩︎ Prediction“you can add a blocklist if you want to deny specific IP addresses within your allowlist CIDR range.”
↩︎ Checkpoint“Add the ranges in CIDR notation. For example, 1.1.1.1/8 You can add multiple ranges in the same rule.”
↩︎ Checkpoint“Simply adding the IP ranges does not enforce IP restrictions.”
↩︎ Checkpoint - 2.
“To resolve this, you should add your third-party integration CIDRs (network addresses) to your allowlist.”
↩︎ What IP restrictions control in dbt“the following 403 response error indicates the IP is not on the allowlist.”
↩︎ Checkpoint - 3.
“Azure's provisioning service IPs rotate approximately every two weeks and can't be statically allowlisted.”
↩︎ Adding rules and turning on enforcement“Use the dbt platform Admin API with a service token to update your IP allowlist on a schedule”
↩︎ Adding rules and turning on enforcement - 4.
“Be sure to allow traffic from these IPs in your firewall, and include them in any database grants.”
↩︎ Allowing dbt's IP addresses at the warehouse“Using the dbt API requires allowing the cloud.getdbt.com subdomain.”
↩︎ Allowing dbt's IP addresses at the warehouse - 5.
“Locate the Connection field and click on the name. Scroll down to the Settings, and the first text block lists your IP addresses.”
↩︎ Allowing dbt's IP addresses at the warehouse - 6.
“you may have to explicitly add the network policy that includes the allow listed dbt IPs to the security integration you just made.”
↩︎ Allowing dbt's IP addresses at the warehouse