Google PCA: DevOps, Delivery Engineering and Infrastructure as Code — Study Guide

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Overview

DevOps, Delivery Engineering, and Infrastructure as Code (IaC) on Google Cloud focus on continuously delivering reliable changes with strong traceability, automation, and safety. Architectures should optimize for short feedback cycles, repeatable deployments, immutable infrastructure, and guardrails that scale with the organization. On Google Cloud this typically combines source control best practices; CI with Cloud Build; artifact management with Artifact Registry; CD with Cloud Deploy; Kubernetes with GKE using manifests, Helm, or Kustomize; GitOps for configuration drift control; and IaC with Terraform or Google Cloud deployment templates. Operational excellence requires progressive delivery (blue-green, canary, traffic splitting, and feature flags), software supply-chain controls (scanning, provenance, signing), testing and deployment gates, and governance that balances speed, safety, auditability, and ownership.

CI/CD, source control, and release orchestration

• CI/CD principles

  • Keep master/main releasable; practice trunk-based development with short-lived feature branches.
  • Automate build, test, scan, and package on every change; require code review with mandatory approvals and status checks.
  • Maintain full traceability from commit → build → artifact digest → environment release; embed commit SHAs and build metadata into images and deployment annotations.
  • Failure modes: long-lived branches, manual handoffs, flaky tests, non-reproducible builds, and missing artifact immutability lead to late surprises and rollbacks.

• Source control, branching, pull requests, code review, and traceability

  • Use protected branches, required reviews, and commit signing. Tag releases and maintain a changelog generated from merge commits.
  • Apply CODEOWNERS and service ownership metadata to enforce domain stewardship.
  • Connect commits to issues and deployments; export CI/CD logs and metadata to Cloud Logging and BigQuery for audit and DORA metrics.

• Cloud Build

  • Triggers: fire on Git events (branch, tag, PR), manual invocations, or Pub/Sub. Parameterize with substitutions for version, environment, and feature flags to keep pipelines DRY.
  • Build steps: run official builders or containers you define; use parallel steps when independent to reduce latency; use caches for language dependencies to speed builds.
  • Artifacts: push images to Artifact Registry with immutable tags and digests; store SBOMs and build logs; publish test reports as build artifacts.
  • Secure build identities: run Cloud Build with a dedicated service account with least privilege and per-repo Workload Identity Federation where possible. For private networks or to avoid egress, use Private Pools. Limit service account keys; prefer short-lived tokens.
  • Example (shortened):
    • cloudbuild.yaml:
      • steps:
        • name: gcr.io/cloud-builders/docker args: [build, -t, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA, .]
        • name: gcr.io/cloud-builders/docker args: [push, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA]
      • substitutions:
        • _ENV=staging

• Cloud Deploy

  • Releases and targets: model a delivery pipeline with promotion across targets (e.g., dev → staging → prod). A release captures an immutable artifact reference and deployment config.
  • Approvals and promotion: require manual or automated approvals with role-based control. Promotion should be a fast, low-risk action because artifact and manifests are unchanged.
  • Canary rollout and rollback: define strategies for progressive exposure, health checks, and automatic rollback on SLO errors. Record every promotion, approver, and verification result for audit.
  • Failure modes: mutable artifacts between environments, manual kubectl in production, or skipped pre-deploy verification cause drift and untraceable outages.

Infrastructure as Code and configuration management

• Terraform

  • Modules: capture reusable patterns (e.g., VPCs, GKE clusters, service accounts, IAM bindings). Version and pin module releases; publish internal module registries.
  • Remote state: store in Cloud Storage with versioning, retention policy, and CMEK; enable locking; restrict access via IAM and uniform bucket-level access; back up state.
  • Plans and policy checks: run terraform fmt/validate/plan in CI; require human review of the plan; enforce policy as code (OPA/Conftest, Sentinel, or Policy Controller) to block violations (e.g., public buckets, wide IAM bindings).
  • Environment promotion: use separate workspaces or separate state/backends per env; promote changes via the same module versions and variables; never hand-edit cloud resources. Sensitive inputs should come from Secret Manager or automation, never hardcoded.
  • Failure modes: leaking secrets into state, concurrent changes without locking, drift from out-of-band edits, and implicit dependencies that break destroy/replace.

