Cloud Deploy is one of those services the Professional Cloud Architect exam loves because it sits squarely in the operations side of architecture. It is Google's managed continuous delivery service, and it pairs naturally with Cloud Build to form a complete CI/CD pipeline. I want to walk through what Cloud Deploy does and how it shows up on the Professional Cloud Architect exam.
Cloud Deploy is managed continuous delivery for GKE, Anthos, and Cloud Run. Those three targets are the ones to remember. If a question on the exam talks about delivering applications to a different runtime, Cloud Deploy is probably not the right answer.
The service handles progressive deployment across multiple environments. The standard sequence is dev, test, staging, and production, and Cloud Deploy moves your application through that sequence in a controlled way. Between each environment you can place approval gates, which let you decide when a deployment is allowed to move from one stage to the next. Approvals can be manual or automatic depending on how much control you want at each step.
Cloud Deploy supports canary and blue-green deployment strategies. So when you reach production you are not limited to a hard cutover. You can shift traffic gradually with canary or stand up a parallel environment with blue-green. Both strategies are first-class capabilities of the service.
Two more capabilities round out the picture. Cloud Deploy watches Artifact Registry for new container images and can automatically promote a new version into the pipeline when one shows up. And it keeps an audit trail of who approved and deployed what, with rollback to previous versions if a deployment turns out to be problematic.
The setup the exam tends to draw looks like this. Cloud Build runs first. It builds the container image, runs tests against it, and pushes the result to Artifact Registry. That is the CI phase.
Cloud Deploy then takes over. It is watching Artifact Registry, so when a new image or version appears it triggers the delivery pipeline. The first stop is the Dev environment, where Cloud Deploy deploys the app to a GKE Dev cluster. Dev usually goes out automatically with no approval needed.
From dev the pipeline reaches an approval gate. Once that gate is cleared the deployment promotes to the Stage environment and lands on the GKE Stage cluster. Another approval gate sits before production. After that final approval, Cloud Deploy promotes the release to the Prod environment and the GKE Prod cluster, and this is the stage where canary, blue-green, and rollback come into play.
The clean separation between Cloud Build and Cloud Deploy is the framing the Professional Cloud Architect exam wants you to recognize. Cloud Build is CI. It is responsible for building images and running tests. Cloud Deploy is CD. It is responsible for delivering those images across environments. Each service owns one half of the pipeline, and they connect through Artifact Registry.
That separation of concerns is worth holding onto for exam questions. If a scenario describes a team that needs progressive promotion through dev, stage, and prod with approval gates and rollback to GKE, Cloud Deploy is the answer. If the scenario is about building images and running tests, that is Cloud Build. And if a scenario describes both ends of the pipeline, the right architecture is Cloud Build feeding Artifact Registry, with Cloud Deploy watching the registry and handling the delivery side.
My Professional Cloud Architect course covers Cloud Deploy alongside the rest of the advanced architecture material you will see on the exam.
