8.2 Event-Driven Architectures: Pub/Sub, Cloud Storage Triggers & Eventarc

Why This Sub-Domain Matters

The official ACE exam guide lists "Deploying an application for receiving Google Cloud events (e.g., Pub/Sub events, Cloud Storage object change notification events, Eventarc)" as its own explicit bullet under sub-topic 3.3, and Pub/Sub reappears again in sub-topic 3.4 as one of the named data products you must know how to deploy and load data into. Event-driven deployment is therefore tested from two angles: knowing which event source is firing, and knowing the plumbing that connects that source to your Cloud Run service or Cloud Run function. Because this pairs directly with the compute choices from the previous section, expect combined scenario questions that require both the right compute target and the right trigger mechanism in the same answer.

Cloud Pub/Sub Fundamentals

Pub/Sub is Google Cloud's fully managed, asynchronous messaging service built around two core objects:

• A topic is the named channel a publisher sends messages to.
• A subscription attaches to a topic and represents a stream of messages a subscriber consumes. Multiple subscriptions on one topic implement a fan-out pattern — every subscription gets its own independent copy of each message.

Subscriptions deliver messages one of two ways:

Pub/Sub guarantees at-least-once delivery — a subscriber may occasionally see a duplicate message and must be built to handle that (idempotent processing). Key configurable numbers:

• Message retention: default 7 days; configurable down to a minimum of 10 minutes or up to a maximum of 31 days — and this applies to both topics (for replay/seek) and subscriptions (for unacknowledged messages).
• Messages can carry an ordering key to guarantee delivery order for messages sharing that key.
• A dead-letter topic can be configured on a subscription so that messages exceeding a maximum delivery-attempt count are routed aside for inspection instead of being retried forever.

Cloud Storage Object Change Notifications

Cloud Storage can fire a Pub/Sub notification whenever an object changes state in a bucket. The event types you need to recognize:

• OBJECT_FINALIZE — a new object (or new generation of an existing object) is successfully written. This is the event most "process this file the moment it lands" pipelines trigger on.
• OBJECT_DELETE — an object is permanently deleted.
• OBJECT_ARCHIVE — only fires when a bucket has object versioning enabled; marks the moment a live object version becomes non-current.
• OBJECT_METADATA_UPDATE — object metadata changes without the object's data changing.
• OBJECT_INITIALIZE — fires when object creation begins, specific to zonal buckets.

A single bucket supports up to 100 total notification configurations, with a cap of 10 configurations per individual event type. These are created directly against Cloud Storage with a command such as gcloud storage buckets notifications create gs://BUCKET --topic=TOPIC --event-types=OBJECT_FINALIZE.

Eventarc: The Unified Event Router

Eventarc is the managed platform that routes events from a source to a destination "without having to implement, customize, or maintain the underlying infrastructure." It recognizes three categories of event source:

1. Direct events — native events emitted straight from a Google Cloud service (for example, a Pub/Sub message being published, or a Cloud Storage object being finalized).
2. Audit Log events — events derived from Cloud Audit Logs, giving Eventarc visibility into 90+ additional API-call-level event types beyond the direct sources.
3. Third-party events — events from external SaaS and custom application sources (Eventarc Standard only).

Eventarc delivers every event in the standardized CloudEvents format, with at-least-once delivery and automatic retry with exponential backoff over a default 24-hour retention window for events that can't yet be delivered. Supported destinations differ by edition:

Wiring a Pub/Sub-Triggered Cloud Run Service

Because Cloud Run itself has no native "trigger" concept, Pub/Sub-to-Cloud-Run integration goes through Eventarc:

• The event filter is type=google.cloud.pubsub.topic.v1.messagePublished.
• The trigger's service account identity needs the roles/eventarc.eventReceiver role (to receive the event) and roles/run.invoker (to actually invoke the target Cloud Run service).
• The account performing the deployment (not the trigger identity) separately needs Cloud Build Editor, Cloud Run Admin, Eventarc Admin, Service Account Admin/User, and Project IAM Admin — a broader set of roles than the trigger identity itself needs.
• By default, Cloud Run uses the Compute Engine default service account (PROJECT_NUMBER-compute@developer.gserviceaccount.com) unless a dedicated service account is specified.
• Newly created triggers can take up to two minutes to become fully active — a detail that explains "my trigger isn't firing yet" scenario questions.

Exam Scenarios

Scenario 1 — Fan-out order processing. An e-commerce order service publishes an OrderCreated message to a single Pub/Sub topic. Three independent services — inventory, billing, and customer notifications — each need their own copy of every order event, and each must be able to fall behind or fail without affecting the others. The correct design is one topic with three separate subscriptions, one per consumer, not three publishers or a single shared subscription (which would let only one consumer receive each message).

Scenario 2 — Image pipeline with a missing role. A team configures an Eventarc trigger so that uploads to a Cloud Storage bucket (OBJECT_FINALIZE) invoke a Cloud Run function that generates a thumbnail. The trigger shows as created, but the function never runs and Cloud Logging shows permission-denied errors. The most likely root cause: the trigger's service account is missing roles/eventarc.eventReceiver and/or roles/run.invoker — a classic, testable ACE trap, since the trigger object itself can exist and appear healthy while IAM is still misconfigured.

Scenario 3 — Retention and replay. A subscriber service is down for 20 hours during a maintenance window. Because Pub/Sub's default message retention is 7 days (far longer than the 20-hour outage), no messages are lost — they simply queue up and are delivered once the subscriber reconnects, as long as retention was not shortened below the outage window.