Cloud Build shows up on the Professional Cloud Architect exam as Google's fully-managed, serverless CI/CD platform. It runs builds, tests, and deployments without you provisioning any infrastructure, and it integrates with GitHub, GitLab, Bitbucket, and Cloud Source Repositories. For the PCA exam, you don't need to be able to author a complex pipeline from scratch. You need to recognize what a Cloud Build YAML file looks like, understand how substitution variables parameterize a build, and know the four ways a build can be triggered.
Cloud Build is a managed CI/CD service. CI stands for continuous integration, CD for continuous delivery. The point is to automate the lifecycle of your application from source commit through deployment. You define a pipeline, push code, and Cloud Build runs the pipeline on Google-managed workers.
Each build step runs inside a container. That detail matters because it means any tool you can put in a Docker image can run as a step. Google publishes a set of pre-built builder images under gcr.io/cloud-builders/ for common tools like gcloud, docker, npm, and kubectl, but you can point a step at any container you want.
One thing the exam likes to do is mention Jenkins. Cloud Build is not a managed Jenkins. It's not the relationship that Dataflow has to Apache Beam or that Pub/Sub has to Kafka. Jenkins is a separate open-source CI/CD platform that you'd self-host, configure, and maintain yourself. If a question mentions Jenkins, the exam isn't testing Jenkins specifics. It's testing whether you recognize CI/CD concepts and whether Cloud Build is the appropriate managed alternative.
A Cloud Build pipeline is defined in a YAML file, typically named cloudbuild.yaml and committed alongside your application code. The file is a sequence of steps that run in order. Each step has three things you should be able to identify:
gcr.io/cloud-builders/gcloud.Here is a representative pipeline that installs dependencies, runs tests, builds a Docker image, pushes it to Google Container Registry, and deploys to App Engine:
steps:
# Install dependencies
- name: 'gcr.io/cloud-builders/npm'
args: ['install']
# Run tests
- name: 'gcr.io/cloud-builders/npm'
args: ['run', 'test']
# Build Docker image
- name: 'gcr.io/cloud-builders/docker'
args: [
'build',
'-t', 'gcr.io/$PROJECT_ID/my-app:$COMMIT_SHA',
'.']
# Push Docker image to Google Container Registry
- name: 'gcr.io/cloud-builders/docker'
args: [
'push',
'gcr.io/$PROJECT_ID/my-app:$COMMIT_SHA']
# Deploy to App Engine
- name: 'gcr.io/cloud-builders/gcloud'
args: ['app', 'deploy']
Each entry under steps: is one container invocation. The steps run sequentially by default. If exam scenarios describe a build process by referring to its steps, this is the structure they're describing.
Substitution variables let you parameterize the YAML so the same file can target different environments. The most common case is a single pipeline that deploys to a development project on the dev branch and a production project on main. You don't want two separate YAML files. You inject the project ID at runtime instead.
A substitution variable looks like $VAR or ${VAR} in the YAML. Google provides several built-in ones automatically, including:
$PROJECT_ID: the project ID where the build is running.$BRANCH_NAME: the branch that triggered the build.$COMMIT_SHA: the full commit hash, useful for tagging Docker images uniquely.$TAG_NAME: the tag name when a tag-based trigger fires.You can also define your own substitutions, conventionally prefixed with an underscore, for example _SERVICE_NAME or _REGION. Custom substitutions are configured on the trigger and passed into the build at runtime.
Here is the same gcloud step from before, but with the project ID injected as a substitution:
steps:
- name: 'gcr.io/cloud-builders/gcloud'
args: ['app', 'deploy', '--project', '${PROJECT_ID}']
For the Professional Cloud Architect exam, the takeaway is that substitution variables are the mechanism for keeping one pipeline file flexible across environments. If a scenario describes a team that wants the same build to deploy to dev and prod with different settings, the answer involves substitutions, not multiple YAML files.
A trigger is what causes a build to start. There are four types you should recognize on the exam.
A branch-based trigger fires when a commit is pushed to a specified branch. The classic pattern is a trigger on the main branch that runs the deploy pipeline whenever production-ready code is merged in. You can also wire one to a dev branch to deploy to a staging environment on every push.
A tag-based trigger fires when a tag is pushed to the repository. The use case is versioned releases. You tag a commit v1.2.0, push the tag, and the trigger runs the release pipeline. This separates ongoing development pushes from intentional release events.
A pull request trigger fires when a PR is opened, updated, or synchronized against a target branch. The point is pre-merge validation. You run tests and any pre-deploy checks against the proposed merge before anyone actually merges, which catches problems while they're still cheap to fix.
A manual trigger doesn't fire on a repo event. You invoke it on demand, either through the Cloud Console, the gcloud CLI, or the Cloud Build API. Use cases include hotfixes, ad-hoc deploys, and any pipeline you want to keep available but not automate against repo activity.
For the Professional Cloud Architect exam, the Cloud Build picture is small but specific:
name, args, and optional environment variables.$PROJECT_ID and $BRANCH_NAME let one pipeline target multiple environments at runtime.Most PCA scenarios involving Cloud Build are recognition questions. You read a description of a CI/CD requirement and pick the trigger or pipeline structure that fits. Knowing the four trigger types and the role of substitution variables will get you through nearly all of them.
My Professional Cloud Architect course covers Cloud Build alongside the rest of the containers and serverless material.
