CI/CD, DevOps, IaC, and Software Supply Chain

Google Cloud PCA — Section 10

CI/CD, DevOps, IaC, and Software Supply Chain

Goal: recognize how an organization should build, store, scan, promote, deploy, and govern software on Google Cloud. For PCA, the question is usually not asking for command syntax. It is asking which managed service, process, or control best fits the organization’s release, security, automation, and governance requirements.

PCA lens: think in terms of a release chain: source control -> build/test -> artifact storage -> vulnerability metadata -> attestation/signing -> promotion -> deployment gate -> runtime. The exam often tests where in that chain a control belongs.

Fast Decision Matrix

Service Deep Dives

Cloud Build

Why an org uses it: Cloud Build gives organizations a managed way to compile code, run tests, build containers/packages, and produce deployable artifacts without operating Jenkins or custom build servers. It can pull source from common repositories, run build steps in containers, and push outputs to Artifact Registry or other destinations.

PCA trigger: Pick Cloud Build when the scenario says managed CI, automated builds, build triggers, build/test/package, container image creation, private worker pools, or generating provenance/attestations as part of a secure build pipeline.

Common trap: Cloud Build is not the same as Cloud Deploy. Cloud Build builds and tests artifacts. Cloud Deploy manages promotion and release progression across environments.

Cloud Build private pools

Why an org uses it: Private pools give an organization dedicated build workers with more control over networking, machine type, location, and access to private resources. This matters when builds must reach private dependencies, private GKE clusters, on-prem systems, or restricted VPC resources.

PCA trigger: Pick private pools when the requirement says builds need private network access, custom build environment control, higher isolation, dedicated workers, or compliance-driven network boundaries.

Common trap: Do not pick private pools for every build. Default pools are simpler when public internet access and standard hosted workers meet the requirement.

Artifact Registry

Why an org uses it: Artifact Registry is where organizations store and manage deployable artifacts such as container images and language packages. It centralizes package storage, IAM access, regional repository placement, and integration with build/deploy pipelines.

PCA trigger: Pick Artifact Registry when the scenario says container registry, Docker images, Maven/npm/Python packages, secure artifact storage, regional repositories, or replacing Container Registry.

Common trap: Artifact Registry is not source control. It stores built artifacts and dependencies, not the application source code workflow.

Artifact Analysis / Container Analysis

Why an org uses it: Artifact Analysis provides vulnerability and metadata information about container images and software artifacts. Organizations use it to understand risk in images and feed security decisions in the software supply chain.

PCA trigger: Pick Artifact Analysis when the requirement says vulnerability scanning, package/image vulnerability metadata, SBOM-like artifact metadata, or identify vulnerable container images before deployment.

Common trap: Scanning is not enforcement. Artifact Analysis can identify risk, but Binary Authorization is what can enforce a deploy-time allow/block policy.

Cloud Deploy

Why an org uses it: Cloud Deploy gives organizations a managed continuous delivery control plane for promoting releases through target environments. It is useful when teams need consistent delivery pipelines, staged promotion, approvals, canary/rollback patterns, and auditability for GKE or Cloud Run.

PCA trigger: Pick Cloud Deploy when the scenario says deploy from dev to staging to production, promote releases, approval gates, delivery pipeline, GKE/Cloud Run deployment progression, canary, or rollback.

Common trap: Do not use Cloud Build alone as the full release-management answer when the requirement is environment promotion and deployment governance. Cloud Build can invoke deploys, but Cloud Deploy is purpose-built for CD.

Binary Authorization

Why an org uses it: Binary Authorization lets organizations enforce that only trusted container images are deployed. It supports a chain-of-trust model where images must meet policy requirements such as approved attestations before they run.

PCA trigger: Pick Binary Authorization when the requirement says only signed images, only approved builds, deployment gate, enforce trusted artifacts, prevent unverified images from running, or supply-chain policy enforcement for GKE/Cloud Run/Distributed Cloud.

Common trap: Binary Authorization does not build images, store images, or scan images by itself. It enforces policy at deployment time based on attestations/policy.

Container image signing and attestations

Why an org uses it: Signing and attestations let an organization prove where an artifact came from, how it was built, and whether it passed required checks. This is central to higher-maturity DevSecOps and supply-chain security.

PCA trigger: Pick this concept when the scenario says provenance, attest build, signed artifact, chain of trust, SLSA-style controls, or proof that the image came from the approved pipeline.

Common trap: Do not confuse “image exists in the registry” with “image is trusted.” Registry storage is not the same as provenance or approval.

Terraform

Why an org uses it: Terraform provides declarative infrastructure as code that can be version-controlled, reviewed, planned, applied, and reused. Organizations use it to make infrastructure repeatable and reduce manual console changes across teams and environments.

PCA trigger: Pick Terraform when the scenario says declarative IaC, multi-cloud, code review for infrastructure, repeatable deployments, drift control, modules, or source-controlled infrastructure.

