Study guide
5.3 Event Routing and Service Orchestration: Eventarc & Cloud Workflows
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
5.3 Event Routing and Service Orchestration: Eventarc & Cloud Workflows
Key Takeaways Explain This Topic AI
Eventarc routes events using the CloudEvents 1.0 standard from supported Google Cloud sources to Cloud Run, Cloud Workflows, and GKE destinations.
Direct triggers (e.g., Cloud Storage) offer lower latency without audit logs, whereas Cloud Audit Log triggers capture operations across GCP APIs but require Data Access audit logs enabled in Cloud IAM.
Cloud Workflows orchestrates complex, multi-step business logic as declarative serverless state machines in YAML, featuring native parallel execution, connectors, and OIDC authentication.
Workflows provides granular error handling via try/except/retry blocks with customizable backoff multipliers, predicate conditions, and compensating transaction steps.
The choice between Choreography (Eventarc/Pub/Sub) and Orchestration (Cloud Workflows) balances autonomous event decoupling against centralized visibility, strict step sequencing, and automated sagas.
Last updated: October 2026
Event Routing and Service Orchestration: Eventarc & Cloud Workflows
Modern cloud-native architectures rely on two complementary architectural patterns to coordinate microservices: Event Routing (Choreography) and Service Orchestration . In Google Cloud, Eventarc provides the routing fabric that captures and normalizes events across Google Cloud services and delivers them to serverless consumers, while Cloud Workflows provides a stateful orchestration engine to coordinate multi-step, distributed business processes.
Eventarc Architecture & The CloudEvents Standard
Eventarc provides a unified, serverless event bus that transforms state changes across supported Google Cloud services into standardized CloudEvents v1.0 payloads. Instead of requiring applications to maintain bespoke event adapters, Eventarc standardizes event headers, delivery mechanisms, and filtering rules.
CloudEvents Format
Every event delivered by Eventarc adheres to the CNCF CloudEvents 1.0 specification:
id : Unique identifier for the event instance.
source : URI identifying the context in which the event occurred (e.g., //storage.googleapis.com/projects/_/buckets/my-bucket ).
specversion : Always 1.0 .
type : Specific event type (e.g., google.cloud.storage.object.v1.finalized , google.cloud.audit.log.v1.written ).
time : Timestamp of when the event occurred in RFC 3339 format.
data : Service-specific JSON payload containing resource details.
Event Destinations
Eventarc delivers CloudEvents via HTTP POST requests to:
- Cloud Run services (fully managed container endpoints)
- Cloud Functions (2nd gen) (built on Cloud Run)
- Google Kubernetes Engine (GKE) services
- Cloud Workflows (initiating workflow executions)
Under the hood, Eventarc automatically manages an internal Cloud Pub/Sub transport topic and subscription to buffer and deliver events reliably.
Direct Triggers vs. Cloud Audit Log Triggers
Eventarc supports two distinct trigger mechanisms with different performance, scope, and configuration requirements.
Trigger Type Supported Sources Latency & Performance Configuration Requirements
Direct Triggers Cloud Storage ( finalized , deleted , archived , metadataUpdated ), Pub/Sub Avoids the audit-log delivery path; latency varies by source and load No special logging configuration required; scoped directly to bucket or topic
Cloud Audit Log Triggers Supported Google Cloud APIs (Compute Engine, BigQuery, IAM, Cloud SQL, etc.) Slightly higher latency; relies on Cloud Logging ingestion pipeline Requires Data Access audit logs to be explicitly enabled in IAM Audit Config for data operations
The Audit Log Configuration Trap
Admin Activity, System Event and Policy Denied logs have their own default/always-written behavior; do not treat all audit logging as one switch. Data Access audit logs (which record data reads and writes) are disabled by default for many services; BigQuery is a notable default-enabled exception. Check the relevant service and operation rather than assuming every audit trigger needs the same logging category. Configure the needed data-operation logging explicitly and review its cost and access controls.
Caution
Exam Trap: Missing Data Access Audit Logs :
If you create an Eventarc trigger listening for google.cloud.audit.log.v1.written filtered by storage.googleapis.com or bigquery.googleapis.com data operations, verify that the matching audit entry is actually produced and the necessary Data Read/Data Write category is enabled. BigQuery Data Access logging is normally already enabled; exact method/type filters and trigger permissions still matter. ## Create a Direct Cloud Storage trigger targeting Cloud Run
- gcloud eventarc triggers create gcs-direct-trigger \
- -location=us-central1 \
- -destination-run-service=document-processor \
- -destination-run-region=us-central1 \
- -event-filters="type=google.cloud.storage.object.v1.finalized" \
- -event-filters="bucket=user-documents-bucket" \
- -service-account=eventarc-invoker@my-project.iam.gserviceaccount.com
- Cloud Workflows: Serverless Service Orchestration
While Eventarc excels at routing individual events, complex business workflows require coordinating multiple microservices in a deterministic sequence, managing state transitions, and handling failures. Cloud Workflows is a fully managed, serverless orchestration engine that executes state machines defined in declarative YAML or JSON.
Core Workflows Constructs
steps : An ordered list of steps executed sequentially unless altered by branching.
call : Invoking an external HTTP endpoint ( http.get , http.post ) or a pre-built Google Cloud Connector ( googleapis.bigquery.v2... , googleapis.pubsub.v1... ).
args : Arguments passed to the call, including URL, query parameters, JSON payload, and authentication.
auth : Built-in credential management supporting type: OIDC or type: OAuth2 using dedicated service accounts.
switch : Conditional branching logic based on variable evaluations.
parallel : Executing multiple branches concurrently with optional concurrency throttling.
try / except / retry : Granular exception handling and retry policies.
Declarative YAML Workflow Example main:
params: [event]
steps:
- init:
assign:
- orderId: ${event.data.orderId}
- customerEmail: ${event.data.email}
- amount: ${event.data.amount}
- reserveInventory:
try:
call: http.post
args:
url: https://inventory-service-xyz.a.run.app/api/reserve
auth:
type: OIDC
body:
- orderId: ${orderId}
- result: inventoryResult
retry:
- predicate: ${http.default_retry_predicate}
- max_retries: 5
backoff:
- initial_delay: 2
- max_delay: 60
- multiplier: 2
- processPayment:
try:
call: http.post
args:
url: https://payment-service-xyz.a.run.app/api/charge
auth:
type: OIDC
body:
- orderId: ${orderId}
- amount: ${amount}
- result: paymentResult
except:
as: e
steps:
- compensateInventory:
call: http.post
args:
url: https://inventory-service-xyz.a.run.app/api/release
auth:
type: OIDC
body:
orderId: ${orderId}
- failWorkflow:
raise: ${e}
- notifyCustomer:
call: http.post
args:
url: https://notification-service-xyz.a.run.app/api/send
auth:
type: OIDC
body:
- email: ${customerEmail}
- status: "ORDER_CONFIRMED"
- result: notificationResult
- returnSuccess:
return:
- status: "COMPLETED"
- orderId: ${orderId}
- Retrying Business Operations Safely
max_retries: 5 allows five retries after the initial call, so up to six attempts. The retry policy is a sibling of try , not a field nested inside its HTTP arguments. A retry predicate must be defined or imported; use ${http.default_retry_predicate} for the documented idempotent HTTP status set. The reserve-inventory endpoint must deduplicate by orderId , or a retry could reserve the same stock twice. Compensating release and refund endpoints also need stable idempotency keys.
Choreography vs. Orchestration Decision Framework
Architecting distributed systems requires choosing between Choreography (Eventarc, Pub/Sub) and Orchestration (Cloud Workflows).
Dimension Event Choreography (Eventarc / Pub/Sub) Service Orchestration (Cloud Workflows)
Coordination Model Decentralized: Services react to published events independently Centralized: A single coordinator executes defined steps sequentially
Coupling Loose coupling: Publishers have zero knowledge of downstream listeners Tighter coupling: The workflow coordinator defines step dependencies
State & Visibility Implicit: Global business state is fragmented across multiple services Explicit: Current execution state, variables, and history are centralized
Compensating Actions Difficult: Requires publishing rollback events that every service must handle Native: Handled cleanly in except blocks using the Saga pattern
Error Handling Localized to individual subscribers; failures do not pause other flows Global: Step retries, conditional fallbacks, and escalation policies
Debugging & Tracing Requires distributed tracing (Cloud Trace) across all event consumers Centrally visible in Cloud Console with step-by-step audit logs
Ideal Scenarios High-throughput data ingestion, real-time analytics, decoupled notifications Multi-step order checkout, payment authorization sagas, human approval chains
The Saga Pattern in Cloud Workflows
In microservice architectures, distributed transactions across independent databases cannot use traditional ACID two-phase locking. The Saga Pattern manages distributed transactions by breaking them into a sequence of local transactions. If any step fails, Cloud Workflows coordinates compensating transactions in reverse order (as demonstrated in the YAML example above: releasing inventory if payment capture fails), restoring eventual data consistency across all microservice boundaries.
Official references checked October 18, 2026: Google Cloud 1 .