11.2 Cloud Build Workers and Step Dependencies

Google Cloud Professional Cloud Developer Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Exam and Compute Platform Decisions

1.1 Current Exam, Sources, and Scenario Method 1.2 Cloud Run Execution and Platform Selection 1.3 GKE Modes and Compute Engine Trade-offs

2 Chapter 2: Container Engineering and API Contracts

2.1 Stateless Microservices and Multi-stage Builds 2.2 Container Hardening, Signals, and Layer Caching 2.3 REST, gRPC, and Protobuf Contracts

3 Chapter 3: gRPC Compatibility and Geographic Routing

3.1 Schema Evolution and gRPC Routing 3.2 Geography, Network Tiers, and Load Balancers 3.3 Serverless NEGs, Sessions, and Edge Controls

4 Chapter 4: API Management and Caching

4.1 API Management & Rate Limiting with Apigee and API Gateway 4.2 Memorystore and Cache Access Patterns 4.3 Cache Invalidation, Capacity, and Failover

5 Chapter 5: Messaging, Task Dispatch, and Orchestration

5.1 Event-Driven Messaging with Cloud Pub/Sub 5.2 Task Queues & Rate Throttling with Cloud Tasks 5.3 Event Routing and Service Orchestration: Eventarc & Cloud Workflows

6 Chapter 6: Resilience and Relational Availability

6.1 Designing Resilient Systems: Circuit Breaking, Retries & Failover 6.2 Cloud SQL Availability and Recovery 6.3 Connection Budgets and Spanner Consistency

7 Chapter 7: Distributed Schemas and NoSQL Data Models

7.1 Spanner Keys, Indexes, and Transactions 7.2 Firestore Data, Indexes, and Transactions 7.3 Bigtable Row Keys and Replication

8 Chapter 8: Object Storage and Application Identity

8.1 Cloud Storage Lifecycle and Signed Access 8.2 Workload Identity and Service Authentication 8.3 Secret Delivery, Rotation, and IAP

9 Chapter 9: Security, Data Integration, and Developer Credentials

9.1 Private Communication, Key Rotation, and Vulnerability Response 9.2 AlloyDB Schemas and BigQuery Ingestion 9.3 CLI Configurations, Local ADC, and Cloud Shell

10 Chapter 10: Managed Development and Automated Tests

10.1 Cloud Workstations and the Container Inner Loop 10.2 Emulating Google Cloud Services & Database Auth Proxies 10.3 Automated Testing Strategies: Unit, Integration, and Mocking

11 Chapter 11: AI Development Tools and Build Pipelines

11.1 AI Coding Assistants, Context, MCP, and Test Review 11.2 Cloud Build Workers and Step Dependencies 11.3 Builders, Substitutions, Triggers, and IAM

12 Chapter 12: Artifact Security and Admission Policies

12.1 Artifact Management and Vulnerability Scanning with Artifact Registry 12.2 Build Provenance and Admission Concepts 12.3 Attestors, Policy Enforcement, and Break-glass

13 Chapter 13: Cloud Run and GKE Deployment Configuration

13.1 Cloud Run Deployment and Scaling Configuration 13.2 Cloud Run CPU, Private Egress, and Secrets 13.3 GKE Workload Controllers and Gateway Routing

14 Chapter 14: Kubernetes Resources, Health, and Progressive Releases

14.1 GKE Resources, OOM Diagnosis, and Autoscaling 14.2 Container Health Probes, Lifecycle Hooks & Graceful Shutdown 14.3 Progressive Delivery: Traffic Splitting, Canary, and Blue/Green Rollouts

15 Chapter 15: Source/Event Deployment and Cloud API Integration

15.1 Source Deployment, Event Receivers, and API Versions 15.2 Client Libraries, Service Enablement, and ADC 15.3 API Responses, Pagination, Caches, and Retries

16 Chapter 16: Tracing, Sampling, and Monitoring

16.1 Trace Context and OpenTelemetry Export 16.2 Custom Spans, Trace Analysis, and Sampling 16.3 Application Metrics, Health Checks & Alerting with Cloud Monitoring

