Technical Processes

A developer pushes a commit, and minutes later that change is running in production with no one having typed a deploy command. That is the technical process this section designs, and on Google Cloud it is two services in sequence. Cloud Build^[1] handles continuous integration: it imports source from a repository or Cloud Storage and executes a build config as a series of steps, where each step runs in a Docker container, then pushes the result to Artifact Registry^[2]. Cloud Deploy^[3] handles continuous delivery: it automates delivery of an application to a series of target environments in a defined promotion sequence.

The Professional Cloud Architect is expected to recommend the shape of this pipeline rather than implement it: which stages exist, what each stage validates, and where a human gate belongs. So the vocabulary matters.

CI: the build config

A Cloud Build build is defined by a build config (commonly cloudbuild.yaml) listing the steps to run. Tests are first-class steps, not an afterthought: you can configure a build to fetch dependencies, run unit tests, static analyses, and integration tests, then create artifacts with tools such as docker, gradle, maven, or bazel. A build trigger starts a new build in response to code changes from Cloud Source Repositories, GitHub, or Bitbucket, which is what makes the integration continuous.

CD: pipeline, target, release, rollout

Cloud Deploy has four nouns the exam reuses. A delivery pipeline contains the promotion sequence, the order in which to deploy to the configured targets. A target is one destination environment (a GKE cluster, a Cloud Run service, or a GKE attached cluster). A release is the rendered, deployable artifact, generated from your source, a skaffold.yaml, and references to specific container images; Cloud Deploy uses Skaffold for rendering, deployment, and verification. A rollout associates a release with a target and drives the actual deploy. Promotion means deploying the release to the next target in the sequence, for example from staging to prod.

Cloud Deploy sits downstream of any CI tool that outputs container images, so it pairs naturally with Cloud Build but does not require it. That separation is the answer to a common stem: build and test live in CI, environment-to-environment promotion lives in CD.

How you know it is working: the four DORA keys

A pipeline is only as good as the outcomes it produces, and those are measured by four metrics from DORA research^[4]. Deployment frequency (how often you successfully release to production) and lead time for changes (how long a commit takes to reach production) measure velocity. Change failure rate (the percentage of deployments causing a failure in production) and time to restore service (how long recovery from a production failure takes) measure stability. The four are read as two pairs on purpose: optimizing velocity while ignoring stability just ships breakage faster, so a healthy process moves both pairs in the right direction.

With the pipeline shape settled, the remaining technical processes are the controls that wrap it: what stops a bad change, how the system recovers when something does go wrong, and how teams provision infrastructure without a central bottleneck.

Validation has two gates, before and at deploy

Testing happens twice in the lifecycle, and conflating the two is a common mistake. The first gate is in CI: unit, static-analysis, and integration tests run as Cloud Build steps, and a failing step fails the build so no artifact is produced. The second gate is at deploy time and checks provenance rather than behavior. Binary Authorization^[5] is a deploy-time control that enforces that images being deployed to a supported platform conform to a policy you define; the policy admits only images carrying the required cryptographic attestations and rejects the rest. An attestation records the image's registry path and digest and is digitally signed by a required signer, so it proves a specific image passed a specific step. Binary Authorization is part of software supply-chain security and integrates with Cloud Build (which produces attestations) and Artifact Analysis (which supplies vulnerability data). Roll a new policy out in dry-run mode first: it logs what would be blocked without actually blocking, so you confirm the policy before enforcing it.

Disaster recovery: pick the pattern that meets RTO and RPO

