Overview
This section covers the pipelines themselves. You design CI/CD for application code and infrastructure code, store and version artifacts in Artifact Registry, deploy to GKE, Cloud Run and hybrid or multi-cloud targets, set up triggers and add approval gates. The title also names continuous testing and machine learning workloads, so expect pipelines that run unit, integration and validation tests and that ship models as well as services.
Running pipelines means auditing what was deployed and by whom, choosing canary, blue/green, rolling, traffic splitting or feature flag strategies with clear success metrics, and fixing failed rollouts. Configuration and secrets are handled with Cloud KMS, Secret Manager, Certificate Manager, Parameter Manager and Workload Identity Federation. Pipeline security relies on Artifact Analysis scanning, Binary Authorization, the SLSA framework and IAM separated by environment.
How it's tested
Questions in this section describe a delivery problem, such as slow releases, failed rollouts, leaked credentials or untrusted images, and ask for the change that fixes it with the least risk. Answers that keep secrets out of source, use managed promotion and gate production on verifiable evidence tend to be correct.
-
Choose the release strategy
You match canary, blue/green, rolling, traffic splitting or feature flags to constraints such as instant rollback, limited capacity or testing with real users.
-
Handle the secret
You decide where a credential lives, who can read it and whether it is injected at build time or at runtime.
-
Prove what runs in production
You combine vulnerability scanning, attestations and Binary Authorization policies so that only verified images deploy.
A team on Cloud Run wants to send 5% of traffic to a new revision, watch error rate and latency, then increase gradually. Blue/green would switch everything at once and double resources. A canary rollout in Cloud Deploy with percentage phases, or Cloud Run traffic splitting between revisions, matches the goal, and the success metric comes from Cloud Monitoring data for the canary revision.
Objectives 4
Official objectives from the Google Cloud outline, in outline order.
2.1 Designing pipelinesCI/CD for apps and infrastructure, artifacts, hybrid targets, triggers and approvals.
- What it means
- This covers designing CI/CD for both application code and infrastructure code, managing artifacts in Artifact Registry, deploying to hybrid and multi-cloud environments such as GKE, setting up pipeline triggers and configuring deployment processes such as approval flows.
- What to understand
- A typical design has a Cloud Build trigger on a pull request that runs tests and a Terraform plan, then a trigger on merge that builds an image, pushes it to Artifact Registry and creates a Cloud Deploy release. Cloud Deploy targets can require approval before promotion to production. Infrastructure pipelines should show plans for review before apply. For ML workloads, the same idea applies to training code, model artifacts and validation checks before a model is promoted.
- How it shows up
- Expect to pick the trigger type, approval point or artifact flow that meets a review or compliance requirement.
- Common confusion
- Rebuilding the image for each environment breaks traceability; build once and promote the same digest.
2.2 Implementing and managing pipelinesDeployment auditing, rollout strategies with success metrics, and troubleshooting.
- What it means
- This covers auditing and tracking deployments with Artifact Registry, Cloud Build, Cloud Deploy and Cloud Audit Logs; using deployment strategies such as canary, blue/green, rolling updates, traffic splitting and feature flags, with success metrics drawn from telemetry; and troubleshooting and mitigating deployment issues.
- What to understand
- Canary sends a small share of traffic to the new version and expands if metrics stay healthy. Blue/green runs two full environments and switches traffic at once, giving fast rollback at the cost of double capacity. Rolling updates replace instances gradually with little extra capacity. Feature flags separate deploying code from releasing behavior. Cloud Deploy keeps a release history and can roll back to a previous release. Cloud Audit Logs show who triggered a deployment.
- How it shows up
- A scenario lists constraints on capacity, rollback speed or user exposure, and you choose the matching strategy.
- Common confusion
- Blue/green and canary both limit risk, but only canary exposes a small slice of real users first.
2.3 Managing pipeline configuration and secretsCloud KMS, Secret Manager, Certificate Manager, Parameter Manager and Workload Identity Federation.
- What it means
- This covers managing encryption keys with Cloud KMS, managing configuration and secrets with Secret Manager, Certificate Manager, Parameter Manager and Workload Identity Federation, and choosing between build-time and runtime secret injection.
- What to understand
- Secret Manager stores versioned secrets with IAM per secret and audit logging. Parameter Manager holds non-secret configuration that can reference secrets. Cloud KMS manages keys used for encryption and signing, including customer-managed keys. Certificate Manager handles TLS certificates for load balancers. Workload Identity Federation lets external CI systems such as GitHub Actions authenticate without service account keys. Runtime injection keeps secrets out of images, while build-time injection suits secrets needed only to build.
- How it shows up
- Questions ask where a credential should live and how a build or service reads it without exposing it.
- Common confusion
- Secret Manager stores secrets; Cloud KMS stores keys and does not hold arbitrary secret values.
2.4 Securing the deployment pipelineArtifact Analysis, Binary Authorization, SLSA and environment-based IAM.
- What it means
- This covers scanning artifacts for vulnerabilities with Artifact Analysis, applying software supply chain security with Binary Authorization and the SLSA framework, and setting IAM policies that differ by environment.
- What to understand
- Artifact Analysis scans images in Artifact Registry for known vulnerabilities and records metadata. Cloud Build can generate build provenance aligned with SLSA levels. Binary Authorization checks attestations at deploy time on GKE or Cloud Run and blocks images that lack required signatures. Production IAM should be narrower than staging, with separate service accounts per environment so a staging pipeline cannot deploy to production.
- How it shows up
- Expect a requirement that only scanned, signed images from a trusted build reach production.
- Common confusion
- Scanning reports vulnerabilities but blocks nothing; Binary Authorization performs the enforcement.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Build once, promote
Build one image and promote the same digest through environments.
- Remember
- Reference images by digest, not mutable tag.
- Tested as
- Traceability and release design.
- Trap
- Rebuilding per environment.
-
Cloud Build triggers
Start builds on push, pull request, tag, Pub/Sub or manual events.
- Remember
- Pull request triggers suit test and plan stages.
- Tested as
- Pipeline design questions.
- Trap
- Running apply on every pull request.
-
Cloud Deploy approvals
Targets can require approval before a rollout proceeds.
- Remember
- Approval is set per target.
- Tested as
- Change control scenarios.
- Trap
- Building custom approval scripts.
-
Canary deployment
Shifts a small share of traffic to the new version in phases.
- Remember
- Define metrics that decide whether to advance.
- Tested as
- Risk-limited releases.
- Trap
- Advancing without health criteria.
-
Blue/green deployment
Two full environments with an instant traffic switch.
- Remember
- Fast rollback, double capacity.
- Tested as
- Zero-downtime cutovers.
- Trap
- Choosing it when capacity is tight.
-
Feature flags
Toggle behavior at runtime independent of deployment.
- Remember
- Separate deploy from release.
- Tested as
- Gradual feature exposure.
- Trap
- Confusing it with traffic splitting.
-
Secret Manager
Versioned secret storage with per-secret IAM.
- Remember
- Grant secretAccessor only to the identity that needs it.
- Tested as
- Secret handling questions.
- Trap
- Putting secrets in env files in Git.
-
Workload Identity Federation
External identities exchange tokens for short-lived Google credentials.
- Remember
- Removes the need for service account keys.
- Tested as
- Third-party CI authentication.
- Trap
- Exporting a JSON key to the CI tool.
-
Cloud KMS
Manages cryptographic keys for encryption and signing.
- Remember
- Use it for keys, Secret Manager for secret values.
- Tested as
- Key management and attestation signing.
- Trap
- Storing passwords as KMS keys.
-
Artifact Analysis
Vulnerability scanning and metadata for artifacts.
- Remember
- It detects issues; it does not block deployment.
- Tested as
- Supply chain questions.
- Trap
- Expecting scanning alone to stop bad images.
-
Binary Authorization
Deploy-time policy enforcement based on attestations.
- Remember
- Works with GKE and Cloud Run.
- Tested as
- Only trusted images in production.
- Trap
- Relying on IAM to check image provenance.
-
SLSA
Framework of levels for build integrity and provenance.
- Remember
- Provenance proves how and where an artifact was built.
- Tested as
- Supply chain maturity.
- Trap
- Treating it as a scanner.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Deployment strategies
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Canary | Gradual traffic shift to the new version in phases. | Limits exposure to a small share of real users. | It needs metrics to judge each phase. |
| Blue/green | Two complete environments; switch traffic at once. | Instant rollback by switching back. | It doubles running capacity during the cutover. |
| Rolling update | Replace instances a few at a time. | Low extra capacity needed. | Old and new versions serve traffic together, so they must be compatible. |
| Feature flags | Code paths toggled by configuration at runtime. | Release is decoupled from deployment. | Stale flags add complexity if not removed. |
Where configuration and credentials belong
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Secret Manager | Stores secret values such as passwords and API tokens. | Versioned, IAM per secret, audited access. | Do not bake its values into container images. |
| Parameter Manager | Stores application configuration parameters. | For non-secret settings that may reference secrets. | It is not a substitute for secret storage. |
| Cloud KMS | Creates and manages cryptographic keys. | Encrypts data and signs attestations. | It does not store arbitrary secret strings. |
| Certificate Manager | Provisions and manages TLS certificates. | Handles certificates for load balancers. | Not used for application passwords. |
Supply chain controls
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Artifact Analysis | Scans images and stores vulnerability findings. | Detection and reporting. | It does not prevent deployment on its own. |
| Binary Authorization | Admits only images with required attestations. | Enforcement at deploy time. | Policies must be set per cluster or service. |
| SLSA provenance | Signed record of how an artifact was built. | Evidence of build integrity. | Provenance is evidence, not a policy gate. |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Secrets in the image
- What candidates pick
- Copy the database password into the image at build time.
- Why it looks right
- The service starts without extra configuration.
- Why it's wrong
- Anyone who can pull the image can read the secret, and rotating it means rebuilding; runtime access from Secret Manager avoids both.
Clue to watch for The secret is needed only when the service runs.
-
Key file for GitHub Actions
- What candidates pick
- Create a service account key and store it as a repository secret.
- Why it looks right
- It is the familiar setup in many tutorials.
- Why it's wrong
- Long-lived keys can leak; Workload Identity Federation issues short-lived credentials without key files.
Clue to watch for An external CI provider must call Google Cloud APIs.
-
Scanning equals enforcement
- What candidates pick
- Turn on Artifact Analysis scanning and stop there.
- Why it looks right
- Scanning finds the vulnerabilities.
- Why it's wrong
- Findings do not stop a deployment unless a Binary Authorization policy or pipeline gate acts on them.
Clue to watch for The requirement says images must be blocked.
-
Blue/green for small exposure
- What candidates pick
- Deploy a green environment and switch all traffic.
- Why it looks right
- Rollback is very fast.
- Why it's wrong
- Switching all traffic does not limit how many users see a bad release; a canary does.
Clue to watch for Phrases like 'a small percentage of users first'.
-
Tags as release identity
- What candidates pick
- Promote the image tagged latest to production.
- Why it looks right
- Tags are readable and easy to script.
- Why it's wrong
- Tags are mutable, so the image in production may differ from the tested one; digests are immutable.
Clue to watch for Auditors need proof that tested and deployed artifacts match.
-
One pipeline identity for all environments
- What candidates pick
- Use a single service account with deploy rights everywhere.
- Why it looks right
- Fewer accounts to manage.
- Why it's wrong
- A compromise in staging then reaches production; separate per-environment identities limit the blast radius.
Clue to watch for Mentions of environment-based IAM or least privilege.
Answer framework
Apply this sequence to Section 2 scenarios about building, releasing or securing a pipeline.
- Identify the stage at issue: trigger and test, artifact storage, promotion between environments, secrets, or production admission.
- Assign the stage to its owning service: Cloud Build for build and test, Artifact Registry for storage, Cloud Deploy for promotion and rollback.
- Pick the release strategy from constraints on user exposure, capacity and rollback time, and name the telemetry that decides success.
- Place each credential in Secret Manager, keys in Cloud KMS, and authenticate external tools with Workload Identity Federation rather than keys.
- Gate production with Artifact Analysis results, SLSA provenance and Binary Authorization, using a separate deploy identity for each environment.
Practice question
Want more like this? The GCP PCDOE practice test has questions for every domain.
Checklist
0 of 14
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Build one pipeline end to end before reading more theory. Put a small service in a Git repository, add a Cloud Build trigger that runs tests on pull requests and builds an image on merge, push the image to Artifact Registry, and create a Cloud Deploy pipeline with staging and production targets. Add an approval on production and a canary strategy, then deliberately ship a broken version to practice rollback.
Once that works, add security layers one at a time: move a credential into Secret Manager and read it at runtime, turn on vulnerability scanning, create an attestor with a Cloud KMS key and enforce a Binary Authorization policy. Make a table of deployment strategies with capacity cost, rollback speed and user exposure. For the ML angle, review how a pipeline can run validation checks on a trained model before promotion. Finish with practice questions that mix strategy and security.
FAQ
How much of the GCP PCDOE exam covers Building and implementing CI/CD pipelines?
Google weights Section 2, Building and implementing CI/CD pipelines, including continuous testing, for application, infrastructure, and machine learning workloads, at about 25%. That is roughly 13 to 15 questions on a 50-60 question exam, as an estimate only.
Do I need to know Jenkins or GitHub Actions?
The guide focuses on Cloud Build and Cloud Deploy but also names third-party tools such as Jenkins and Argo CD. Know how external tools authenticate to Google Cloud and where they fit, not their configuration syntax.
How deep does the ML workload coverage go?
The section title names machine learning workloads, but the listed subsections stay at the pipeline level. Expect to treat models and training code as artifacts that are built, tested, validated and promoted.
When is build-time secret injection acceptable?
When a secret is needed only to build, such as a token for a private package repository, and it is not copied into the final image. Secrets the running service needs should be read at runtime.
What is the difference between Cloud Build and Cloud Deploy?
Cloud Build runs steps that test and build artifacts. Cloud Deploy manages releases and rollouts through a sequence of targets with approvals, canary phases and rollback history.
Is Container Registry still tested?
Current guides name Artifact Registry. Container Registry has been replaced, so answers that rely on it are unlikely to be preferred.
Other DevOps & Containers certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 2 knowledge
Practice choosing release strategies, secret handling and supply chain controls in scenario questions like the ones in this section.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the GCP PCDOE AI tutor Get any concept explained your way