Common trap: Terraform is not a CI/CD service by itself. It still needs a controlled execution workflow, permissions model, state management, and change-review process.

Infrastructure Manager

Why an org uses it: Infrastructure Manager is Google Cloud’s managed service for deploying and managing Google Cloud resources using Terraform. It reduces the need to build your own Terraform execution environment for Google Cloud infrastructure deployments.

PCA trigger: Pick Infrastructure Manager when the scenario says managed Terraform on Google Cloud, deploy infrastructure resources from Terraform configs, reduce custom IaC runner management, or standardize Google Cloud infrastructure deployment.

Common trap: Do not confuse Infrastructure Manager with Cloud Deploy. Infrastructure Manager deploys infrastructure resources; Cloud Deploy promotes application releases to runtime targets.

Cloud Deployment Manager

Why an org uses it: Cloud Deployment Manager is an older Google Cloud-native infrastructure deployment service. It may appear in older materials or existing environments, so you should know what it does.

PCA trigger: Know it when the scenario references existing Deployment Manager templates or legacy Google Cloud-native IaC. For a new architecture, Terraform or Infrastructure Manager is usually the better modern answer.

Common trap: Do not over-prioritize Deployment Manager for greenfield PCA answers. It is less likely to be the best choice compared with Terraform-based patterns.

Cloud Source Repositories

Why an org uses it: Cloud Source Repositories is Google Cloud’s legacy managed Git repository service. It matters mostly for recognizing older architectures or existing customer environments.

PCA trigger: Know it when the question says native Google-hosted Git repositories or existing Cloud Source Repositories usage.

Common trap: Do not select it as the default new source-control service. Effective June 17, 2024, Cloud Source Repositories is not available to new customers, so greenfield designs should use other source hosting options.

Cloud Code

Why an org uses it: Cloud Code helps developers build, debug, and deploy cloud-native applications from IDEs such as VS Code and IntelliJ. It improves developer productivity for Kubernetes, Cloud Run, and Google Cloud workflows.

PCA trigger: Pick Cloud Code when the scenario says IDE integration, local developer workflow, Kubernetes/Cloud Run development support, or simplify development against Google Cloud services.

Common trap: Cloud Code is not the production CI/CD control plane. It helps developers work locally or in an IDE; Cloud Build/Cloud Deploy handle automated build and delivery pipelines.

Cloud Shell Editor and Cloud Shell Terminal

Why an org uses it: Cloud Shell gives users a browser-based terminal and editor with the Google Cloud CLI and common tools already installed and authenticated. It is useful for quick administration, demos, labs, tutorials, and emergency access without configuring a local machine.

PCA trigger: Pick Cloud Shell when the scenario says browser-based terminal, preinstalled tools, no local setup, quick administrative commands, or temporary cloud development environment.

Common trap: Cloud Shell is not a production build system and should not be treated as the organization’s release pipeline.

Google Cloud SDK, gcloud, gsutil, and bq

Why an org uses it: The Google Cloud SDK provides command-line tools for managing Google Cloud resources. gcloud is the broad resource/admin CLI, gsutil is commonly used for Cloud Storage operations, and bq is used for BigQuery tasks.

PCA trigger: Pick these tools when the scenario says script administrative actions, automate resource management, move/manage Cloud Storage objects, run BigQuery commands, or operate from a terminal.

Common trap: Do not confuse CLI tooling with architecture governance. Scripts need IAM, auditability, change control, and ideally IaC/CI workflows for repeatable production changes.

Cloud Emulators

Why an org uses it: Cloud Emulators let developers test against local versions of supported Google Cloud services. This reduces cost and speeds development because tests do not need to call real cloud resources for every run.

PCA trigger: Pick emulators when the scenario says local development, automated tests without real cloud resources, offline testing, or avoid cost/side effects during development.

Common trap: Emulators are not full production equivalents. They help with development and test loops, but final validation should still happen in real Google Cloud environments.

Google API client libraries

Why an org uses it: Client libraries let applications call Google Cloud APIs using language-specific, supported libraries. They handle common tasks like authentication integration, pagination, retries, and long-running operations more cleanly than hand-written REST calls.

PCA trigger: Pick client libraries when the scenario says application code needs to call Google Cloud APIs reliably, use supported language libraries, or reduce boilerplate for API integration.

Common trap: Do not hard-code credentials in application code. Use service accounts, Workload Identity Federation, Secret Manager where appropriate, and least-privilege IAM.

Google API best practices

Why an org uses it: API best practices are about designing integrations that are reliable, secure, observable, and maintainable. PCA may test retries, idempotency, pagination, auth, quotas, exponential backoff, and proper error handling.

PCA trigger: Pick this concept when the scenario says API integration reliability, avoid duplicate operations, handle rate limits, retry transient failures, or safely call Google APIs at scale.

Common trap: Do not solve API reliability only by increasing quotas. Often the better answer is backoff, idempotency, batching, pagination, and proper error handling.

