Google PCD: Continuous Delivery, Configuration and Infrastructure Automation — Study Guide

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Part of the Google Professional Cloud Developer — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

Continuous delivery on Google Cloud integrates build automation, artifact management, deployment orchestration, infrastructure as code, and strong governance to repeatedly deliver changes safely. Robust pipelines pair immutable artifacts and declarative configuration with policy and auditability. This section explains design choices, operational practices, and common failure modes when implementing Cloud Build, Cloud Deploy, Artifact Registry, Terraform, Kubernetes, feature flags, and governance controls end to end.

Build and Deploy Orchestration

Cloud Build

• Triggers: Connect builds to source events (branch pushes, tags, PRs) or schedules. Prefer branch or tag regex to ensure only intended refs fire. Triggers can run as a specific service account to enforce least privilege; do not rely on the default if builds need broad API access.
• Build steps: Each step runs in a container. Use purpose-built builders (docker, gcloud) or custom builders when the default toolchain is insufficient. Separate steps for compile, unit test, integration test, lint, security scans, and artifact packaging so failures are attributable and cached effectively.
• Substitutions: Use built-in vars (PROJECT_ID, SHORT_SHA) and custom substitutions (prefix with $_) for parameterized builds. Keep environment-specific values out of build logic; pass them as substitutions or resolve later during deploy.
• Service accounts: The Cloud Build service account (PROJECT_NUMBER@cloudbuild.gserviceaccount.com) requires explicit roles (for example, Artifact Registry write, Cloud Deploy release admin). Assign minimal roles and scope per project. For private resources, use Private Pools with VPC connectivity.
• Artifacts: Publish immutable images to Artifact Registry and optionally upload non-container artifacts to Cloud Storage via the artifacts section. Tag images with both a semantic version and the commit digest; use image digests in deployments to avoid tag drift.

Example Cloud Build config:

• cloudbuild.yaml: steps:

  • name: gcr.io/cloud-builders/docker args: [“build”,"-t","$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}","."]
  • name: gcr.io/cloud-builders/docker args: [“push”,"$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}"]
  • name: gcr.io/cloud-builders/gcloud args: [“deploy”,“releases”,“create”,“app-${SHORT_SHA}”,"–delivery-pipeline=app-pipeline","–images=app=$REGION-docker.pkg.dev/$PROJECT_ID/app/app@sha256:${COMMIT_SHA}"] substitutions: _REGION: us-central1 serviceAccount: projects/$PROJECT_ID/serviceAccounts/cb-deployer@$PROJECT_ID.iam.gserviceaccount.com

• Trigger example: gcloud builds triggers create cloud-source-repositories –repo=my-repo –branch-pattern=^main$ –build-config=cloudbuild.yaml –service-account=cb-deployer@$PROJECT_ID.iam.gserviceaccount.com

Cloud Deploy

• Delivery pipelines define ordered stages and targets. Targets reference GKE clusters, Cloud Run services, or other supported runtimes. Mark production stages with requireApproval to gate promotion.
• Rollouts map a release to a target; promotion advances a release through targets. Use progressive delivery (canary, blue/green) and hooks for predeploy/postdeploy checks.
• Failure modes: Using mutable tags causes unintended upgrades; always pin digests. Missing IAM for the deployer account blocks rollouts. Unrenderable manifests or environment-specific config drift lead to promotion failures; validate manifests during build.

Example Cloud Deploy definitions:

• delivery-pipeline.yaml: apiVersion: deploy.cloud.google.com/v1 kind: DeliveryPipeline metadata: name: app-pipeline serialPipeline: stages:

  • targetId: dev
  • targetId: prod strategy: standard: verify: true requireApproval: true

• targets.yaml: apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: dev gke: cluster: projects/PROJECT/locations/REGION/clusters/DEV_CLUSTER

  Production target definition

  apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: prod gke: cluster: projects/PROJECT/locations/REGION/clusters/PROD_CLUSTER

• Release and promotion: gcloud deploy releases create app-20260903-1 –delivery-pipeline=app-pipeline –region=us-central1 –images=app=us-central1-docker.pkg.dev/PROJECT/app/app@sha256:IMAGE_DIGEST gcloud deploy releases promote –delivery-pipeline=app-pipeline –release=app-20260903-1 –region=us-central1

Artifacts and Supply Chain Integrity

Artifact Registry

• Repositories: Create separate repositories per team or environment to scope IAM and cleanup. Use regional repos near builders and runtimes to reduce egress and latency. Package formats include Docker images and language packages (Maven, npm, PyPI).
• Retention: Define cleanup policies to remove unreferenced or old tags, keeping a safety window for rollback. Avoid aggressive retention that removes the last known-good version.
• Provenance and SBOM: Enable build provenance so images carry SLSA-compliant attestations. Generate SBOMs during build and store as attestations, improving vulnerability triage.
• Vulnerability scanning: Enable container analysis and break the build or block promotion when high-severity CVEs are detected without available fixes or policy exceptions.
• Trade-offs: Centralizing all artifacts in a single project simplifies governance but can create a blast radius; per-environment or per-application repos reduce risk but add management overhead.

