Prepare and test your skills
Prepare and test your skills
Asynchronous Execution and Traffic Management is the practice of decoupling work from the immediate request path and controlling how requests flow to backend endpoints. Traffic flows from clients to Kubernetes Services (opens in a new tab) that forward requests to endpoints in different zones. Cloud Tasks sits between producers and consumers as a queue, holding asynchronous work and delivering it at a controlled rate with rate limiting and throttling to keep backends stable. Cloud Service Mesh adds control at the application layer when basic distribution is not enough for stability and observability.
Traffic distribution is the mechanism that spreads incoming traffic across the endpoints behind a Kubernetes Service. Traffic distribution from the Service to its zone endpoints works best when incoming traffic is evenly distributed and each Kubernetes Service has three or more endpoints per zone. When traffic is uneven or a zone has fewer than three endpoints, some endpoints can receive disproportionate load while others sit underused. Keeping at least three endpoints per zone gives the distributor enough destinations to balance load smoothly.
Exam tip: Traffic distribution works best with evenly distributed incoming traffic and three or more endpoints per zone for each Kubernetes Service.
Cloud Service Mesh is an application-layer traffic management plane that sits between services and controls how requests move from one service to another. Unlike basic Service-level distribution, the mesh operates at the application layer, so it can see and shape request behavior across services. Consider implementing a mesh like Istio when an application needs more granular control over traffic distribution, advanced routing policies, and observability.
The mesh divides application-layer management into three related capabilities:
Reliability engineering and automated scheduling is the practice of using observability, error handling, and event-driven automation to keep applications running without manual intervention. Workflows (opens in a new tab) acts as the central automation destination that runs ordered application logic when something happens in the system. Cloud Monitoring (opens in a new tab) and Cloud Logging provide continuous signals that reveal where errors occurred and where failures might occur next. Cloud Scheduler (opens in a new tab) automates recurring administrative tasks and time-based service triggers.
Observability signals for reliability are three complementary data types that together show system health and transaction behavior. These signals flow from application components and Google Cloud services to monitoring and logging systems for analysis:
Comprehensive monitoring of these signals helps teams find out where and why errors occurred and detect potential failures before errors reach users. Default service metrics also reveal component dependencies and their impact on overall workload performance.
Error handling and proactive troubleshooting means building retry policies and error-handling routines into Workflows and Cloud Tasks and enabling logging across all workload components. Logging data flows from each component to collection systems, and teams should activate detailed sources such as Cloud Storage access logs and Virtual Private Cloud Flow Logs to capture access and network behavior. Custom application metrics can also be created and published with the Google Cloud SDK when default metrics do not cover workload-specific needs. Logging volume creates a cost tradeoff because storing every log increases expense, so log sinks support exclusion filters that prevent selected logs from being stored while keeping critical failure signals.
Event-driven automation to Workflows means routing platform events directly to a workflow execution without manual polling. An event flows from the source service through the event-routing layer to Workflows, which then runs the defined resilient logic. Supported sources for this pattern include Cloud Pub/Sub, Cloud Run, Cloud Run functions, Cloud Resource Manager, Cloud Retail, and Cloud Profiler. Two event types feed this flow: audit log events that record administrative and data-access activity, and direct events from services such as Cloud Pub/Sub and Cloud Run functions. Audit log routing supports recurring administrative reactions, while direct events support near-real-time service triggers, so missing or filtered events will prevent the automated response from starting.
Resource monitoring, alerts, and automated scheduling keep automated systems reliable under changing load and time. Resource data flows from services such as Google Kubernetes Engine, Compute Engine, and Managed Service for Apache Spark to Cloud Monitoring, where CPU consumption, network I/O, and disk I/O metrics reveal under-provisioned and over-provisioned resources. Under-provisioning risks slowdowns and failures, while over-provisioning wastes capacity. Alerts should focus on critical metrics with carefully set thresholds so teams respond quickly to significant issues without alert fatigue, and Cloud Scheduler triggers recurring work on a schedule so administrative and time-based tasks do not depend on manual action.
Exam tip: Set alert thresholds on critical metrics to minimize alert fatigue, and use exclusion filters on log sinks to control logging costs while keeping failure signals.
Service orchestration and event-driven architecture are two complementary ways to build scalable and decoupled cloud-native applications. Workflows (opens in a new tab) provides stateful orchestration by running loosely coupled services in an order that you define and waiting for operations to complete. Eventarc (opens in a new tab) provides loosely coupled event delivery by routing events from providers to consumers without the provider naming a specific destination.
Workflows is a serverless orchestration service that separates the logic that sequences and links services from core business logic. A workflow is a series of steps written in YAML or JSON using the Workflows syntax, with standard library functions and built-in environment variables for building arguments and processing responses. A workflow can combine any HTTP-based API service, which makes service dependencies explicit and observable end-to-end, and it can be event-driven. Workflows publishes lightweight, serverless connectors that simplify calling other Google Cloud APIs inside a workflow, so the developer does not need to know the details of the target API.
Supported connectors include connectors for Cloud Run functions, Firestore, Cloud Translation API, BigQuery, and a connector to Application Integration for triggering and waiting for an integration. A typical lightweight orchestration moves data through an ordered sequence:
Eventarc is a managed Google Cloud service that listens for events from other services and routes them to destinations. An event is a data record expressing an occurrence and its context, such as a change to database data, a file added to storage, or a scheduled job. Each event is a discrete unit of communication that is independent of other events. Events flow from an event provider to an interested event consumer, with routing based on information contained in the event. Eventarc supports events from more than 130 Google providers, which send events directly from the source or through Cloud Audit Logs entries. Events are routed to the event receiver through Pub/Sub push subscriptions, and the managed Eventarc control plane requires no provisioned infrastructure.
Eventarc supports the following event destinations:
Combining Eventarc triggers with Workflows executions links an asynchronous occurrence to a stateful sequence of operations. Eventarc delivers the event to the selected destination, and that destination determines the next step: Cloud Run functions for a standalone action such as an SMS alert, Workflows for a complex multi-step process, or a GKE service when the larger solution runs in a cluster. When Workflows is the destination, the event payload becomes the workflow input and the workflow runs its steps in order. Dataflow job management shows this pattern clearly, where a Dataflow job first enters JOB_STATE_QUEUED, then moves to JOB_STATE_RUNNING, and finally reaches JOB_STATE_DONE. The event payload describes the job at trigger time and omits the steps, pipeline_description, and transform_name_mapping fields. The resulting workflow might send an alert if a critical job fails, notify users or start another job when a batch job completes, or clean up resources such as Cloud Storage buckets.
Choosing between Workflows and Application Integration is a decision about code-based orchestration versus low-code business-system integration. Workflows is code-based orchestration for developers, data engineers, and platform teams building applications, automations, and data pipelines. Application Integration (opens in a new tab) is low-code business-system integration for connecting systems with differing data structures, such as Salesforce, ServiceNow, Cloud SQL, BigQuery, Spanner, and Oracle DB.
| Product | Primary user and interface | Choose when |
|---|---|---|
| Workflows | Developer interface using YAML or JSON steps and connectors | The work sequences loosely coupled services, pipelines, or infrastructure automation in a defined order |
| Application Integration | Drag-and-drop visual interface with transformation functions and connectors | The work maps, transforms, and exchanges data between business systems with different schemas |
The two products can compose in one process. A workflow can use the Application Integration connector to trigger and wait for an integration, such as updating a Salesforce instance or running a refund flow that needs heuristic checks or human approval. For dedicated extract, transform, load or extract, load, transform data pipelines, use Cloud Data Fusion.
Exam tip: Choose Workflows to orchestrate services in a defined order, while Application Integration fits mapping data between business systems with different schemas.
Use Workflows when the work sequences loosely coupled services, pipelines, or infrastructure automation in a defined order using YAML or JSON steps and connectors. Use Application Integration when the work maps, transforms, and exchanges data between business systems with different schemas, such as Salesforce, ServiceNow, Cloud SQL, BigQuery, Spanner, and Oracle DB, using a drag-and-drop visual interface.
Eventarc routes events from more than 130 Google providers through Pub/Sub push subscriptions to Cloud Run, Cloud Run functions, Google Kubernetes Engine services, internal HTTP endpoints in a Virtual Private Cloud network, and Workflows. When Workflows is the destination, the event is transformed and passed to the workflow as runtime arguments.
Traffic distribution from a Kubernetes Service to its zone endpoints works best when incoming traffic is evenly distributed and each Kubernetes Service has three or more endpoints per zone. When traffic is uneven or a zone has fewer than three endpoints, some endpoints can receive disproportionate load while others sit underused.
Last updated