• Google Cloud deployment templates and declarative configuration

  • Use declarative tools (Terraform, Google Cloud Deployment Manager, or Kubernetes Configuration as Code) to define desired state rather than scripts of imperative steps.
  • Prefer immutable infrastructure: replace instance templates and roll MIGs; roll out new GKE Deployments rather than patching pods in place. Immutable patterns make rollback and audit simple.
  • Deployment Manager supports Jinja/Python templates for Google Cloud resources but is limited to Google Cloud; Terraform offers broader ecosystem and policy tooling. Select based on organizational standardization and skill sets.

• Kubernetes manifests, Helm, Kustomize, and GitOps

  • Manifests: keep base templates with environment overlays; parameterize only what should vary by environment (e.g., replicas, limits, endpoints).
  • Helm: package, template, and version services with charts; lock dependencies; pin image digests. Failure mode: over-templating obscures intent and complicates review.
  • Kustomize: manage overlays (base + env patches); simpler than Helm when pure Kubernetes is sufficient.
  • GitOps: a controller (e.g., Config Sync, Argo CD, Flux) continuously reconciles clusters to the desired state in Git; every change is a PR with review and an audit trail. Detect and correct drift automatically.

Progressive delivery, supply chain, testing, and verification

• Feature flags and traffic management

  • Feature flags decouple deploy from release; use for gradual exposure, A/B tests, and emergency kill switches. Ensure flag states are versioned and auditable; retire stale flags.
  • Traffic splitting: on Cloud Run use percent-based routing across revisions; on GKE use service mesh or ingress controllers that support weighted routing. For APIs under one hostname/TLS, keep separate backend services per path behind the HTTP(S) Load Balancer; path routing cleanly isolates old/new versions while preserving a single URL and certificate.
  • Blue-green: run two production-ready stacks; switch traffic atomically via load balancer, service selectors, or Cloud Run revision traffic. Enables instant rollback but doubles steady-state cost.
  • Canary and progressive rollout: gradually increase traffic from a small slice while measuring golden signals and business KPIs; automate rollback on regression.

• Software supply-chain controls

  • Image scanning: enable Artifact Analysis vulnerability scanning; fail builds for critical vulnerabilities or known-bad base images; keep a patch cadence.
  • Provenance and signing: generate SLSA-compliant build provenance in Cloud Build; sign artifacts with Cosign; enforce Binary Authorization policies requiring attestations before deployment.
  • Dependency management: pin versions and digests, maintain SBOMs, vendor critical dependencies, and verify checksums. Failure modes include transitive dependency drift and compromised registries.

• Testing pyramid, deployment gates, and post-deployment verification

  • Pyramid: emphasize fast unit tests; add integration and contract tests; run targeted end-to-end tests. Keep test data realistic and de-identified (use Cloud DLP to remove PII).
  • Deployment gates: enforce thresholds for test pass rate, vulnerability status, policy compliance, and code review before promotion; require manual approval for production when risk is elevated.
  • Post-deployment verification: run smoke tests, synthetic checks, and canary analysis using Cloud Monitoring, Error Reporting, and Trace. If KPIs degrade, trigger an automated rollback and open an incident with captured context.
  • Operational diagnostics: deploy the Cloud Logging agent where needed, and instrument services for Trace and Debugger. Keep runbooks for safe remediation (e.g., resizing a persistent disk online and running resize2fs with minimal downtime).

Governance, safety, auditability, and ownership

• Speed with safety

  • Trunk-based development with short-lived PRs and mandatory review maintains flow without sacrificing quality.
  • Self-service pipelines with templates for common stacks (GKE + Helm, Cloud Run, Dataflow) accelerate teams and reduce bespoke risk.

• Access, identity, and approvals

  • Use dedicated service accounts per pipeline stage with least privilege and Workload Identity Federation; avoid static keys.
  • Separate duties: developers build; release managers approve production promotion; runtime operators own runtime configuration and budgets.

• Auditability and compliance

  • Export Cloud Build, Cloud Deploy, and Cloud Audit Logs to BigQuery. Use dataset views and IAM to share scoped audit data with auditors. Retain metrics long term by exporting to Cloud Storage or BigQuery per policy.
  • Record artifact digests in deployment metadata. Maintain end-to-end SBOM and provenance for each release.

• Ownership and SLOs

  • Each service has an owner, on-call rotation, SLOs, and error budgets that gate releases. Tie deployment policies to SLO compliance to avoid pushing changes when the budget is exhausted.