17 Chapter 17: Structured Logs, Routing, and Error Management

17.1 Structured Logs, Trace Correlation, and Queries 17.2 Log Routing, Export Destinations, and Exclusions 17.3 Error Reporting Formats and Regression Handling

18 Chapter 18: Profiling, Generative AI, and Assisted Troubleshooting

18.1 Cloud Profiler Types and Flame Graph Analysis 18.2 Generative AI Integration with the Google Gen AI SDK 18.3 Evidence-Based Troubleshooting with AI Assistance

11.2 Cloud Build Workers and Step Dependencies

Key Takeaways Explain This Topic AI

waitFor omitted means all preceding steps; waitFor with a dash starts without dependencies.

Fan-in steps must reference every required independent predecessor.

A private pool alone does not bridge a second service peering to a private GKE control plane.

Last updated: October 2026

Continuous Integration Pipelines with Cloud Build

Modern cloud-native software delivery requires automated, repeatable, and scalable continuous integration (CI) pipelines. Cloud Build is Google Cloud's serverless continuous integration and continuous delivery (CI/CD) platform that executes build steps natively inside container environments. It scales elastically to handle high-concurrency build spikes without requiring developers to provision, patch, or maintain build servers.

For the Google Cloud Professional Cloud Developer exam, you must master Cloud Build architecture, pipeline syntax ( cloudbuild.yaml ), parallel execution and dependency modeling ( waitFor ), worker pool networking, variable substitutions, trigger automations, and service account security boundaries.

Cloud Build Architecture & Worker Pools

At its core, Cloud Build treats every operation in your pipeline as a container execution. A build consists of a sequence of build steps , where each step is invoked inside a dedicated container image. Cloud Build mounts a shared workspace directory across all steps at /workspace , enabling subsequent steps to inspect, modify, and consume artifacts generated by earlier steps.

Default Public Worker Pools vs. Private Worker Pools

When a build is initiated, Cloud Build routes execution to a Worker Pool . Google Cloud provides two fundamentally different worker pool architectures:

• Architectural Dimension Default Public Worker Pool Private Worker Pools
• Hosting Model Multi-tenant Google-managed environment Single-tenant dedicated worker instances

Network Placement Google-owned VPC with direct public internet egress Peered to customer Virtual Private Cloud (VPC) via Private Service Access (PSA)

Private Network Access Cannot access RFC 1918 internal IPs or private VPC services Configured private routes; other service peerings are not transitively reachable

VPC Service Controls Not compliant with strict VPC Service Controls perimeters Fully supported within VPC Service Controls (VPC-SC) perimeters

Static Egress IPs Dynamic public IP addresses; cannot be whitelisted Static egress needs the documented private-pool network/NAT architecture; simple peering alone does not make Cloud NAT transitive

Compute Sizing Standard machine types ( e2-standard-2 through e2-standard-32 ) Custom machine types, custom disk sizes (up to 4,000 GB), and customizable concurrency

Billing Model Billed per build-minute consumed Usage-based build-time pricing by selected machine resources; not a permanently allocated idle VM fleet

Private Worker Pools in Enterprise Topologies

In secure enterprise architectures, workloads such as private Google Kubernetes Engine (GKE) control planes, private Cloud SQL instances, or internal artifact repositories disable public IP access entirely. If a pipeline running on the default public worker pool attempts to run kubectl apply against a private GKE cluster control plane ( 172.16.0.2 ), the operation fails with a network timeout.

To resolve this, developers configure a Private Worker Pool :

A dedicated Service Networking connection (VPC Network Peering) is established between the customer VPC and the Google Services VPC.

The Private Worker Pool is allocated a reserved internal IP range ( /24 CIDR block) within the customer network.

Cloud Build workers spin up inside this isolated network slice, with access limited to routes and DNS deliberately made reachable. VPC peering is non-transitive: a private GKE control plane or Cloud SQL reached through another service peering may require the documented VPN/proxy or other supported connectivity design. ## Creating a Private Worker Pool peered to a custom VPC network

