What you will be able to do
- Tell a service account token apart from a personal access token (PAT) by who owns it and where its permissions come from
- Pick the right token type for partner integrations, Terraform, scripts, the dbt platform CLI and user-context API endpoints
- Explain why a service token needs a narrow scope and why a PAT can't stand in for one
- Explain why deployment environments should connect to the warehouse as a dedicated user or service principal, not as a person
Key concept
Service account token — An API credential owned by the dbt account rather than by any person. You give it exactly the permission sets it needs. It is the credential for production and system-level workflows that must keep working whoever is employed that week.
1.Account-owned versus user-owned credentials
Every call to the dbt API is made as someone. Either it is made as a person, or it is made as the account itself. The two credential types follow that split. A personal access token (PAT) belongs to a user. A service account token belongs to the account. Choosing a service account comes down to one question: should this workflow stop working when a particular person's access changes?
A PAT carries whatever its creator holds. Suppose a developer-licensed user has the Project Admin role on two projects. Every PAT they create gets Project Admin on those same two projects, no more and no less. That is convenient when the person is the one doing the work. It is a liability when a scheduled integration quietly picks up a human's full reach, or loses it when that human changes teams. PATs are also tied to one account: a user with access to several dbt accounts needs a separate PAT for each.
A service account token is not tied to a person, and its permissions aren't inherited from anyone. You assign permission sets to the token directly, so its access is whatever you choose to give it. That makes it the natural credential for system-level integrations: a reverse-ETL tool, an observability product, an in-house app that triggers jobs. None of these act on behalf of one person. User API tokens, the older user-scoped credential, are deprecated and no longer work. On the user side, the PAT is the only option left.
Checkpoint 1 of 7· Check yourself
A data engineer creates a token so a nightly reconciliation service can call the dbt API. Six months later the engineer leaves and their dbt user is removed. Which token type would have kept the service running?
A service account token is owned by the account, so it doesn't depend on any one person staying. A PAT is the user's own credential and carries that user's permissions. User API tokens are deprecated altogether.
“While similar to personal access tokens, service account tokens belong to an account rather than a user.”Source: docs.getdbt.com
2.Production workflows get a service token; developmental workflows get a PAT
One rule settles most cases. Use a service token for any production workflow that needs a service account. Use a PAT only for developmental work, or for client workflows that need to know which user is calling. What matters is the workflow's stage and its need for a user identity. The tool involved doesn't decide it. The same Terraform code can call for either token, depending on where it runs.
| Workflow | Token | Reason |
|---|---|---|
| Partner integration (Semantic Layer Google Sheets, Hightouch, Datafold, a custom app) | Service token | Gives visibility and can be scoped to only what the integration needs |
| Production Terraform | Service token | A production workflow acting as a service account, not a user account |
| dbt platform CLI | PAT | The CLI works within the context of a user, who is the one making the requests |
| Testing a custom script; staging Terraform or Postman | PAT | A developmental workflow scoped to the user making the changes |
| API endpoints requiring user context (for example, creating and updating user credentials) | PAT | The endpoint needs a user identity |
Partner integrations are the case most teams get wrong. Wiring Hightouch or Datafold to dbt with someone's PAT works on day one, so it is easy to leave in place. But that integration now holds everything that person can do, and nobody looking at the account can easily see what the integration itself is allowed to do. A service token fixes both problems. It shows up as its own credential, and it carries only the permissions the integration needs. If an integration runs on a PAT today, the recommended move is to switch it to a service token.
The dbt platform CLI goes the other way. A developer running commands from a laptop is acting as themselves, and requests are made in their user context. A service token has no user, so it doesn't fit. The same is true of API endpoints that act on a specific user's records, such as creating or updating user credentials.
Checkpoint 2 of 7· Match them up
Match each workflow to the token it should use and the reason
Tap a term, then the definition that fits it.
Production and integration workflows act for the account, so they take service tokens. Work done by a person, either interactively or while testing, takes that person's PAT.
“You should use PATs only for developmental workflows or dbt client workflows that require user context.”Source: docs.getdbt.com
Checkpoint 3 of 7· Exam question
A platform team is building a Terraform pipeline that calls the dbt Cloud Administrative API every night to trigger jobs and pull run artifacts, with no engineer signed in during the run. Which credential should back this integration?
Correct answer: B — A service token scoped to only the permissions the pipeline actually needs
- A. Personal tokens are tied to one user's identity and access, so the automation breaks or loses permissions the moment that person leaves, changes role, or has their access revoked, which is exactly the coupling a system integration should avoid.
- B. A service token belongs to the account rather than an individual, so it keeps working independent of any one person's employment status, and scoping it narrowly limits the blast radius if the credential ever leaks.
- C. Sharing an interactive account login as a stored secret mixes human and machine access, defeats audit trails that attribute actions to a specific token, and grants far more privilege than a nightly job needs.
- D. Interactive authentication requires a human to complete a login step, which is incompatible with an unattended nightly pipeline that must run without anyone present to approve it.
Checkpoint 4 of 7· Exam question
An architect is deciding how to authenticate a new monitoring script that only needs to read job run metadata for a single project and must never be able to trigger a run or change project settings. Evaluate this option and answer Yes or No: Create a service token with the Metadata Only permission set, scoped to that one project.
Correct answer: A — Yes
- Yes. Metadata Only grants read-only access to metadata and, combined with project-level scoping, matches the script's actual needs exactly, so it cannot start jobs or edit settings even if the token were exposed.
- No. This is incorrect to reject: a narrowly scoped, read-only service token is the recommended fit for a monitoring integration, so declining it in favor of a broader credential would violate least-privilege practice for no benefit.
Sources3
3.Scoping a service token to least privilege
A service token is only safer than a PAT if you scope it narrowly. You attach permission sets to the token, as many as the job needs. For each set, you choose whether it applies to all projects in the account or only to specific ones. An integration that reads metadata for one project should get a metadata-level set on that one project. It should not get account-wide access because that was quicker to click through. The mechanics are covered in [creating service tokens](lesson:5.1) and [permission sets](lesson:5.2). The point here is that a narrow scope is one of the reasons to choose a service token in the first place.
| Property | Personal access token | Service account token |
|---|---|---|
| Owner | The user who created it | The dbt account |
| Where permissions come from | Inherited from the creating user | Permission sets assigned to the token, across all projects or specific ones |
| Typical use | Developmental workflows and user-context calls | Production workflows and system-level integrations |
| Can create a service token | No, the request returns a 400 error | Yes, existing service tokens can create new ones |
Account Admin is the permission set to be most careful with. An Account Admin service token has full read and write access to the whole account, and nothing ties it to a person who might notice it being misused. Give it only to the rare integration that genuinely manages the account. Any other integration that holds it can do far more than it needs.
Your plan limits what a service token can carry, and that can decide whether a service token is even an option. Enterprise and Enterprise+ plans can attach any permission set available to service tokens. Developer and Starter plans can attach only Semantic Layer permissions. Legacy Team plans get a fixed list: Account Admin, Member, Job Admin, Read-Only, Metadata and Semantic Layer. Creating a service token at all requires a Developer license with account admin permissions.
Checkpoint 5 of 7· Check yourself
An admin writes a bootstrap script that calls the API to create a service token for a new integration. They authenticate the script with their own PAT, which has full admin permissions. What happens?
Service token creation can't be authenticated with a PAT, however broad the creator's permissions are. Use an existing service token instead.
“Requests to create a service token authenticated with a PAT return a 400 error”Source: docs.getdbt.com
Checkpoint 6 of 7· Exam question
A data analyst wants to run occasional ad-hoc queries against dbt models from a personal Python notebook on their laptop, using their own dbt Cloud login to authenticate. Which credential type fits this scenario?
Correct answer: A — A personal API token tied to the analyst's own dbt Cloud user account
- A. A personal token inherits the analyst's own permissions and identity, which is appropriate for an individual's ad-hoc, interactive work and keeps API activity attributable to that specific user.
- B. Sharing an Account Admin token across a team for individual notebook work grants far more privilege than ad-hoc querying requires and removes per-user attribution, which is the opposite of what a personal workflow needs.
- C. Job Admin permissions govern triggering and managing jobs, not general query access, and assigning a service credential to one person's personal workflow still mismatches the system-account use case.
- D. Semantic Layer Only limits access to the Semantic Layer API specifically, which does not match a general ad-hoc notebook workflow and is still a system-level credential rather than a personal one.
Sources1
4.Service identities for warehouse credentials in deployment environments
The same question about ownership comes up one layer down, at the warehouse. The development environment is meant to run as people. Each developer who uses the Studio IDE or the dbt platform CLI sets up personal user credentials to the warehouse connection, so queries run as that developer. That is fine for development work, and it keeps each person's target and access separate.
Deployment environments are different. Their warehouse credentials should belong to a dedicated user or service principal. In Databricks terms, a service principal is a headless account that doesn't belong to an actual person. A production pipeline built on someone's personal login breaks when they leave the company, or simply when they change their password. That failure shows up as a missed nightly run, not as an access review.
There is also a governance reason. Production data should change only through scheduled jobs running code that has passed CI tests and code review, not through ad hoc commands. Taking people out of the production identity helps enforce that. If something breaks, every change has an auditable trail back to a reviewed commit, which makes the root cause easier to find and the last working version easier to restore. Name the identity so its purpose is obvious and nobody mistakes it for a person, as in dbt_prod_sp. Which environments people can reach in the first place is covered under [access control to environments](lesson:3.1).
Checkpoint 7 of 7· Check yourself
A team's production deployment environment connects to Databricks with the lead analytics engineer's personal credentials. Which risk is the strongest reason to replace them with a service principal?
A personal identity ties production to one person's employment and password. A service principal removes that dependency and keeps changes to production auditable.
“Personal identities should not be used to build production pipelines because they could break if the user leaves the company or changes their credentials.”Source: docs.getdbt.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Terraform and API scripts are automation, so they should always use a service token.Why is that wrong?
While a script or Terraform configuration is being tested or staged, use a PAT, because that work is scoped to the user making the changes. Switch to a service token when it goes into production.
Covered in Production workflows get a service token; developmental workflows get a PAT
2.The dbt platform CLI can authenticate with a service token, like any other API client.Why is that wrong?
The CLI makes requests in the context of the user running it, so it takes that user's PAT.
Covered in Production workflows get a service token; developmental workflows get a PAT
3.An admin's PAT has enough permissions to create service tokens through the API.Why is that wrong?
Creating a service token with a PAT always fails with a 400 error. Only an existing service token can create new ones.
Covered in Scoping a service token to least privilege
4.A senior engineer's personal warehouse credentials are fine for the production deployment environment.Why is that wrong?
Deployment environments should connect as a dedicated user or service principal, so that production doesn't depend on one person's account.
Covered in Service identities for warehouse credentials in deployment environments
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://docs.getdbt.com/docs/dbt-apis/service-tokensOfficial docs
“You can use service account tokens for system-level integrations that do not run on behalf of any one user.”
↩︎ Account-owned versus user-owned credentials“you will also be able to choose whether to grant those permissions to all projects in the account or to specific projects.”
↩︎ Scoping a service token to least privilege“Account Admin service tokens have full read + write access to an account, so please use them with caution.”
↩︎ Scoping a service token to least privilege“Developer and Starter plans can apply Semantic Layer permissions set to service tokens.”
↩︎ Scoping a service token to least privilege“You can generate service tokens if you have a Developer license and account admin permissions.”
↩︎ Scoping a service token to least privilege“While similar to personal access tokens, service account tokens belong to an account rather than a user.”
↩︎ Checkpoint - 2.https://docs.getdbt.com/docs/dbt-apis/user-tokensOfficial docs
“PATs inherit the permissions of the user that created them.”
↩︎ Account-owned versus user-owned credentials“User API tokens have been deprecated and will no longer work.”
↩︎ Account-owned versus user-owned credentials“Requests to create a service token authenticated with a PAT return a 400 error”
↩︎ Exam trap 3“Requests to create a service token authenticated with a PAT return a 400 error”
↩︎ Checkpoint - 3.https://docs.getdbt.com/docs/dbt-apis/authenticationOfficial docs
“You should use service tokens broadly for any production workflow where you need a service account.”
↩︎ Production workflows get a service token; developmental workflows get a PAT“service tokens give you visibility, and you can scope them to only what the integration needs and ensure the least privilege”
↩︎ Production workflows get a service token; developmental workflows get a PAT“this is a production workflow and is acting as a service account and not a user account”
↩︎ Production workflows get a service token; developmental workflows get a PAT“Service tokens are similar to service accounts and are the preferred method to enable access on behalf of the dbt account.”
↩︎ Key concept“When you push this script or Terraform into production, use a service token instead.”
↩︎ Exam trap 1“Use a PAT since the dbt platform CLI works within the context of a user”
↩︎ Exam trap 2“When you push this script or Terraform into production, use a service token instead.”
↩︎ Prediction“You should use PATs only for developmental workflows or dbt client workflows that require user context.”
↩︎ Checkpoint - 4.
“We recommend that the data warehouse credentials be for a dedicated user or service principal.”
↩︎ Service identities for warehouse credentials in deployment environments“We recommend that the data warehouse credentials be for a dedicated user or service principal.”
↩︎ Exam trap 4 - 5.
“each developer will need to set up personal user credentials to your warehouse connection.”
↩︎ Service identities for warehouse credentials in deployment environments - 6.
“a service principal is a headless account that does not belong to an actual person.”
↩︎ Service identities for warehouse credentials in deployment environments“Only scheduled jobs and running code that has passed CI tests and code reviews should be allowed to modify production data.”
↩︎ Service identities for warehouse credentials in deployment environments“Personal identities should not be used to build production pipelines because they could break if the user leaves the company or changes their credentials.”
↩︎ Checkpoint