Supply chain enforcement

• Binary Authorization on GKE can require attestations (for example, “built by Cloud Build in project X,” “no critical CVEs”). Integrate with Cloud Deploy gates to stop non-compliant releases.
• Failure modes: Relying on mutable tags, disabled scanning, or unauthenticated pulls can lead to unverified software reaching production. Pin digests and require attestations.

Infrastructure as Code and GitOps

Terraform

• Configuration and modules: Factor reusable modules with clear inputs/outputs and semantic versions. Publish modules in a shared repo or registry; pin versions to avoid surprise changes.
• State: Use the GCS backend for remote state with bucket-level IAM, object versioning, and CMEK. Protect state from human edits and ensure state encryption. Avoid secrets in state by reading from Secret Manager at apply time and using data sources sparingly. terraform { backend “gcs” { bucket = “tf-state-prod” prefix = “networking” } }
• Plans and applies: Run terraform plan with -out and have a human or automated gate review the diff; apply only the previously approved plan. Use -refresh-only or -detailed-exitcode in drift detection jobs.
• Environment separation: Use separate projects, state buckets, and service accounts per environment. Prefer directory-per-environment with variable files over workspaces for complex orgs. Never share state across environments.
• Failure modes: Concurrent applies corrupt state; enforce serialization with CI/CD and locking (GCS uses object preconditions). Manual console changes cause drift; restrict direct mutations, and run periodic plan jobs.

Kubernetes declarative config

• Manifests: Keep Kubernetes objects declarative; avoid kubectl imperatives in production flows. Pin image digests and resource requests/limits.
• Kustomize: Use base + overlays to handle environment-specific patches without forking charts. kustomization.yaml (overlay): resources:
  • ../../base patches:
  • target: kind: Deployment name: api patch: |
    • op: replace path: /spec/replicas value: 3
• Helm: Use values files per environment; document precedence (command-line values override values files, which override chart defaults). Template and render in CI (skaffold render or helm template) so deploy-time configs are immutable.
• GitOps: Store the desired state in Git. Use Cloud Deploy or Config Sync to reconcile clusters to Git. PRs become the change control surface with audit trails and policy checks. Avoid kubectl exec modifications that are not captured in Git.

Release Safety, Configuration, and Governance

Feature flags and runtime config

• Feature flags decouple deploy from release; ship dormant code and enable per cohort, percent, or region. Store flag definitions in a low-latency, HA system (Firestore, Memorystore) and cache with short TTLs. Log evaluations for traceability.
• Gradual rollout: Combine traffic splitting (Cloud Run) or canary subsets (GKE) with flags to minimize blast radius. Use health metrics and SLO-based automated rollback triggers.
• Safe rollback: Prefer fast disables via feature flags. For binary rollback, promote the last known-good release or reapply the prior manifest digest.

Environment variables, precedence, secrets

• Precedence commonly follows: runtime flags > environment variables > config files > code defaults. Document and standardize this across services.
• Inject configuration with ConfigMaps and environment variables; use Secret Manager or Kubernetes Secrets for sensitive values. Rotate regularly and avoid baking secrets into images.
• Secret injection examples:
  • Cloud Run environment variable: gcloud run services update api –update-secrets=DB_PASSWORD=projects/PROJECT/secrets/db_password:latest
  • GKE Secret Manager CSI: apiVersion: v1 kind: Pod metadata: name: app spec: volumes:
    • name: sm csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: gsm-secrets containers:
    • name: app volumeMounts:
      • name: sm mountPath: /secrets

Quality gates in CI/CD

• Unit tests run on every commit; fast feedback is paramount.
• Integration tests run against ephemeral environments or sandboxes with seeded data.
• Security checks: SAST, dependency scanning, container vulnerability scanning, IaC policy checks (Conftest, Policy Controller). Block merges or promotions on critical findings.
• Deployment checks: Cloud Deploy predeploy and postdeploy actions validate readiness, database migrations safety, and smoke tests.

Branching, code review, versioning, traceability

• Prefer trunk-based development with short-lived feature branches and mandatory PR reviews. Enforce required checks and linear history for auditability.
• Versioning: Semantic version tags for releases; image digests and commit SHAs for immutability. Avoid moving tags like latest in production deployments.
• Traceability: Annotate builds and releases with commit, PR, ticket IDs. Emit deployment events to Logging; attach labels to resources for cost and ownership.

