Cloud Deploy Study Notes

Cloud Deploy is a fully managed continuous delivery service that automates releasing application artifacts to target runtimes such as GKE, Cloud Run, and Anthos clusters. You define a delivery pipeline and a progression of targets, typically development, staging, and production, and Cloud Deploy manages releases and rollouts through that progression. It adds approvals, verification, and rollback controls on top of the deployment itself.

Key facts

• A delivery pipeline describes the sequence of targets an artifact progresses through, and each target corresponds to a specific runtime environment such as a GKE cluster or a Cloud Run service.
• A release is a specific version of your artifacts, usually container images plus configuration, created from a build result and then promoted from target to target unchanged.
• A rollout is the act of deploying a release to one target, and Cloud Deploy tracks its phases, logs, and success or failure through the console and API.
• Pipelines can require manual approval before a rollout to a sensitive target such as production, and designated approvers can approve or reject with an audit trail.
• Promotion moves the same tested release to the next target in the sequence rather than rebuilding it, which keeps environments consistent and makes results reproducible.
• Rollback is performed by creating a rollout of a previous successful release to the target, using artifacts already stored, so recovery does not depend on rebuilding code.
• Cloud Deploy uses Skaffold for rendering and deploying manifests to Kubernetes targets, separating the delivery orchestration from the underlying deployment mechanics.
• Post-deployment verification and automated canary strategies are supported for some targets, letting a release be checked and gradually shifted before full rollout.

What the exam expects you to know

• Distinguishing Cloud Deploy's delivery role from Cloud Build's build role in an end-to-end pipeline scenario.
• Explaining pipelines, targets, releases, and rollouts and the order in which they are created and promoted.
• Configuring an approval gate before production so a human decision is recorded before the rollout proceeds.
• Rolling back by redeploying a previous release instead of rebuilding or editing manifests under pressure.
• Promoting the identical release artifact through environments to avoid the trap of rebuilding separately for staging and production.
• Knowing that Cloud Deploy targets include GKE and Cloud Run, so it serves both Kubernetes and serverless delivery questions.

Cloud Deploy vs Cloud Build: when to use which

Use Cloud Build to create the artifact: it compiles, tests, and pushes images when code changes. Use Cloud Deploy to deliver that artifact: it manages the staged path to GKE or Cloud Run with promotions, approvals, verification, and rollback. The criteria are pipeline stage and governance. If a scenario is about building on a commit, Cloud Build fits; if it is about a controlled, auditable release from staging to production with an approval step, Cloud Deploy fits that job. See also the Cloud Build notes.

Useful gcloud commands

gcloud deploy releases create release-001 --delivery-pipeline=my-pipeline --region=us-central1 --images=my-app=gcr.io/my-project/my-app:v1
gcloud deploy releases promote --delivery-pipeline=my-pipeline --release=release-001 --region=us-central1
gcloud deploy rollouts list --delivery-pipeline=my-pipeline --release=release-001 --region=us-central1

Common exam traps

• Rebuilding the image for each environment: Cloud Deploy promotes one release, so a rebuild for production breaks the tested-artifact guarantee the service is built around.
• Thinking Cloud Deploy builds code: it starts from artifacts that already exist, typically produced by Cloud Build and stored in Artifact Registry.
• Treating rollback as an undo button that edits history: rollback creates a new rollout of an earlier release, and the failed rollout remains in the record for auditing.
• Skipping approvals in the pipeline definition and expecting them at deploy time: approval requirements are configured on the pipeline's target progression in advance.

Frequently asked questions

What is the difference between a release and a rollout?

A release is a versioned package of artifacts, such as container images and rendered configuration, that will be delivered through a pipeline. A rollout is the deployment of that release to one specific target, with its own phases, logs, and outcome. One release normally produces several rollouts as it is promoted across targets.

How do approvals work in Cloud Deploy?

You configure a target in the pipeline progression to require approval. When a rollout reaches that target it pauses in a pending state, and users with the approver role can approve or reject it in the console or by API. The decision, approver identity, and timing are recorded, giving production releases an auditable human gate.

How do I roll back a bad production deployment?

Create a new rollout to the production target using the previous release that was known to work. Because releases keep their original artifacts and configuration, Cloud Deploy redeploys that exact version without rebuilding anything. You can do this from the console or gcloud, and the failed rollout stays visible for later investigation.

Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.