This chapter covers Google Cloud Deploy for continuous delivery (CD), a managed service that automates the release of applications to Google Kubernetes Engine (GKE), Cloud Run, and Anthos clusters. For the ACE exam, Cloud Deploy appears in Domain Deploy Implement, Objective 3.2, and typically accounts for 5-8% of questions. You must understand its core concepts, pipeline structure, promotion mechanisms, and rollback strategies to answer scenario-based questions correctly.
Jump to a section
Imagine a car factory where each car model goes through a series of stations: design, parts assembly, painting, quality check, and shipping. The factory has a conveyor belt that moves cars from one station to the next. Each station represents a stage in a software delivery pipeline: build, test, stage, and production. Cloud Deploy is the conveyor belt controller. It knows the exact sequence of stations, the rules for moving a car forward (e.g., only if quality check passes), and can pause a car for manual inspection (approval gate). The belt can also run multiple cars of different models simultaneously on different lines (parallel pipelines). When a car reaches the shipping station, it's automatically delivered to the dealer (production target). If a defect is found after shipping, the controller can roll back the car by reversing the belt to the previous station (rollback to previous target). The factory manager (Cloud Deploy) can see the status of every car on every line in real time and has a log of every move. This mirrors how Cloud Deploy manages releases: it orchestrates the progression of a release through a series of targets (e.g., dev, staging, prod) with automated or manual promotion, rollbacks, and parallel execution, all while providing a unified view of pipeline state.
What is Google Cloud Deploy?
Google Cloud Deploy is a fully managed continuous delivery service that automates the deployment of applications to GKE, Cloud Run, and Anthos clusters. It defines a delivery pipeline as a series of targets (e.g., dev, staging, prod) and manages the promotion of releases through these targets with optional approval gates. Cloud Deploy integrates with Skaffold for building and deploying artifacts, and it supports rollbacks, multi-target deployments, and parallel execution.
Why Cloud Deploy Exists
Before Cloud Deploy, teams had to build their own CD pipelines using tools like Jenkins, Spinnaker, or custom scripts. These required managing infrastructure, scaling, and security. Cloud Deploy provides a serverless, Google-managed alternative that reduces operational overhead. It enforces deployment best practices (e.g., sequential promotion, approval gates) and provides a single pane of glass for all releases.
Core Concepts and Components
Delivery Pipeline: A YAML-defined sequence of stages (targets). Each pipeline has a unique name and is associated with a project and region.
Target: A deployment destination, such as a GKE cluster, Cloud Run service, or Anthos cluster. Targets are defined separately from the pipeline and can be reused across pipelines.
Release: A specific version of the application artifact (e.g., container image) along with a Skaffold configuration. Releases are created by associating a pipeline with a source (e.g., container image tag).
Rollout: The process of deploying a release to a target. Rollouts are created automatically when a release is promoted to a target.
Promotion: The action of moving a release from one target to the next in the pipeline. Promotion can be automatic or manual (requiring approval).
Approval Gate: A manual approval step that must be completed before a release can proceed to the next target.
Skaffold: An open-source tool for building and deploying applications. Cloud Deploy uses Skaffold to render manifests and deploy to targets.
How Cloud Deploy Works Internally
Define Pipeline and Targets: The user creates a pipeline YAML file that lists targets in order. Each target references a GKE cluster or Cloud Run service. Example:
apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
name: my-pipeline
serialPipeline:
stages:
- targetId: dev
- targetId: staging
- targetId: prodTargets are defined separately:
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name: dev
description: development cluster
requireApproval: false
gke:
cluster: projects/my-project/locations/us-central1/clusters/dev-clusterCreate a Release: A release is created by specifying the pipeline and the source artifact. The source can be a container image tag or a commit in Cloud Source Repositories. Cloud Deploy triggers Skaffold to render Kubernetes manifests (e.g., using kustomize or helm) and stores them in Cloud Storage.
Promote to First Target: The release is automatically promoted to the first target (e.g., dev) unless manual promotion is configured. A rollout is created, which deploys the application to the target cluster. Cloud Deploy monitors the rollout status (e.g., pending, in-progress, succeeded, failed).
Promotion to Next Targets: Once the rollout succeeds, the release can be promoted to the next target. Promotion can be manual (via Cloud Console, gcloud, or API) or automatic if configured. An approval gate can pause the pipeline before a target.
Rollback: If a rollout fails, Cloud Deploy can automatically roll back to the previous successful release. Manual rollback is also supported. Rollback creates a new rollout that deploys the previous release.
Key Parameters, Values, and Defaults
Pipeline Region: Must be specified when creating the pipeline. Supported regions include us-central1, europe-west1, asia-east1, etc.
Target Region: Targets can be in different regions than the pipeline.
RequireApproval: Boolean flag on a target. Default is false. If true, an approval is required before a rollout can proceed to that target.
Rollout Strategy: For GKE, Cloud Deploy uses a blue/green or canary strategy defined in the Skaffold configuration. Default is blue/green.
Rollback on Failure: Default is true. If a rollout fails, Cloud Deploy automatically rolls back to the previous release.
Release Retention: Releases are retained for 365 days by default. This is configurable.
Maximum Parallel Rollouts: For a single pipeline, only one rollout per target is allowed at a time. However, multiple pipelines can run in parallel.
Configuration and Verification Commands
Create a pipeline:
gcloud deploy apply --file pipeline.yaml --region=us-central1 --project=my-projectCreate a target:
gcloud deploy apply --file target.yaml --region=us-central1 --project=my-projectCreate a release:
gcloud deploy releases create my-release --delivery-pipeline=my-pipeline --region=us-central1 --images=my-image=us.gcr.io/my-project/my-image:v1Promote a release:
gcloud deploy releases promote --release=my-release --delivery-pipeline=my-pipeline --region=us-central1Approve a rollout:
gcloud deploy rollouts approve my-rollout --release=my-release --delivery-pipeline=my-pipeline --region=us-central1List releases:
gcloud deploy releases list --delivery-pipeline=my-pipeline --region=us-central1Rollback:
gcloud deploy rollouts rollback my-rollout --release=my-release --delivery-pipeline=my-pipeline --region=us-central1Interaction with Related Technologies
GKE: Cloud Deploy deploys to GKE clusters using Skaffold. It supports any GKE cluster (standard or Autopilot).
Cloud Run: Cloud Deploy can deploy to Cloud Run services. Targets are defined with a run field specifying the service name.
Anthos Clusters: Cloud Deploy supports Anthos clusters on Google Cloud, AWS, and on-premises.
Cloud Build: Often used to build container images, which are then referenced in Cloud Deploy releases.
Cloud Source Repositories: Can be used as the source of application code for Skaffold.
Cloud Monitoring: Cloud Deploy emits metrics (e.g., rollout success/failure) that can be monitored.
Pipeline Execution Flow
When a release is created, the following happens:
Cloud Deploy triggers Skaffold to render manifests (e.g., expand templates, apply kustomize patches).
The rendered manifests are stored in Cloud Storage.
The release is automatically promoted to the first target (if auto-promotion is enabled).
A rollout is created for that target. Skaffold applies the manifests to the target cluster using kubectl or a direct API call.
Cloud Deploy monitors the rollout status by checking the deployment's progress (e.g., number of pods ready).
Once the rollout succeeds, the release is ready for promotion to the next target.
If approval is required, the pipeline pauses until an approver approves the rollout.
After approval, the release is promoted to the next target, and a new rollout is created.
Steps 4-8 repeat for each target in the pipeline.
If a rollout fails, Cloud Deploy rolls back to the previous successful release automatically (if configured) or allows manual rollback.
Rollout Strategies (via Skaffold)
Cloud Deploy itself does not define rollout strategies; it relies on Skaffold's deployment configuration. Common strategies include:
Blue/Green: Two versions (blue=current, green=new) run simultaneously. Traffic is switched from blue to green after green passes health checks.
Canary: A small percentage of traffic is shifted to the new version, gradually increasing until 100%.
Rolling Update: Pods are replaced incrementally.
For GKE, Skaffold can use kubectl apply or custom deployers. For Cloud Run, Skaffold uses gcloud run deploy.
Security and IAM
Cloud Deploy uses service accounts for deployment. The Cloud Deploy service account (or a user-managed service account) needs permissions to deploy to targets (e.g., GKE cluster admin). IAM roles include:
roles/clouddeploy.admin - full control
roles/clouddeploy.developer - create releases and rollouts
roles/clouddeploy.approver - approve rollouts
roles/clouddeploy.viewer - read-only
Monitoring and Logging
Cloud Deploy integrates with Cloud Logging and Cloud Monitoring. Each rollout generates logs. You can set up alerts for rollout failures or approval requests. The Cloud Console provides a dashboard showing pipeline status, recent releases, and rollouts.
Limitations and Quotas
Maximum of 100 pipelines per project.
Maximum of 100 targets per project.
Maximum of 1000 releases per pipeline.
Rollout timeout: 30 minutes by default (configurable).
Pipeline and target names must be unique within a project.
Exam-Relevant Details
Cloud Deploy is a managed service; no infrastructure to manage.
It supports GKE, Cloud Run, and Anthos clusters.
Pipelines are defined in YAML and applied via gcloud or API.
Promotion can be automatic or manual.
Approval gates are per-target.
Rollbacks can be automatic or manual.
Cloud Deploy uses Skaffold under the hood.
Releases are immutable; you cannot modify a release once created.
Common Exam Scenarios
Given a scenario with multiple GKE clusters (dev, staging, prod), design a pipeline that promotes releases sequentially with an approval gate before prod.
Troubleshoot a rollout failure: check logs, verify service account permissions, check Skaffold configuration.
Differentiate between Cloud Deploy and Cloud Build: Cloud Build is for CI, Cloud Deploy is for CD.
Understand that Cloud Deploy does not build images; it deploys pre-built images.
Define Delivery Pipeline and Targets
Create a YAML file for the delivery pipeline, specifying the serial stages (targets) in order. Each target references a GKE cluster, Cloud Run service, or Anthos cluster. Targets are defined separately in their own YAML files. Use `gcloud deploy apply` to create both the pipeline and targets. The pipeline must be in a supported region. Targets can be in different regions. The `requireApproval` flag on a target determines if manual approval is needed before promoting to that target.
Create a Release
A release is created by associating a pipeline with a source artifact (e.g., container image tag). Use `gcloud deploy releases create` with the `--images` flag to specify the image. Cloud Deploy triggers Skaffold to render Kubernetes manifests and stores them in Cloud Storage. The release is immutable and includes the rendered manifests. Multiple releases can point to the same image version.
Promote Release to First Target
After creation, the release is automatically promoted to the first target (e.g., dev) if auto-promotion is enabled. A rollout is created for that target. Cloud Deploy uses Skaffold to apply the manifests to the target cluster. The rollout status is monitored (pending, in-progress, succeeded, failed). If the target requires approval, the rollout is created but paused pending approval.
Approve or Automatically Promote
If the target has `requireApproval: true`, an approver must use `gcloud deploy rollouts approve` or the Cloud Console to approve the rollout. Once approved, the rollout proceeds. If auto-promotion is enabled (default), the release automatically moves to the next target after the current rollout succeeds. Manual promotion can be done via `gcloud deploy releases promote`.
Rollback on Failure
If a rollout fails (e.g., pods not ready, health check failure), Cloud Deploy can automatically roll back to the previous successful release. The rollback creates a new rollout that deploys the previous release. Manual rollback is also possible using `gcloud deploy rollouts rollback`. The rollback operation is logged and can be monitored.
Enterprise Scenario 1: Multi-Environment Deployment with Approval Gates
A financial services company uses GKE clusters for dev, staging, and prod in separate projects. They need to ensure that only approved releases reach production. They create a single delivery pipeline with three targets: dev, staging, prod. The dev target has requireApproval: false, staging has requireApproval: false, and prod has requireApproval: true. Developers create releases that automatically deploy to dev. After testing, they manually promote to staging. Once staging passes QA, a release manager approves the rollout to prod. This setup prevents unauthorized deployments to production and provides an audit trail. The company uses Cloud Deploy's integration with Cloud Logging to track who approved each rollout.
Enterprise Scenario 2: Blue/Green Deployment to Cloud Run
An e-commerce platform uses Cloud Run for its microservices. They want to reduce downtime during deployments. They configure a Cloud Deploy pipeline with a single target (prod) that uses a Skaffold configuration for blue/green deployment. When a new release is created and promoted to prod, Cloud Deploy deploys the new version (green) alongside the current version (blue). Traffic is switched to green only after health checks pass. If the rollout fails, Cloud Deploy automatically rolls back to blue. This ensures zero-downtime deployments. The team monitors rollout success rates using Cloud Monitoring dashboards.
Common Misconfigurations and Pitfalls
Insufficient IAM permissions: The Cloud Deploy service account must have permissions to deploy to the target cluster. Missing roles like container.deployer cause rollout failures.
Incorrect target cluster URL: The cluster field in the target YAML must be the full resource name (e.g., projects/my-project/locations/us-central1/clusters/my-cluster).
Skaffold version mismatch: Cloud Deploy uses a specific version of Skaffold. If the Skaffold configuration uses features not supported, the render step fails.
Pipeline region mismatch: The pipeline and targets must be in the same region as the Cloud Deploy API endpoint used. Cross-region pipelines are supported but require proper configuration.
Rollback confusion: Automatic rollback only happens if the rollout fails. If a rollout succeeds but the application has a bug, manual rollback is needed.
Scale and Performance Considerations
Cloud Deploy handles thousands of releases per pipeline. However, concurrent rollouts are limited to one per target. For high-frequency deployments, consider multiple pipelines.
Rollout time depends on the target scale. For large GKE clusters with many pods, rollout can take several minutes.
Cloud Deploy stores rendered manifests in Cloud Storage. For large manifests, ensure adequate storage and network bandwidth.
What ACE Tests on Cloud Deploy (Objective 3.2)
The ACE exam tests your ability to:
Design a delivery pipeline for a given set of environments (targets).
Configure approval gates and promotion strategies.
Troubleshoot rollout failures.
Differentiate Cloud Deploy from Cloud Build and other CI/CD tools.
Understand the role of Skaffold.
Common Wrong Answers and Why Candidates Choose Them
1. Wrong: "Cloud Deploy builds container images." Why chosen: Candidates confuse CI (Cloud Build) with CD (Cloud Deploy). Cloud Deploy deploys pre-built images; it does not build them.
2. Wrong: "Cloud Deploy only supports GKE." Why chosen: GKE is the most common target, but Cloud Deploy also supports Cloud Run and Anthos clusters. The exam may ask for supported targets.
3. Wrong: "Rollback automatically reverts to the previous rollout." Why chosen: This is partially true, but the exam tests that automatic rollback only happens on rollout failure. If a rollout succeeds but the app is buggy, you must manually roll back.
4. Wrong: "Approval gates are configured on the pipeline."
Why chosen: Candidates think approval is a pipeline-level setting, but it's per-target. Each target has a requireApproval flag.
Key Numbers and Terms to Memorize
Pipeline region: Must be specified; common regions: us-central1, europe-west1.
Maximum pipelines per project: 100.
Maximum targets per project: 100.
Release retention: 365 days default.
Rollout timeout: 30 minutes default.
IAM roles: clouddeploy.admin, clouddeploy.developer, clouddeploy.approver, clouddeploy.viewer.
Skaffold: Used for rendering manifests and deploying.
Edge Cases and Exceptions
Cross-project targets: Targets can be in different projects than the pipeline. The service account must have cross-project permissions.
Multiple pipelines per project: Allowed up to 100. Each pipeline can have different targets.
Manual promotion without approval: If a target does not require approval, you can still manually promote using gcloud deploy releases promote.
Rollback to a specific release: You can roll back to any previous release, not just the immediate predecessor, by specifying the release name.
How to Eliminate Wrong Answers
If the question mentions building images, eliminate Cloud Deploy (use Cloud Build).
If the question mentions a single environment with no promotion, Cloud Deploy may be overkill; consider simpler tools.
If the question requires a pipeline with manual approval before production, look for requireApproval: true on the prod target.
If the question asks about monitoring rollout status, think Cloud Deploy console or gcloud deploy rollouts list.
Cloud Deploy is a managed CD service for GKE, Cloud Run, and Anthos clusters.
Pipelines are YAML-defined sequences of targets with optional approval gates.
Releases are immutable and include rendered manifests via Skaffold.
Promotion can be automatic or manual; approval gates are per-target.
Rollback can be automatic on failure or manual at any time.
Cloud Deploy does not build images; use Cloud Build for CI.
Maximum 100 pipelines and 100 targets per project.
IAM roles: admin, developer, approver, viewer.
These come up on the exam all the time. Here's how to tell them apart.
Cloud Deploy
Purpose: Continuous delivery (CD) - automates deployment of pre-built artifacts.
Pipelines: Defined as a series of targets (environments).
Promotion: Manual or automatic with approval gates.
Rollback: Supports automatic and manual rollback.
Targets: GKE, Cloud Run, Anthos clusters.
Cloud Build
Purpose: Continuous integration (CI) - builds and tests code.
Pipelines: Defined as a series of steps (build, test, push).
Trigger: Typically triggered by source code commits.
Rollback: Not applicable; focuses on building artifacts.
Output: Container images or other build artifacts.
Mistake
Cloud Deploy builds container images from source code.
Correct
Cloud Deploy does not build images. It deploys pre-built images referenced in the release. Image building is done by Cloud Build or another CI tool.
Mistake
Cloud Deploy only works with GKE clusters.
Correct
Cloud Deploy supports GKE, Cloud Run, and Anthos clusters (including on-premises and AWS). The target type is specified in the target YAML.
Mistake
Approval gates are set on the pipeline, not on individual targets.
Correct
Approval gates are configured per-target using the `requireApproval` field. Each target can independently require approval.
Mistake
Automatic rollback always happens when a deployment fails.
Correct
Automatic rollback only occurs if the rollout fails (e.g., pods not ready). If the rollout succeeds but the application has a bug, you must manually roll back.
Mistake
Cloud Deploy can deploy to any Kubernetes cluster, including on-premises.
Correct
Cloud Deploy supports only Anthos clusters for on-premises deployments. It does not support generic Kubernetes clusters outside Google Cloud or Anthos.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Cloud Build is a CI service that builds and tests code, producing artifacts like container images. Cloud Deploy is a CD service that takes pre-built artifacts and deploys them to environments (GKE, Cloud Run, Anthos) through a defined pipeline with promotion and rollback. They complement each other: Cloud Build builds, Cloud Deploy deploys.
Yes, but not within the same pipeline stage. You can create multiple targets in parallel by defining separate pipelines or by using a fan-out pattern with multiple targets at the same stage (though Cloud Deploy serial stages are sequential). For parallel deployments to multiple clusters, you would typically create separate pipelines or use a custom solution.
In the target YAML for the production target, set `requireApproval: true`. When a release is promoted to that target, a rollout is created but remains pending until an approver uses `gcloud deploy rollouts approve` or the Cloud Console to approve it. Only then does the deployment proceed.
By default, Cloud Deploy automatically rolls back to the previous successful release. The rollback creates a new rollout that deploys the previous release. You can also manually roll back using `gcloud deploy rollouts rollback`. The failure is logged, and you can view details in the Cloud Console.
Yes. Cloud Deploy supports Cloud Run as a target. In the target YAML, use the `run` field instead of `gke` to specify the Cloud Run service name. Skaffold handles the deployment using `gcloud run deploy`. All Cloud Deploy features (promotion, approval, rollback) work with Cloud Run.
Skaffold is an open-source tool that Cloud Deploy uses under the hood to render Kubernetes manifests (e.g., expand templates, apply kustomize patches) and deploy them to targets. When you create a release, Cloud Deploy triggers Skaffold to render the manifests and store them. During a rollout, Skaffold applies the manifests to the target.
Use the command: `gcloud deploy rollouts list --release=RELEASE_NAME --delivery-pipeline=PIPELINE_NAME --region=REGION`. This lists all rollouts associated with that release, showing their status and target.
You've just covered Google Cloud Deploy for CD — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?