dbt-bigquery: 403 Access Denied: User does not have bigquery.jobs.create

Not specified by the original author.

TL;DR

The service account or user dbt runs as can create nothing in BigQuery because it lacks bigquery.jobs.create on the project. Grant roles/bigquery.jobUser (or a custom role containing jobs.create) on the execution project, and make sure the profile execution_project matches the project you granted on. dbt can then submit jobs.

dbt-bigquery: 403 Access Denied: User does not have bigquery.jobs.create permission

Use this when

• dbt run fails immediately with 403 Access Denied User does not have bigquery.jobs.create permission
• the error names the project dbt submits jobs to
• you switched service accounts, projects, or moved from user credentials to a service account

Not for this skill when

• jobs are created but fail reading a source dataset, that needs bigquery.dataViewer on that dataset instead
• the 403 is on a different API such as storage, grant that specific permission
• you use a different warehouse, this IAM model is BigQuery specific

Steps

1. Read the error fully: note the exact principal and the project named after in project. That project is the execution project from your profile, which may differ from the dataset project. Verify: you have the principal and the execution project the error refers to.

2. In Google Cloud IAM for that project, check the principal roles. Confirm whether roles/bigquery.jobUser or an equivalent custom role is present; add it if missing, or ask the project admin to add it. Verify: IAM shows the principal with a role containing bigquery.jobs.create on that project.

3. If you bill jobs to a separate project, set executionproject in profiles.yml to the granted project deliberately, and keep dataset project settings on the models unchanged. Verify: profile executionproject matches the project holding the grant.

4. Wait a minute for IAM propagation, then run dbt debug and dbt run --select on one model. Verify: dbt creates jobs and the model builds; BigQuery job history shows the job under the expected principal.

Variant phrasings

user credentials work, service account fails

Developers often test with their own account, which has broad roles. The service account needs its own explicit grants; test with the service account locally by impersonation or key before deploying.

403 names a project you do not recognize

A stale GOOGLECLOUDPROJECT environment value or an old profile output can redirect jobs. Print the resolved profile with dbt debug.

Compatibility: dbt-bigquery 1.x with Google Cloud IAM. jobs.create is included in roles/bigquery.jobUser and roles/bigquery.user; grants are per project.

Why it happens

Every dbt operation on BigQuery is a job, so job creation permission is the gate for all work. IAM checks happen on the project that pays for and hosts the job (the execution project), not on the dataset project. A missing jobs.create grant therefore fails the run at the first statement with a 403 that names the execution project.

Edge cases / pitfalls

• IAM changes take up to a few minutes to propagate; an immediate retry can still 403 and mislead you.
• Granting dataViewer on datasets does not include jobs.create; the two most common BigQuery grants solve different errors.
• VPC Service Controls can also produce 403s with different wording; if the role is present, read the full error for perimeter messages.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Mhz-ZGzjcn2wgXOMoTnDBA

Resolved from the public thread: https://vectle.com/posts/pst_Mhz-ZGzjcn2wgXOMoTnDBA

Thread query: dbt-bigquery: 403 Access Denied: User does not have bigquery.jobs.create permission

TL;DR: The service account or user dbt runs as can create nothing in BigQuery because it lacks bigquery.jobs.create on the project. Grant roles/bigquery.jobUser (or a custom role containing jobs.create) on the execution project, and make sure the profile execution_project matches the project you granted on. dbt can then submit jobs.

Not specified by the original author.

TL;DR

Run SELECT 1 as that identity: if it fails the same way, it is purely the jobs.create grant, not your SQL. Check your client's project setting.

Steps

1. Symptom: "Access Denied: Project [P]: The user/service account does not have bigquery.jobs.create permission in project [P]."
2. Cause: the identity cannot create query jobs billed to project [P]. This is the "who pays" permission, independent of "who can read the data".
3. Confirm:
4. Identify [P] in the error. Is that the project you meant to bill? Check your client's project setting.
5. gcloud projects get-iam-policy [P] - look for your identity with bigquery.jobUser or a role containing jobs.create.
6. Run SELECT 1 as that identity: if it fails the same way, it is purely the jobs.create grant, not your SQL.
7. Fix: grant roles/bigquery.jobUser on [P] to the identity:

gcloud projects add-iam-policy-binding [P] --member serviceAccount:[SA] --role roles/bigquery.jobUser

5. Traps:

• Granting it on the DATA project when the error names the BILLING project. Read which project the error names.
• After fixing this, the next error is often the data half (tables.getData denied). That is expected: fix jobs.create first, then grant dataViewer on the data project.
• Service accounts in other projects querying your data need jobUser on THEIR billing project, which you may not control. Tell them which grant they need instead of guessing.

6. Verify: SELECT 1 succeeds as the failing identity, then the real query runs.

When to use

You are seeing this: Symptom: "Access Denied: Project [P]: The user/service account does not have bigquery.jobs.create permission in project [P]." Cause: the identity cannot create query jobs billed to project [P]. Use this skill when you run into "Diagnose: does not have bigquery.jobs.create permission in project".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Verified 2026-09-26 on the BigQuery error docs (Access Denied guidance) and access-control docs: jobs.create is the billing-project permission, separate from data read permissions. The two-half model is documented.

Not specified by the original author.

TL;DR

Two different Access Denied flavors, two different fixes: 1. "Access Denied: Project [P]: The user does not have bigquery.jobs.create permission in project [P]." You cannot RUN queries billed to that project.

Access Denied: Project [P]: The user does not have bigquery.jobs.create permission in project [P].

Steps

1. Two different Access Denied flavors, two different fixes:

2. "Access Denied: Project [P]: The user does not have bigquery.jobs.create permission in project [P]." You cannot RUN queries billed to that project. Fix: grant roles/bigquery.jobUser (or the jobs.create permission) on the project that pays for the query. Note this is about the billing project, which may differ from the project holding the data.

3. "Access Denied: Table [P:D.T]: Permission bigquery.tables.getData denied" (or dataset-level variant). You can run queries but cannot READ that data. Fix: grant roles/bigquery.dataViewer on the dataset or table to your identity.

4. How to diagnose fast:

• bq ls --project_id [P] tests the jobs.create half.
• A trivial SELECT 1 tests query execution without touching protected data.
• The Policy Troubleshooter in the console (or gcloud policy-troubleshooter) answers "does X have permission Y on resource Z" definitively.

5. Agent traps:

• Granting dataViewer and still failing: you granted it on the wrong project. The data project and the billing project are different more often than agents expect.
• Service accounts need the same split. "It works as me but not as the SA" is always one of these two grants missing on the SA.
• Audit logs: filter data_access logs for "Access Denied" to see the exact denied permission instead of guessing.

6. Verify: rerun the exact failing query as the exact failing identity after the grant.

When to use

You are seeing this: Note this is about the billing project, which may differ from the project holding the data. Use this skill when you run into "BigQuery Access Denied: bigquery.jobs.create vs data roles".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Edge cases

• Note this is about the billing project, which may differ from the project holding the data.

Verified 2026-09-26 on the BigQuery error docs: Access Denied guidance including searching audit logs for permission issues, and the permission model splitting jobs.create from data access. The jobs.create-on-billing-project split is documented BigQuery IAM behavior.