For the Associate Cloud Engineer exam, the one specific detail that gets tested on Cloud Build is service account troubleshooting. This article covers how Cloud Build's service account works, what kinds of permission errors come up, the IAM roles to grant for common deployment targets, and how the ACE exam tests this.
It does not cover the broader CI/CD design questions or the cloudbuild.yaml structure (those are separate articles). The focus here is narrow: when your build pipeline fails because something it tries to do has been denied by IAM, what do you do.
When a Cloud Build pipeline runs, it does not run as you. It runs as a service account. By default, that is the Cloud Build default service account, with a name that looks like PROJECT_NUMBER@cloudbuild.gserviceaccount.com.
Every action that pipeline takes - pushing an image to Artifact Registry, deploying to Cloud Run, applying a kubectl manifest to a GKE cluster, calling any GCP API - goes through that service account. If the service account is not allowed to do something, the action fails.
CI/CD pipelines have a lot of steps. A typical pipeline might check out code, run tests, build a container image, push it to a registry, deploy it to a compute service, run a database migration, and notify a Slack channel. Each of those steps may touch a different GCP service. Each requires the right IAM permission.
Keeping permissions in sync as a pipeline grows is operationally annoying. You add a deploy step. The build runs fine, but the deploy fails because the service account never had the role for the target service. That is the most common kind of failure, and it shows up loudly in the build logs as "permission denied" or "the caller does not have permission" errors.
The diagnosis is consistent. When a Cloud Build pipeline fails, look at the logs. Find the step that failed. Read the error message. If the message says permission denied, missing permission, or the caller does not have permission, it is an IAM problem on the Cloud Build service account, on the resource it tried to act on.
The fix is to grant the right role. Which role depends on what the step was trying to do.
A few patterns come up often enough that they are worth memorizing.
To push an image to Artifact Registry, the Cloud Build service account needs Artifact Registry Writer on the repository. To deploy to Cloud Run, it needs Cloud Run Admin (and IAM Service Account User on the runtime service account that Cloud Run will use). To deploy to GKE, it needs Kubernetes Engine Developer at minimum. To deploy to Compute Engine, it needs Compute Instance Admin or a more granular role for the specific operation. To act as another service account (which Cloud Run and many other services need), it needs IAM Service Account User on that account.
For Cloud Storage operations, Storage Object Admin or a narrower role on the bucket. For BigQuery jobs, BigQuery Job User on the project plus dataset-level access for any tables it touches.
You do not need to memorize every one of these for the Associate Cloud Engineer exam. You need to recognize the pattern: when a build fails on a deploy step, the fix involves granting the Cloud Build service account a role on the target resource.
From the command line, the gcloud command for granting a role on the project to the Cloud Build service account looks like this:
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:PROJECT_NUMBER@cloudbuild.gserviceaccount.com" \
--role="roles/run.admin"You can scope the binding more narrowly to a specific resource (a Cloud Run service, an Artifact Registry repository, a GKE cluster) when you do not want to grant the role at the project level. For high-security environments, narrower scoping is the right call.
The Associate Cloud Engineer exam tests this in a specific pattern. A scenario describes a Cloud Build pipeline that is failing. The error in the build logs mentions permission denied, or the inability to deploy to Cloud Run or GKE or Artifact Registry, or the service account being unable to perform some action. The question asks what to do.
The answer is to grant the Cloud Build service account the appropriate IAM role on the target resource. The wrong answers usually involve granting a role to the user instead of the service account, or granting a role on the wrong resource, or recreating the pipeline.
If you see in the question Cloud Build pipeline failing, permission denied error in build logs, or service account cannot deploy to some service, think Cloud Build service account permission fix. Cloud Build service account permission errors are the one detailed thing the ACE exam tests for Cloud Build, so it is worth recognizing on sight.
Cloud Build pipelines run as a service account. When the pipeline fails with permission denied errors, the fix is to grant that service account the right IAM role on the resource it is trying to act on. Push to Artifact Registry needs Artifact Registry Writer. Deploy to Cloud Run needs Cloud Run Admin and Service Account User. Deploy to GKE needs Kubernetes Engine Developer.
For the Associate Cloud Engineer exam, recognize the diagnosis pattern (permission denied in build logs, fix is on the Cloud Build service account) and you will get these questions right.
My Associate Cloud Engineer course covers Cloud Build service account troubleshooting alongside the IAM section, where the role-binding patterns the ACE exam tests come up across many other services as well.
