CI/CD Architecture with Cloud Build, Cloud Deploy and Artifact Registry

What it is

A CI/CD stack turns a commit into a running release. On Google Cloud the managed pieces are Cloud Build for continuous integration, Artifact Registry for storing what was built, and Cloud Deploy for continuous delivery to GKE and Cloud Run.

Many organizations also keep third-party tools. The exam asks which piece does which job, how they fit together, and how to secure the tooling itself.

How it works

Continuous integration with Cloud Build

Cloud Build runs a series of steps, each a container, defined in cloudbuild.yaml. Triggers start builds from repository events in GitHub, GitLab or Bitbucket, from Pub/Sub messages, webhooks or manual runs.

steps:
- name: gcr.io/cloud-builders/docker
  args: ['build', '-t', '${_IMAGE}:$SHORT_SHA', '.']
- name: gcr.io/cloud-builders/docker
  args: ['push', '${_IMAGE}:$SHORT_SHA']
- name: gcr.io/google.com/cloudsdktool/cloud-sdk
  entrypoint: gcloud
  args: ['deploy', 'releases', 'create', 'rel-$SHORT_SHA',
         '--delivery-pipeline=web-app', '--region=europe-west1',
         '--images=web=${_IMAGE}:$SHORT_SHA']
substitutions:
  _IMAGE: europe-west1-docker.pkg.dev/acme-ci/apps/web
serviceAccount: projects/acme-ci/serviceAccounts/build-sa@acme-ci.iam.gserviceaccount.com
options:
  logging: CLOUD_LOGGING_ONLY

Private pools run builds on workers in a Google-managed network peered to your VPC. Use them when builds must reach private resources, such as an on-premises artifact server over VPN, or must run without public IP addresses.

Continuous delivery with Cloud Deploy

Cloud Deploy models delivery as a delivery pipeline with an ordered list of targets (for example staging, then production). Each build creates a release; deploying it to a target creates a rollout, and promotion moves the same release to the next target.

Cloud Deploy uses Skaffold to render and deploy manifests. Skaffold profiles select per-target config, and Skaffold can render with Kustomize overlays or Helm charts, so one base manifest becomes staging and prod variants.

apiVersion: skaffold/v4beta7
kind: Config
manifests:
  kustomize:
    paths: [k8s/overlays/staging]
profiles:
- name: prod
  manifests:
    kustomize:
      paths: [k8s/overlays/prod]

Artifact Registry configuration

Keep a repository per environment stage or per team, and deploy by digest so the image that was tested is exactly the image that runs.

Hybrid, multi-cloud and third-party tools

Cloud Deploy reaches clusters outside Google Cloud as GKE attached clusters, and a fleet's Connect gateway gives a single control path into registered clusters.

Security of CI/CD tooling

• Run each build with a dedicated, user-specified service account holding only the roles it needs, not a broad default.
• Keep credentials in Secret Manager and read them in the build; never put them in the repository.
• Use private pools and VPC Service Controls where builds handle sensitive projects.
• Restrict who can edit triggers and pipeline definitions, and require approval for builds from untrusted branches or forks.
• Let only the build service account write to the registry, so nothing reaches it except through the pipeline.

A worked example

A team uses Jenkins on VMs and deploys to GKE with kubectl from the build server. The engineer moves CI to Cloud Build triggered on merges to main, pushing images to a regional Artifact Registry repository.

Cloud Build then creates a Cloud Deploy release. The pipeline deploys to staging, and production requires approval, with Skaffold profiles selecting Kustomize overlays per target.

How the exam asks about this

• "Builds must reach a package server in the on-premises data centre over Cloud Interconnect." Use a Cloud Build private pool peered to the VPC.
• "The same release must move from staging to production with a manual sign-off." Use a Cloud Deploy pipeline with requireApproval on the production target.
• "Builds pull base images from Docker Hub and hit rate limits." Create an Artifact Registry remote repository as a cache.