SDLC, CI/CD process design, and release management

Why an org uses it: Organizations use CI/CD process design to standardize how code moves from commit to production. This includes build/test automation, approvals, separation of duties, rollback plans, environment promotion, progressive delivery, and audit trails.

PCA trigger: Pick this concept when the scenario asks how to reduce release risk, improve velocity safely, support approvals, standardize release process, or balance developer autonomy with governance.

Common trap: PCA is not always looking for another product. Sometimes the right answer is a controlled process: tests, approvals, rollback strategy, environment separation, and change management.

Testing frameworks and quality gates

Why an org uses it: Testing frameworks and quality gates help prove that a release is safe before it reaches production. They can include unit tests, integration tests, security checks, policy checks, load tests, and manual approvals for sensitive environments.

PCA trigger: Pick testing/quality gates when the scenario says prevent bad releases, validate changes before deployment, enforce checks before production, reduce rollback frequency, or meet compliance requirements.

Common trap: Do not rely only on monitoring after deployment. PCA often rewards catching issues earlier in the pipeline and pairing that with rollback and observability.

Common PCA Comparison Patterns

Architecture Patterns to Recognize

• Secure container delivery: source control -> Cloud Build -> Artifact Registry -> Artifact Analysis -> attestation/signing -> Binary Authorization -> Cloud Deploy -> GKE/Cloud Run.

• Regulated application promotion: Cloud Deploy pipeline with dev/stage/prod targets, approvals, audit trail, rollback plan, and separation of duties.

• Private enterprise builds: Cloud Build private pools when builds need private network access, custom worker control, or access to internal dependencies.

• Managed IaC: Terraform configuration stored in source control, reviewed through pull requests, executed through Infrastructure Manager or a controlled CI pipeline.

• Artifact governance: store packages/images in Artifact Registry, apply IAM, scan artifacts, and prevent untrusted images from running with Binary Authorization.

• Developer productivity: Cloud Code for IDE workflows, Cloud Shell for browser-based admin/dev tasks, and Cloud SDK for local/automation CLI workflows.

• Reliable API integrations: use Google API client libraries with retries, pagination, backoff, idempotency, and least-privilege authentication.

• Quality gates: require tests, vulnerability checks, policy checks, and approval gates before production deployment.

Common PCA Traps

• Choosing Cloud Build when the requirement is release promotion across environments. Use Cloud Deploy for managed CD progression.

• Treating vulnerability scanning as deployment enforcement. Use Artifact Analysis for metadata/scanning and Binary Authorization for deploy-time enforcement.

• Using Artifact Registry as if it were source control. It is for artifacts and packages, not Git source workflows.

• Picking Cloud Source Repositories for a new greenfield design. It is a legacy service and not available to new customers.

• Using Cloud Deployment Manager as the default modern IaC answer. Prefer Terraform or Infrastructure Manager for current designs.

• Letting developers deploy directly from laptops to production without a controlled pipeline, audit trail, approvals, and rollback plan.

• Embedding long-lived service account keys or secrets in build configs. Use least privilege and proper secret/identity patterns.

• Assuming managed CI/CD removes the need for tests. PCA still expects unit, integration, security, policy, and release validation.

• Confusing local development tools with production automation. Cloud Code and Cloud Shell help developers; Cloud Build and Cloud Deploy run the release pipeline.

• Ignoring idempotency, backoff, and retry design for API integrations that run at scale.

Mini Scenario Drills

Cram Summary

• Cloud Build = managed CI/build/test/package.

• Cloud Build private pools = dedicated/private build workers and private network access.

• Artifact Registry = store container images and language packages.

• Artifact Analysis = vulnerability and artifact metadata.

• Binary Authorization = enforce trusted/signed/attested images at deployment time.

• Cloud Deploy = managed CD and promotion across environments for GKE/Cloud Run.

• Terraform = declarative IaC ecosystem. Infrastructure Manager = managed Terraform deployment on Google Cloud.

• Cloud Deployment Manager = older Google-native IaC. Know it, but avoid as a default greenfield answer.

• Cloud Source Repositories = legacy Google Git hosting; not the default new answer.

• Cloud Code = IDE productivity. Cloud Shell = browser terminal/editor. Cloud SDK = CLI tools.

• gcloud = broad resource management. gsutil = Cloud Storage. bq = BigQuery.

• Cloud Emulators = local dev/test for supported services.

• Google API client libraries = safer application integration with Google APIs.

• Good PCA answers include process: tests, approvals, rollout strategy, rollback, auditability, and least privilege.

Sources Checked

Google Professional Cloud Architect exam guidance; Google Cloud docs for Cloud Build, Artifact Registry, Cloud Deploy, Binary Authorization, Artifact Analysis, software supply chain security, Infrastructure Manager, Cloud Source Repositories release notes, Cloud Shell, Cloud SDK/gcloud, Cloud Code, and Google Cloud API/client-library guidance.