Prepare and test your skills
Prepare and test your skills
Eventarc is a Google Cloud event-routing service that carries events from a source to a destination. Eventarc (opens in a new tab) Standard is the routing layer, and an Eventarc trigger is the rule that listens for a specific event and starts work when it occurs. This model improves efficiency because processing runs only when something happens, instead of running on a fixed schedule or polling for changes. For example, a new object in Cloud Storage can start an integration flow, and a message in Pub/Sub can call a container service.
An Eventarc trigger connects an event source to an event destination through matching rules and identity. The source produces the event, Eventarc routes the event when the trigger filters match, and the destination receives the event as a request to start work. A common flow is Cloud Storage to Eventarc to Application Integration, or Pub/Sub (opens in a new tab) to Eventarc to Cloud Run. The trigger stays inactive until its configuration is deployed, and it becomes active only after the owning integration or service setup is published or created successfully.
Event sources on the left route through a central Eventarc Standard trigger with exact-match filters to five destinations on the right that start work on HTTP POST delivery.
An event source defines where an Eventarc trigger listens, and filters define which events cause it to fire. The trigger type selects the category of source, the event provider selects the specific product, and the event type selects the exact action, such as google.cloud.pubsub.topic.v1.messagePublished. Optional filters narrow the match further, for example to a specific bucket, topic, or resource name, and filtering uses exact match without wildcards or regular expressions.
Event data can use application/json or application/protobuf content types. A JSON payload is larger than a Protobuf payload, which can matter when a destination has limits on event size.
An event destination is the workload that Eventarc invokes when a matched event arrives. Supported destinations include an Application Integration flow and a Cloud Run (opens in a new tab) service, with the destination service receiving events as HTTP POST requests. In Application Integration, the Eventarc trigger element starts the integration flow, so downstream steps run automatically after the event. In Cloud Run, a Pub/Sub trigger watches one selected Pub/Sub topic, so every message published to that topic calls the selected Cloud Run service.
This pattern supports automation because one event can start transformation, integration, or serving work without manual action. A storage event can start file-driven processing, a Pub/Sub message can start per-message processing in Cloud Run, and an integration flow can then connect additional systems and steps. For Google Kubernetes Engine (GKE) (opens in a new tab) destinations, Eventarc creates an event forwarder component that pulls events from Pub/Sub and forwards them to the target GKE service.
Trigger creation collects the same core configuration whether it starts from Application Integration or from Eventarc, and both paths require activation. Before configuring a trigger, the Eventarc API and the Pub/Sub API must be enabled, which requires the serviceusage.services.enable permission through the Owner role or the Service Usage Admin role. Cloud Run Pub/Sub scenarios also use Artifact Registry, Cloud Build, Cloud Run Admin, and Cloud Logging APIs.
Saving the trigger only stores the rules in the trigger definition. The trigger remains inactive until the integration is published, so publishing is the step that deploys the rules and starts event delivery.
| Creation starting point | What is selected first | What happens next |
|---|---|---|
| Application Integration | Existing or new integration, then Eventarc trigger element | Configure trigger fields in the integration editor, connect the flow, then publish |
| Eventarc console | Trigger name, type, provider, event type, and destination | Open the selected integration, verify the added trigger element, connect the flow, then publish |
Secure execution in Eventarc depends on the trigger service account, required permissions, and network path. The service account associated with the trigger is the identity Eventarc uses when invoking the destination, so that account must have permission to invoke the destination. For Cloud Run, the trigger identity needs the Cloud Run Invoker role, and if no account is selected, Eventarc uses the Compute Engine default service account. A network attachment can connect a service-producer Virtual Private Cloud (VPC) network to a consumer VPC network so Eventarc can deliver event data to an internal HTTP endpoint in the consumer VPC.
Region placement and retry behavior affect latency and resilience. For best performance and lower latency, the Eventarc trigger, the monitored resource, and the destination service should be in the same Google Cloud region. The Retry on failure option controls whether Eventarc retries delivery when the destination fails to process an event. Publishing a modified trigger replaces the old trigger and deletes the obsolete trigger, while publishing with an unchanged trigger reuses the existing trigger.
Exam tip: Saving an Eventarc trigger does not activate it; the integration must be published before the trigger processes events, and a failed trigger creation leaves the integration published but the trigger inactive.
Implementing Eventarc triggers for workflow automation means creating rules that start the right service automatically when an event occurs. Eventarc (opens in a new tab) automation sends an event from a source through Eventarc Standard to a destination only when filters match. For example, a new object uploaded to a Cloud Storage bucket can start an integration flow without a person starting it manually. This removes manual steps and links data transformation, stream processing, lightweight tasks, container work, and orchestration into one event-driven pipeline.
An Eventarc Standard trigger rule binds an event source to an event destination. The source produces the event, Eventarc routes the event, and the destination receives the event and runs its work. Sources can be Google services such as Pub/Sub (opens in a new tab), Cloud Storage, and Firestore, third-party providers that offer an Eventarc source, or custom event sources that publish their own events. The trigger matches on the event provider and event type, with optional filters that narrow which events qualify.
Filtering uses exact match and does not support wildcards or regular expressions, so a trigger fires only for events that exactly match its criteria. Once matched, Eventarc delivers the event payload as application/json or application/protobuf to the destination. JSON is larger than Protobuf, which matters when destinations limit event size.
Eventarc trigger setup depends on enabled APIs and a secure trigger identity. Before configuring a trigger, the Eventarc API and the Pub/Sub API must be enabled, which requires the serviceusage.services.enable permission through the Owner role or the Service Usage Admin role. Without these APIs, Eventarc cannot route events and cannot use Pub/Sub transport for delivery.
Every trigger invokes its destination using a service account identity, and that service account must have permission to invoke the destination service. If no service account is selected, the trigger uses the Compute Engine default service account, which is acceptable for testing but should be replaced in production with a dedicated service account that follows least privilege. For a Cloud Run destination, the trigger identity needs the Cloud Run Invoker role, and for pulling Pub/Sub events it may need the Pub/Sub Subscriber role.
People who create triggers and deploy destinations also need their own permissions. Documented deployer roles include:
A trigger binding defines which events to listen for and where to send them. The binding starts with a trigger name, which is the trigger ID and must start with a letter and contain up to 63 lowercase letters, numbers, or hyphens. It then specifies the trigger type, event provider, event type, optional filters, region, and destination. After the type is chosen, the event provider selects the product that emits the event and the event type selects the specific action to match.
| Trigger type | Event source | Choose when |
|---|---|---|
| Google sources | Pub/Sub, Cloud Storage, Firestore, and other Google providers | The event comes from a Google Cloud service, such as google.cloud.pubsub.topic.v1.messagePublished |
| Custom | Application-defined event source | The event comes from your own system or application |
| Third-party | Non-Google provider with an Eventarc source | The event comes from an external partner integrated with Eventarc |
Optional filters further narrow the match, such as a specific bucket, topic, or API name. For best performance and lower latency, the Eventarc trigger, the monitored resource, and the destination service should all be in the same Google Cloud region.
Eventarc routing sends a matched event to the configured event destination, which is the service that does the processing work. Documented destinations include Application Integration for integration flows and Cloud Run (opens in a new tab) for containerized services that receive events as HTTP POST requests at the root path or a configured service URL path. In a data pipeline, this same routing pattern lets different events start different kinds of work, such as Dataform transformation work, Dataflow real-time stream processing, Cloud Functions lightweight tasks, Cloud Run containerized logic, or Cloud Composer multi-step orchestration.
A common pipeline pattern uses a Pub/Sub topic as the monitored resource. Data flows from the publisher to the Pub/Sub topic, then from the topic through the Eventarc trigger to the destination service. The destination service depends on the trigger for delivery, and the trigger depends on its service account for permission to invoke that service. Two delivery options control resilience: retry on failure can be enabled so Eventarc retries if the destination fails, and a network attachment can be selected so Eventarc can reach an internal HTTP endpoint inside a consumer Virtual Private Cloud (VPC) network.
Exam tip: Saving a trigger only stores the rule; the trigger stays inactive until the integration or service configuration is published or created, so publishing is what activates delivery.
The trigger activation lifecycle moves from draft to active only after publishing. Saving the trigger configuration stores when and how Eventarc should respond, but those rules are not applied until activation. After creation, event source filters cannot be edited, so a change requires creating a new trigger and deleting the old one. It can take up to two minutes after activation for a trigger to become fully functional.
If trigger creation fails during publication because of configuration errors, the integration still publishes but the trigger stays inactive. Recovery requires unpublishing the integration, correcting the trigger configuration, checking creation status in console notifications, and republishing. This separation keeps a bad trigger from blocking the rest of the integration while ensuring no events are processed until the binding is correct.
Configure security and reliability for event-driven workflows means giving each trigger a trusted identity and deciding what happens when delivery fails. Eventarc (opens in a new tab) event data flows from the event provider, such as Pub/Sub (Publish/Subscribe), Cloud Storage, or Firestore, to the Eventarc trigger, and then the trigger invokes the destination, such as Cloud Run, Cloud Functions, or Application Integration, as an authenticated HTTP request. The destination only accepts the request when the trigger identity has permission, and the workflow only stays reliable when retries and activation are configured correctly.
The trigger service account is the Identity and Access Management (IAM) identity that Eventarc uses to call the destination service. When an event matches the trigger filters, Eventarc assumes this service account and sends the event to the destination URL, and the destination checks the service account against its IAM policy before running any code. This creates a trust boundary between the event routing plane and the compute destination, so no event can invoke Cloud Run or Cloud Functions without an authorized identity.
If no account is selected, the trigger falls back to the Compute Engine default service account, which has the email format PROJECT_NUMBER-compute@developer.gserviceaccount.com. For testing this default account is convenient, but for production a dedicated user-managed service account with minimum permissions and least privilege is strongly recommended. The iam.automaticIamGrantsForDefaultServiceAccounts organization policy constraint prevents the broad Editor role from being automatically granted to default service accounts in organizations created after May 3, 2024, so permissions must be granted explicitly.
| Service account option | When to use | Permission approach |
|---|---|---|
| Compute Engine default service account | Testing and tutorials | Reuse existing account, then add only needed invoker roles |
| User-managed service account | Production pipelines | Create a new account and grant only minimum required roles |
An IAM policy for Eventarc grants specific roles to the trigger service account so it can pull events and invoke the destination, and nothing more. The account associated with the trigger must have the required permission to invoke the service, otherwise delivery is denied even when the event matches. Access can be granted on the whole project for testing or on a single Cloud Run service for tighter control.
The roles that matter for pipelines using Cloud Run and Cloud Functions include:
roles/run.invoker): allows the trigger service account to send authenticated invocations to Cloud Run services and jobs; without it, Cloud Run rejects the request.roles/pubsub.subscriber): allows the Eventarc trigger to pull events from Pub/Sub when Pub/Sub is the transport or event source.roles/iam.serviceAccountTokenCreator): allows the Pub/Sub service agent, service-PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com, to create tokens for authenticated push delivery; it is granted by default except for service agents enabled on or before April 8, 2021.roles/serviceusage.serviceUsageAdmin): provides the serviceusage.services.enable permission needed to enable the Eventarc API and Pub/Sub API before configuring triggers.Per-service control follows least privilege because the trigger identity can invoke only the intended destination, while project-wide grants let the same identity invoke every service in the project.
Reliability in Eventarc depends on the Retry on failure setting, which controls what happens when the destination fails to process an event. When retry is enabled, which is the default behavior, Eventarc retries delivery after a failure; when the checkbox is cleared, Eventarc makes a single delivery attempt with no retries. Choosing retries keeps transient errors from losing pipeline data, while choosing a single attempt avoids duplicate processing when the destination cannot handle redelivery.
An Eventarc trigger moves through an ordered lifecycle where configuration and activation are separate. First the configuration is saved as part of the trigger definition, then the integration is published to deploy the rules, and only after publication does the trigger become active. If trigger creation fails during publication because of configuration errors, the integration still publishes but the trigger stays inactive until it is corrected and republished. Publishing a new version with a changed configuration replaces the old trigger with a new one, while publishing with the same configuration reuses the existing trigger. After creation, event source filters cannot be modified, so a new trigger must be created and the old one deleted.
Reliability also improves when the Eventarc trigger, the monitored resource, and the destination service are in the same Google Cloud region, which reduces latency. Event payload encoding matters as well: an event formatted in JSON is larger than one formatted in Protobuf, which can affect delivery when the destination has limits on event size.
Exam tip: Saving a trigger only stores its rules — you must publish the integration or finish creating the trigger before it becomes active and starts processing events.
An Eventarc trigger connects an event source to an event destination through matching rules and identity, so processing runs only when something happens instead of running on a fixed schedule or polling for changes. The source produces the event, Eventarc routes the event when the trigger filters match, and the destination receives the event as a request to start work, such as an Application Integration flow or a Cloud Run service receiving an HTTP POST request.
Saving an Eventarc trigger only stores its rules in the trigger definition and the trigger remains inactive until activation. The trigger becomes active only after the owning integration is published or the trigger creation is completed, and publishing with a changed configuration replaces the old trigger while publishing with an unchanged configuration reuses the existing trigger.
The trigger service account is the Identity and Access Management (IAM) identity that Eventarc uses to invoke the destination, and it must have permission to invoke the destination or delivery is denied even when the event matches. A Cloud Run destination requires the Cloud Run Invoker role, and if no account is selected Eventarc uses the Compute Engine default service account, which is acceptable for testing but should be replaced in production with a dedicated service account that follows least privilege.
For best performance and lower latency, the Eventarc trigger, the monitored resource, and the destination service should be in the same Google Cloud region. When Retry on failure is enabled Eventarc retries delivery after a destination failure, and when it is cleared Eventarc makes a single delivery attempt with no retries.
Your team is deploying an event-driven data pipeline in Google Cloud. An Eventarc trigger is configured to listen for state changes in Dataflow jobs and route those events to an internal, authenticated Cloud Run service for automated post-processing.
After creating the trigger, you notice that the Cloud Run service is never triggered, and the trigger logs display the following error message:
The request was not authenticated. Either allow unauthenticated invocations or set the proper Authorization header.
Which Identity and Access Management (IAM) configuration should you implement to resolve this issue securely?
Last updated