• Common trade-offs and pitfalls

  • Blue-green cost vs. rollback speed; canary confidence vs. time to full release.
  • GitOps consistency vs. operational flexibility; allow controlled break-glass with logging and follow-up PRs.
  • Over-templating reduces readability; keep configuration explicit and minimal.
  • Central policy prevents misconfiguration but must be iteratively rolled out to avoid blocking teams unnecessarily.

Practical Problem Scenario

Company: Borealis Fintech

Challenge: Borealis is launching a new payments API on GKE while maintaining v1 and v2 under the same hostname and TLS. They need end-to-end traceability, progressive delivery with canary and feature flags, strong supply-chain controls, and audited promotions across dev, staging, and prod. They also want GitOps for cluster config and Terraform for platform resources.

Approach:

1. Establish source control and branching

   • Create a mono-repo with service directories and a separate infra repo. Enforce protected main, mandatory PR reviews, CODEOWNERS, and signed commits. Rationale: trunk-based flow with clear ownership and audit-ready history.

2. Build artifacts with Cloud Build and Artifact Registry

   • Define cloudbuild.yaml to build and push images tagged by $COMMIT_SHA and annotated with SBOM and provenance. Use a dedicated Cloud Build service account with least privilege and a Private Pool. Rationale: reproducible, isolated builds with traceable digests.
   • Example:
     • gcloud artifacts repositories create app –repository-format=docker –location=us

3. Implement software supply-chain controls

   • Enable vulnerability scanning in Artifact Registry. Generate provenance and sign images with Cosign in Cloud Build post-build steps. Configure Binary Authorization to require signatures and scanning pass before GKE deploy. Rationale: block untrusted or vulnerable artifacts at enforcement time.

4. Model delivery with Cloud Deploy

   • Define a delivery pipeline with targets dev, staging, prod and a canary strategy for prod. Require manual approval for prod with role-based approvers. Rationale: immutable promotion and auditable approvals.
   • clouddeploy.yaml (excerpt):
     • strategy:
       • canary:
         • canaryDeployment:
           • percentages: [5, 25, 50, 100]

5. Route v1 and v2 APIs under the same hostname

   • Configure an external HTTP(S) Load Balancer with separate backend services for /v1 and /v2 paths, each pointing to the corresponding GKE NEG. Rationale: clean path-based isolation, same certificate and DNS, independent deployability.
   • Example (excerpt):
     • gcloud compute url-maps add-path-matcher api-map –path-matcher-name api-pm –default-service v1-bes –path-rules="/v1/=v1-bes,/v2/=v2-bes"

6. Manage infrastructure with Terraform

   • Create modules for VPC, GKE, Artifact Registry, service accounts, and IAM. Store remote state in a CMEK-protected Cloud Storage bucket with versioning and retention. Enforce OPA policies in CI to prevent risky changes. Rationale: reusable, reviewable, and governed platform provisioning.
   • backend “gcs” { bucket = “borealis-tf-state” prefix = “prod” }

7. Configure Kubernetes with Helm/Kustomize and GitOps

   • Maintain base manifests for the API and overlays per env using Kustomize. Use Config Sync or Argo CD to reconcile clusters to the Git state. Rationale: declarative, auditable, and drift-resistant operations.

8. Progressive delivery with canary and feature flags

   • Use Cloud Deploy canary for prod and a feature-flag SDK (OpenFeature) to gate new logic. Start at 5% of traffic, auto-promote upon healthy SLOs; auto-rollback on degradation, and use the flag as a kill switch. Rationale: reduce blast radius and decouple deploy from release.

9. Quality gates and verification

   • Pipeline stages: unit tests → integration tests against ephemeral env → container scan → policy checks → staging end-to-end tests → prod canary with automated SLO-based verification (Cloud Monitoring, Error Reporting, Trace). Rationale: fast feedback early, strong safety before prod, and objective health checks post-deploy.

10. Operations, logging, and audit

    • Install Cloud Logging/Monitoring agents for supporting VMs and enable GKE workload logs/metrics. Export CI/CD and Audit Logs to BigQuery with scoped views for auditors. Maintain runbooks (including safe rollback and emergency DNS or LB switch procedures). Rationale: observability for rapid remediation and compliance-ready evidence.

This design preserves speed with trunk-based flow and automated pipelines; safety with canary, feature flags, and Binary Authorization; auditability with immutable artifacts, approvals, and centralized logs; and clear ownership via CODEOWNERS and GitOps-controlled environments.

← Operations · All domains · Cost →

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

Browse Google →