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.

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