Cloud Build Service Account Troubleshooting for the PDE Exam

If you are preparing for the Professional Data Engineer exam, Cloud Build shows up in a specific way. The exam likes to test whether you can diagnose a pipeline that suddenly stops working, and the answer is almost always a service account that is missing a role. This pattern repeats across questions about deploying Dataflow jobs, loading BigQuery tables, pushing images to Artifact Registry, and updating Cloud Functions. I want to walk through how the Cloud Build service account actually works, where permission failures come from, and how to reason about them under exam pressure.

What service account is actually running the build

Every Cloud Build pipeline runs as a service account. By default, that account is the legacy Cloud Build service account, formatted as PROJECT_NUMBER@cloudbuild.gserviceaccount.com. This identity is created the first time the Cloud Build API is enabled in a project. It is not the Compute Engine default service account, and it is not your user account. The build steps inherit this identity, so any gcloud, bq, or gsutil call inside a step runs with whatever roles this account has been granted.

For exam scenarios, you should also know that Cloud Build now supports user-managed service accounts. You can attach a custom service account to a build trigger, which is the recommended pattern when you want least-privilege isolation between pipelines. If a question describes a team that wants tight scoping between a data ingestion pipeline and a model deployment pipeline, the right answer is usually two separate user-managed service accounts, each with only the roles it needs.

Why permission errors happen

A Cloud Build pipeline touches a lot of services. Even a modest data pipeline build might pull source from a repo, run tests, build a container, push it to Artifact Registry, deploy a Dataflow template, and then trigger a BigQuery load. Each of those actions calls a different API, and each API checks the calling identity against IAM. The challenge is that the required permissions for the build identity drift as the pipeline grows. Someone adds a new step that writes to a GCS bucket, and the pipeline starts failing because the Cloud Build account does not have roles/storage.objectAdmin on that bucket.

When this happens, the symptom on the exam will almost always be a permission denied error surfaced in Cloud Logging. The exam expects you to know that the first move is to inspect the build logs, find the denied API call, and trace it back to the service account that ran the step. That is the diagnostic loop. You do not start by rewriting the pipeline. You start by reading the log line that names the missing permission.

Roles you should recognize for the PDE exam

The Professional Data Engineer exam leans on a specific set of roles that show up in Cloud Build scenarios. These are the ones I would memorize the bindings for.

• roles/dataflow.developer: needed when the build submits or updates a Dataflow job. Without it, the pipeline fails on the job-submission step.
• roles/bigquery.dataEditor: needed when the build loads or writes data into BigQuery tables. Read-only roles will not cover insert or load operations.
• roles/bigquery.jobUser: needed to run BigQuery jobs at all, separate from dataset-level write access. A common gotcha is granting dataEditor without jobUser.
• roles/artifactregistry.writer: needed to push container images to Artifact Registry. Without it, the docker push step fails.
• roles/iam.serviceAccountUser: needed when the build impersonates another service account, which is common when deploying Cloud Run services or Dataflow jobs that themselves run as a different identity.
• roles/storage.objectAdmin: needed when staging artifacts or templates to a GCS bucket.

How to diagnose a failing build

The exam-friendly troubleshooting flow is short. First, open the build in Cloud Logging and filter on the failing step. Look for the literal phrase PERMISSION_DENIED or a message like does not have permission. The log entry will name both the principal and the permission, which tells you exactly which role binding to add. A typical entry looks like this.

ERROR: (gcloud.dataflow.jobs.run) PERMISSION_DENIED:
Permission 'dataflow.jobs.create' denied on project 'my-project'
for principal '123456789@cloudbuild.gserviceaccount.com'

From there, granting the missing role is one IAM command.

gcloud projects add-iam-policy-binding my-project \
  --member="serviceAccount:123456789@cloudbuild.gserviceaccount.com" \
  --role="roles/dataflow.developer"

If the exam question shows you a build that worked yesterday and fails today, the most likely cause is that someone added a new step or a new resource without updating the service account bindings. The fix is not to disable IAM or to grant Owner. The fix is to read the log, identify the specific permission, and bind the narrowest role that covers it.

What the exam wants you to choose

When a Cloud Build scenario appears on the Professional Data Engineer exam, the wrong answers usually involve restarting the build, recreating the trigger, or escalating to Project Owner. The right answer is almost always to inspect Cloud Logging for the permission denied error and grant the specific role to the build identity. If the question hints at multi-tenant pipelines or least privilege, the right answer shifts toward attaching a user-managed service account to the trigger and binding only the roles that pipeline needs.

Knowing the diagnostic loop and recognizing the four or five roles above will cover most Cloud Build questions you encounter on the Professional Data Engineer exam.

My Professional Data Engineer course covers Cloud Build service accounts, IAM troubleshooting, and the full set of CI/CD patterns the exam tests, with worked examples for each of the roles above.