Infrastructure drift, policy, audit, change control

• Drift detection: Scheduled terraform plan -detailed-exitcode; alert on non-zero codes. For clusters, Config Sync ensures eventual convergence to Git.
• Policy enforcement: Use Organization Policy for guardrails (for example, restrict external IPs), Policy Controller for KRM constraints, and Binary Authorization for image policy.
• Audit logs: Enable Admin Activity and Data Access logs; route to centralized projects with sinks and retention aligned to compliance. Cloud Asset Inventory feeds change history and access analysis.
• Change control: Manual approvals on production promotions, with justifications captured as annotations. Freeze windows can be encoded as policy checks in CI/CD. Ensure emergency rollback pathways are documented and exercised.

Practical Problem Scenario

Acme Retail needs to deploy a new order-service to GKE across dev and prod with safe canary rollouts, strict policy enforcement, and full release traceability. The team must standardize Terraform-managed infrastructure, declarative Kubernetes config with Kustomize, and an auditable CI/CD using Cloud Build and Cloud Deploy.

Approach:

1. Establish artifact repositories and identities

• Create regional Artifact Registry repositories order-docker-dev and order-docker-prod. Grant the Cloud Build service account in the app project roles/artifactregistry.writer and the GKE runtime nodes roles/artifactregistry.reader for the appropriate repo.
• Rationale: Segregated repos reduce blast radius and simplify lifecycle policies. Explicit IAM avoids overprivileged defaults.

2. Define Terraform for infrastructure with environment separation

• Create terraform/envs/dev and terraform/envs/prod directories. Each config includes a GCS backend with separate state buckets, a GKE cluster module, and IAM bindings for the Cloud Deploy service account. Run terraform init, plan -out=plan.bin, and apply plan.bin in a gated CI job per environment.
• Rationale: Per-environment state and projects prevent accidental cross-env impact; plan files support review and auditable change control.

3. Author declarative Kubernetes base and Kustomize overlays

• Place Kubernetes manifests in k8s/base for Deployment, Service, and HPAs with images pinned by digest. Create k8s/overlays/dev and k8s/overlays/prod with replicas, resource requests, and config patches. Use a Secret Manager CSI class for database credentials.
• Rationale: Single source of truth with overlays eliminates drift and keeps configs DRY while enabling safe environment-specific differences.

4. Implement Cloud Build with distinct test and package steps

• cloudbuild.yaml includes steps: lint and unit tests, integration tests against a disposable dev namespace, container build and push to the environment repo, SBOM and vulnerability scanning, and provenance generation. The trigger runs on PRs to main for tests and on merges for packaging. Builds run as a least-privilege cb-deployer service account.
• Rationale: Early failures are cheap; separating concerns improves observability and enables targeted retries. Least-privilege reduces supply chain risk.

5. Configure Cloud Deploy delivery pipeline with manual prod approval and canary strategy

• Define a DeliveryPipeline with dev and prod targets. The prod stage requires approval and uses a canary strategy (for example, 10 percent then 100 percent). Use predeploy hooks for schema compatibility checks and smoke tests; postdeploy verifies SLOs.
• Rationale: Progressive delivery limits blast radius and introduces automated quality gates, while manual approval enforces human-in-the-loop for prod.

6. Wire GitOps and policy enforcement

• Protect main with required reviews and passing checks. Use Policy Controller constraints to block privileged pods and disallow mutable tags. Enable Binary Authorization to require Cloud Build provenance and “no high CVEs” attestations before admission.
• Rationale: Policy-as-code prevents risky configurations from reaching the cluster and provides consistent enforcement.

7. Manage configuration and feature flags for safe release

• Store non-secret runtime configuration in ConfigMaps; secrets are provided via Secret Manager CSI. Introduce a feature flag order_new_flow read from Firestore with 1 percent initial rollout in prod; flags are cached with short TTL and logged.
• Rationale: Flags decouple release from deploy, enabling instant disable if issues emerge without rolling back the binary.

8. Ensure observability, drift detection, and traceability

• Annotate builds and releases with commit SHA, PR number, and change ticket. Route Cloud Deploy events and GKE audit logs to a central Logging project. Nightly terraform plan jobs alert on drift; Config Sync monitors KRM divergence, reconciling to Git.
• Rationale: Complete provenance and audit trails speed incident response; continuous drift detection maintains infrastructure integrity.

9. Operate rollbacks and change control

• For incidents, first disable order_new_flow via the flag. If needed, promote the previous successful release in Cloud Deploy to dev and prod. All prod promotions require a ticket reference in release annotations and an approval from on-call SRE.
• Rationale: Flags provide instant mitigation; immutable releases enable predictable rollback. Approvals and annotations satisfy operational governance and compliance.

← Identity · All domains · Observability →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Google →