GCP DevOps & CI/CD Platform — Review Deck
A visual review companion to the 6-part GCP DevOps & CI/CD Platform course, aligned to Professional Cloud DevOps Engineer exam sections 1-2: organization design, infrastructure as code, Cloud Build CI, Cloud Deploy CD, environment/secret management, and pipeline supply-chain security.
Slides
One pipeline, built deliberately
Opening slide framing the course as designing the system that deploys GCP resources safely and repeatedly, not just operating them.
PCDE sections 1-2, and where this course sits in the track
Shows the two PCDE exam sections this course covers and this course's position as course 2 of 6 in the GCP certification track.
ACE operates a resource; PCDE designs the system
The structural shift from certifying correct resource operation to certifying a safe, repeatable delivery system.
One tooling project, not one pipeline per environment
A dedicated tooling project holds Cloud Build, Artifact Registry, and Cloud Deploy; environment projects hold zero pipeline machinery.
Dev, staging, and prod should never share one policy
Org policy, deploy approval, and budget alerting should all tighten deliberately from dev toward production.
What actually crosses the project boundary: a token, never a key
A short-lived, signed token — never a static credential — is what lets Cloud Deploy act across a project boundary.
A hand-run command leaves no record of why
Infrastructure as Code turns an infrastructure change into a reviewed, versioned, reproducible pull request instead of an unreviewable click.
Local Terraform state is a production incident waiting to happen
A GCS backend with real locking replaces the single point of failure a local .tfstate file represents the moment more than one person runs apply.
Cloud Foundation Toolkit and Fabric FAST: forked, never left unmodified
Google's own staged Terraform blueprints are a starting point to adapt, not a black box dependency.
Terraform for foundations, Config Connector for workload-coupled infra
The two tools solve overlapping problems from different angles and must never manage the same live resource.
Git decides, automation reconciles — no human runs apply
The core GitOps rule: an automated process, never a human at a keyboard, reconciles live state to match whatever Git currently says.
Cloud Build's whole job: source in, tested artifact out
Every build step is a container running a command against one shared workspace — Cloud Build never deploys anything itself.
Built-in substitutions are automatic; user-defined ones need an underscore
Cloud Build fills in $PROJECT_ID and $SHORT_SHA automatically; a custom $_REGION must be declared explicitly.
An unfiltered branch trigger is a budget incident waiting to happen
Six trigger types exist; filtering push triggers to main/release branches is the difference between cheap CI and a surprise bill.
Three repository modes, and scanning stops at the virtual layer
Standard, remote, and virtual repositories serve different roles — and vulnerability scanning does not run inside a virtual repository itself.
Cheap checks first, expensive checks last
Lint, then unit tests, then build, then integration tests, then scan, then push — each gate gets more expensive so cheaper failures surface first.
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.
Four objects: DeliveryPipeline, Target, Release, Rollout
A pipeline declares the environment sequence; a target is one environment; a release is one immutable snapshot; a rollout is one deploy attempt.
Canary limits exposure; blue/green makes the cutover atomic
A failed verification at any canary step routes to the same rollback state — that's the entire point of gradual exposure.
A human gates production; automation gates everything else
requireApproval pauses a rollout for a real person; automation rules define retry-then-rollback as declared policy, not external scripting.
Meridian's full path: merge to production, one continuous record
Every step from a merged commit to a fully promoted production release, queryable end to end with no separate tracking system.
Credentials go in Secret Manager; configuration goes in Parameter Manager
The same split AWS draws between Secrets Manager and Parameter Store, and Parameter Manager can reference a secret inline for its sensitive fields.
An ENV baked into a Dockerfile is still build-time injection
Build-time secrets live in image layers forever, retrievable by anyone who pulls the image — regardless of whether the container ever prints them.
One question resolves almost every config-placement decision
If this value leaked, would that be an inconvenience or an incident? The answer picks the right mechanism every time.
Ephemeral environments need a TTL, or they're not actually ephemeral
A per-PR environment with no automatic teardown becomes a permanent environment with a misleading name.
Rapid, Regular, Stable — and a maintenance exclusion set too late doesn't help
Release channels match upgrade cadence to real risk tolerance; exclusions must be set before a high-risk window, not during one.
A compromised pipeline is every environment it deploys to
The final chapter's framing: what stops the pipeline itself from becoming the attack, not just the mechanism that delivers code safely.
SLSA grades the pipeline's trustworthiness, not any single artifact
Three escalating levels, each closing a progressively more sophisticated threat — from Google's own internal system, generalized industry-wide.
Default-deny, or an unlisted cluster accepts anything
A permissive defaultAdmissionRule silently exempts every cluster without its own explicit strict rule.
Only /home survives a session — everything else is rebuilt fresh
The ephemeral-image, persistent-home split makes every developer's tooling identical, auditable, and reproducible.
Every chapter of this course, in one sequence
A hardened workstation, tested and scanned CI, gated and staged CD, and a dual-attestation enforcement point — no single control is sufficient alone.
Readiness checklist
The minimum signals that a GCP CI/CD platform is actually production-ready, not just technically wired together.