Cloud Build produces; Cloud Deploy promotes — never the reverse
Deploying directly from a Cloud Build step throws away every approval gate and rollback mechanism the next four slides build.
Speaker notes
- Draw the design boundary the exam guide itself draws: CI (Cloud Build) produces a tested, versioned artifact; CD (Cloud Deploy) decides where and how that already-built artifact runs — confusing the two is a real design smell.
- Walk the pipeline: source -> test/scan/build (Cloud Build) -> artifact in Artifact Registry -> release created -> rollout: dev -> rollout: staging -> rollout: prod (approval + canary) — exactly one artifact flows through the whole right-hand side, Cloud Deploy never rebuilds anything.
- Name the concrete risk of skipping this boundary: a Cloud Build step that deploys straight to production bypasses Cloud Deploy's promotion model entirely, meaning every approval gate and every rollback mechanism this chapter is about to build simply doesn't exist for that deploy path.
Deck map
01
One pipeline, built deliberately
02
PCDE sections 1-2, and where this course sits in the track
03
ACE operates a resource; PCDE designs the system
04
One tooling project, not one pipeline per environment
05
Dev, staging, and prod should never share one policy
06
What actually crosses the project boundary: a token, never a key
07
A hand-run command leaves no record of why
08
Local Terraform state is a production incident waiting to happen
09
Cloud Foundation Toolkit and Fabric FAST: forked, never left unmodified
10
Terraform for foundations, Config Connector for workload-coupled infra
11
Git decides, automation reconciles — no human runs apply
12
Cloud Build's whole job: source in, tested artifact out
13
Built-in substitutions are automatic; user-defined ones need an underscore
14
An unfiltered branch trigger is a budget incident waiting to happen
15
Three repository modes, and scanning stops at the virtual layer
16
Cheap checks first, expensive checks last
17
Cloud Build produces; Cloud Deploy promotes — never the reverse
18
Four objects: DeliveryPipeline, Target, Release, Rollout
19
Canary limits exposure; blue/green makes the cutover atomic
20
A human gates production; automation gates everything else
21
Meridian's full path: merge to production, one continuous record
22
Credentials go in Secret Manager; configuration goes in Parameter Manager
23
An ENV baked into a Dockerfile is still build-time injection
24
One question resolves almost every config-placement decision
25
Ephemeral environments need a TTL, or they're not actually ephemeral
26
Rapid, Regular, Stable — and a maintenance exclusion set too late doesn't help
27
A compromised pipeline is every environment it deploys to
28
SLSA grades the pipeline's trustworthiness, not any single artifact
29
Default-deny, or an unlisted cluster accepts anything
30
Only /home survives a session — everything else is rebuilt fresh
31
Every chapter of this course, in one sequence
32
Readiness checklist