This article covers what Cloud Build is, the basic structure of cloudbuild.yaml, the trigger types you can configure, and how the Associate Cloud Engineer exam tests CI/CD on GCP. The exam coverage of Cloud Build is high level, so this article matches that scope.
It does not cover the deep details of build optimization, custom builder images, or the more advanced features like remote builds and worker pools. Those matter in production but the ACE exam does not test them.
Cloud Build is GCP's managed, serverless CI/CD platform. CI/CD stands for continuous integration and continuous delivery. The idea is that whenever your code changes, an automated pipeline runs your tests, builds your artifact, and (optionally) deploys it. Cloud Build is the service that runs that pipeline for you. There are no servers to manage. You define what should happen, and Cloud Build runs the steps.
It integrates with GitHub, Bitbucket, and Cloud Source Repositories (which is GCP's managed Git service). When code is pushed to a repository, Cloud Build can trigger a build automatically.
Cloud Build pipelines are defined in a file called cloudbuild.yaml. It is a YAML file that lists the steps Cloud Build should run. Each step is a containerized tool plus the arguments to pass to it. Here is a minimal example that builds a Docker image and pushes it to Artifact Registry:
steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-image', '.']
- name: 'gcr.io/cloud-builders/docker'
args: ['push', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-image']Each step runs in a container. The "name" is the container image to use, and "args" is what gets passed to it. Cloud Build provides prebuilt builder images for common tools (docker, gcloud, npm, mvn, gradle, and so on), and you can also use any container image of your own.
For the Associate Cloud Engineer exam, you do not need to memorize the exact YAML syntax. You need to recognize that cloudbuild.yaml is the file where the pipeline is defined, and that each step is a containerized tool.
A trigger is what causes a build to actually run. There are three categories worth knowing.
Manual triggers are the simplest. You run gcloud builds submit or click a button in the console. Useful for one-off builds or testing a pipeline definition.
Source repository triggers fire when something changes in a Git repo. The most common is "build on push to main" or "build on pull request." These work with GitHub, Bitbucket, or Cloud Source Repositories. This is the bread and butter of CI/CD, and it is what most teams set up.
The third category is event-based or scheduled triggers, like Pub/Sub messages or Cloud Scheduler jobs. These are less common and the exam does not lean on them, but you should know they exist.
Cloud Build typically does three things in sequence. Build the artifact (often a Docker image). Push it to a registry (Artifact Registry, ideally, since Container Registry is being retired). Deploy it (to Cloud Run, GKE, App Engine, or Compute Engine).
The deploy step uses gcloud commands inside a Cloud Build step. So you might have a step that runs gcloud run deploy, or gcloud builds submit, or a kubectl command targeting your GKE cluster. The deploy step needs the Cloud Build service account to have the right permissions on the target service, which is its own topic and a common cause of pipeline failures.
The exam coverage of Cloud Build is intentionally light. For the exam, you basically just need to know what Cloud Build is at a general level. The patterns I see on the ACE exam are these.
If the question asks for a managed, serverless CI/CD platform on GCP, the answer is Cloud Build. If the question describes automated builds triggered by code pushes to a Git repository, Cloud Build. If the question shows a cloudbuild.yaml file, that is Cloud Build.
The one specific thing the ACE exam tests beyond the conceptual overview is service account troubleshooting, which is a separate topic. Permission errors in CI/CD pipelines come up directly. If a Cloud Build pipeline fails with a permissions denied error, the fix is to grant the Cloud Build service account the right role on the target resource.
Cloud Build is GCP's managed CI/CD. Pipelines are defined in cloudbuild.yaml as a sequence of containerized steps. Triggers can be manual, repo-based, or event-based. The standard flow is build, push to a registry, deploy to a compute target.
For the Associate Cloud Engineer exam, recognize the service, recognize the YAML file, and know that GitHub, Bitbucket, and Cloud Source Repositories are the supported source repos. The deeper details mostly do not get tested.
My Associate Cloud Engineer course covers Cloud Build alongside Artifact Registry, the deployment flow, and the service account permission troubleshooting that the ACE exam asks about more directly.
