Eventarc Study Notes

Eventarc is a fully managed event routing service that delivers events from Google Cloud services, custom sources, and supported third parties to event receivers. It uses the CloudEvents standard format, so events carry a consistent structure regardless of their source. Receivers such as Cloud Run, Cloud Functions, and Workflows can then react without custom polling code.

Key facts

• An Eventarc trigger defines which events to route, based on source and event type filters, and which destination service should receive matching events.
• Events are delivered in CloudEvents format, a vendor-neutral specification that includes attributes such as id, source, type, subject, and time alongside the event data.
• Many Google Cloud sources produce events through audit logs or Pub/Sub, and Eventarc can use those paths to react to changes such as a file uploaded to Cloud Storage.
• Supported destinations include Cloud Run services, Cloud Functions second generation, Google Kubernetes Engine services, Workflows, and Pub/Sub topics in supported configurations.
• Eventarc is regional or global depending on the source and trigger type, and the trigger location must align with the location of the event source where required.
• Delivery is at least once, so receiving services should be idempotent and able to handle the same event being delivered more than one time safely.
• Eventarc uses service accounts to deliver events, and the service account needs permission to invoke the destination, such as the Cloud Run Invoker role.
• Custom events can be published through Eventarc channels and providers, letting applications emit their own events in CloudEvents format for other services to consume.
• Triggers can filter on event attributes, which reduces unnecessary invocations by delivering only events that match the specified type, bucket, or other criteria.

What the exam expects you to know

• The exam tests Eventarc as the glue for event-driven architectures: a change in one Google Cloud service triggers a Cloud Run service, function, or workflow automatically.
• Know the CloudEvents standard as Eventarc's format and why a common format makes it easier to process events from many different sources uniformly.
• Expect questions on triggers: source, event type, filters, location, and destination, and how a misaligned region can prevent a trigger from firing.
• Candidates should understand that Eventarc routes events but does not process them itself; the destination service contains the business logic.
• Understand the service account and invoke permissions needed for delivery, a common cause of events not reaching a private Cloud Run service.
• Questions may contrast Eventarc with writing polling code or wiring every source directly to Pub/Sub topics manually for each consumer.

Eventarc vs Pub/Sub: when to use which

Choose Eventarc when you want managed routing of events from Google Cloud services and supported SaaS sources directly to a receiver, with filtering on event type and no consumer code to manage subscriptions. Choose Pub/Sub when you need a durable message topic that multiple subscribers pull at their own pace, with buffering, replay within retention, and fan-out you control. Eventarc often uses Pub/Sub as its transport behind the scenes, but it hides that plumbing. Exam clue: react automatically to a Cloud Storage upload or audit log event points to Eventarc. See also the Pub/Sub notes.

Useful gcloud commands

gcloud eventarc triggers list --location=us-central1
gcloud eventarc triggers describe my-trigger --location=us-central1

Common exam traps

• Eventarc delivery is at least once, not exactly once, so a receiver that creates records or charges on every delivery must deduplicate events itself.
• A trigger in the wrong location for its source can silently receive nothing, because many sources are regional and the trigger must match that location.
• Eventarc does not replace Pub/Sub for high-volume streaming ingestion pipelines; it is an event routing layer, not a streaming data backbone.
• The destination must be able to accept CloudEvents over HTTP and return success promptly, or deliveries will retry and may be mistaken for application errors.

Frequently asked questions

What kinds of events can Eventarc handle?

Eventarc handles events from many Google Cloud services, such as Cloud Storage object changes, Pub/Sub messages, Firestore updates, and audit log entries for resource changes, as well as events from supported third-party providers and custom application events. All are normalised into CloudEvents format before delivery to the configured destination service for processing.

How does Eventarc deliver an event to Cloud Run?

You create a trigger that matches a source and event type and points to a Cloud Run service. When a matching event occurs, Eventarc sends an HTTP POST containing the CloudEvent to the service, using a service account with permission to invoke it. The service processes the event and returns a success status to complete delivery.

Does Eventarc guarantee an event is handled only once?

No. Eventarc provides at-least-once delivery, which means a network issue or a slow receiver can cause the same event to be delivered again. Design receivers to be idempotent by using the event id or a business key to detect duplicates, so repeated delivery does not create duplicate records, notifications, or side effects in downstream systems.

Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.