When recovery is the topic, two numbers drive every decision. The recovery time objective (RTO)^[6] is the maximum acceptable time the application can be offline. The recovery point objective (RPO) is the maximum acceptable length of time during which data might be lost. You design backwards from these: settle the RTO and RPO the business needs, then choose the DR pattern that meets them at the lowest cost that qualifies. The patterns scale by readiness. Cold (backup and restore) provisions recovery resources only after a disaster strikes, so it is the cheapest and slowest. Warm keeps a scaled-down standby already running and scales it up on failover, trading some cost for faster recovery. Hot runs a full second deployment serving traffic, the fastest and the most expensive. The relationship is monotonic: the smaller your RTO and RPO, the more your application costs to run. A frequent distinction is high availability versus disaster recovery: HA keeps a service up through a zone failure within a region, while DR restores service after a larger, often regional, disaster; meeting a tight RTO inside one region with multi-zone HA can make a separate cross-region DR pattern unnecessary.

Troubleshooting and root cause analysis

When a deployment does cause an incident, the technical process is to restore service first, then run a blameless retrospective. The Well-Architected Framework's operational excellence pillar names "manage incidents and problems^[7]" as a core principle: reduce incident impact and prevent recurrence through observability, incident response procedures, retrospectives, and preventive measures. Blameless means the analysis identifies the contributing systemic causes without indicting any individual, on the assumption that people acted reasonably on the information they had; the deliverable is a set of action items that reduce the likelihood or impact of recurrence, which is also what lowers the change failure rate and time-to-restore DORA keys over time.

Service catalog and governed provisioning

Provisioning at scale poses a governance problem: let every team run their own gcloud and you lose consistency; route everything through central ops and you create a bottleneck. Service Catalog^[8] resolves it by letting cloud admins curate a list of trusted solutions (Terraform configurations, Deployment Manager templates, or reference links) that internal users discover and deploy themselves. Admins control distribution at different folder and project levels and bake in parameters and organization policies, so a developer self-serves within guardrails the admin already approved. That is the standard answer when a scenario wants fast, repeatable provisioning that still enforces standards.

Section 4.1 questions are usually scenarios that name a process pain and ask which Google Cloud capability fixes it. The trick is matching the symptom to the right lifecycle stage.

"Deploys are slow and error-prone" (CI/CD shape)

When a stem describes manual, inconsistent deploys and asks for an automated path from commit to production, the answer is Cloud Build for build and test plus Cloud Deploy for promotion across environments. Distractors usually offer a single tool for the whole job, or put the test stage in the wrong place. Remember the split: Cloud Build runs your tests and produces artifacts, Cloud Deploy promotes a release through ordered targets. A choice that says "run integration tests in Cloud Deploy" is the trap; Cloud Deploy runs Skaffold verify, your test suite belongs in the CI build steps.

"Only approved or scanned images may run in prod" (validation gate)

If the requirement is that untrusted, untested, or unscanned container images must never reach production, the answer is Binary Authorization with a policy requiring attestations. The tempting wrong answer is an IAM role or a firewall rule, but neither inspects image provenance at deploy time. A second trap is enforcing the new policy immediately; the safe rollout is dry-run mode first to see what would be blocked.

"How fast can we recover, and at what cost" (DR)

When a scenario gives a tolerable-downtime and tolerable-data-loss figure and asks for the recovery design, translate them to RTO and RPO and pick the cheapest pattern that meets both: cold for loose objectives, warm for moderate, hot for the tightest. The classic distractor is choosing hot (or a fully active-active design) when the stated RTO and RPO are loose; that over-provisions and overspends. The other distractor confuses HA with DR: a multi-zone regional setup answers a zone-failure RTO, not a regional-disaster one.

"Teams keep building infrastructure inconsistently" (governed provisioning)

When many teams provision their own resources and the result is drift and policy violations, the answer is Service Catalog publishing approved Terraform or Deployment Manager solutions for self-service. The distractor is a pure central-ops gatekeeper (a bottleneck) or unrestricted project owner access (no guardrails). Service Catalog is the middle path: self-service inside admin-approved bounds.

"Did our process change actually help?" (measurement)

When asked how to evaluate a delivery-process investment, the answer is the four DORA keys, read as velocity (deployment frequency, lead time for changes) and stability (change failure rate, time to restore service). The trap is reporting only the velocity pair, or a vanity metric like commit count, which can mask rising failure rates.