• gcloud builds worker-pools create enterprise-pool \
• -project=my-project-id \
• -region=us-central1 \
• -peered-network=projects/my-project-id/global/networks/production-vpc \
• -worker-machine-type=e2-standard-8 \
• -worker-disk-size=200GB \
• -no-external-ip-address
• Anatomy of cloudbuild.yaml

A Cloud Build configuration file is written in YAML or JSON and defines the exact state machine of your pipeline. The primary building blocks include:

steps : An ordered list of containerized actions to execute.

name : The container image used to execute the step (the "builder").

args : Arguments passed directly to the container entrypoint.

entrypoint : Overrides the default ENTRYPOINT defined in the builder container image.

env : Environment variables injected into the step container.

dir : Working directory inside the container, relative to /workspace .

id : An optional unique string identifier for the step, used for dependency tracking.

waitFor : Controls step execution order and parallelization.

timeout : Maximum execution time for an individual step or the overall build.

secretEnv : Secret environment variables extracted securely from Secret Manager.

Directed Acyclic Graphs (DAGs) and Parallel Execution

By default, Cloud Build executes steps serially in the order they are listed in the YAML file. However, modern CI pipelines must run unit tests, security linters, static code analysis, and asset minification concurrently to minimize build duration.

Cloud Build supports arbitrary Directed Acyclic Graph (DAG) orchestration through the waitFor field:

Sequential Default: If waitFor is omitted, the step waits for all preceding steps to complete successfully.

Parallel Start ( waitFor: ['-'] ): Setting waitFor: ['-'] instructs Cloud Build that this step has no dependencies and should begin execution immediately upon build start, concurrently with any other zero-dependency steps.

Explicit Fan-In ( waitFor: ['step-a', 'step-b'] ): A step will pause execution until all referenced step IDs have finished successfully.

Concrete Example: Parallel CI/CD Pipeline steps:

• # Step 1: Run unit tests immediately in parallel
• name: 'golang:1.26-bookworm'
• id: 'run-unit-tests'
• entrypoint: 'go'
• args: ['test', '-v', '-race', './...']
• waitFor: ['-']

• # Step 2: Run security linter immediately in parallel
• name: 'securego/gosec:v2.22.0'
• id: 'run-security-linter'
• args: ['-exclude-dir=vendor', './...']
• waitFor: ['-']

• # Step 3: Build container image only after tests and lint pass
• name: 'gcr.io/cloud-builders/docker'
• id: 'build-image'

args:

• 'build'
• '-t'
• 'us-central1-docker.pkg.dev/$PROJECT_ID/app-repo/payment-service:$SHORT_SHA'
• '-t'
• 'us-central1-docker.pkg.dev/$PROJECT_ID/app-repo/payment-service:latest'
• '.'
• waitFor: ['run-unit-tests', 'run-security-linter']

• # Step 4: Push the tagged image to Artifact Registry
• name: 'gcr.io/cloud-builders/docker'
• id: 'push-image'

args:

• 'push'
• '--all-tags'
• 'us-central1-docker.pkg.dev/$PROJECT_ID/app-repo/payment-service'
• waitFor: ['build-image']

• # Step 5: Deploy to Cloud Run using Secret Manager credential
• name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
• id: 'deploy-cloud-run'
• entrypoint: 'gcloud'

args:

• 'run'
• 'deploy'
• 'payment-service'
• '--image=us-central1-docker.pkg.dev/$PROJECT_ID/app-repo/payment-service:$SHORT_SHA'
• '--region=us-central1'
• '--platform=managed'
• '--set-env-vars=ENVIRONMENT=$_ENVIRONMENT'
• waitFor: ['push-image']

substitutions:

_ENVIRONMENT: 'staging'

options:

• substitutionOption: 'ALLOW_LOOSE'
• logging: 'CLOUD_LOGGING_ONLY'
• timeout: '1200s'

Official references checked October 18, 2026: Google Cloud 1 , Google Cloud 2 .