Topic 5 of 11
Cloud Run, Cloud Run functions, and Eventarc
The exam guide asks you to deploy applications to serverless platforms, including processing Google Cloud events: Pub/Sub events, Cloud Storage object change notifications, and Eventarc. This article covers how to deploy and how to wire up events; revisions, traffic splitting, and scaling are in domain D3.
Contents
Deploying to Cloud Run
From an image
The image is stored in Artifact Registry (or Docker Hub) and deployed by its URL.
From source code
With --source, Cloud Run builds the container with Cloud Build and stores it in Artifact Registry.
# From an image gcloud run deploy my-service --image us-docker.pkg.dev/PROJECT/repo/app:1.0 --region us-central1 # From source code gcloud run deploy my-service --source . --region us-central1
- Each deployment creates a new, immutable revision.
- The container must listen on a TCP port and handle HTTP requests.
- A service can have several containers (sidecars) with
--container; only one receives ingress traffic. - Typical roles to deploy: Cloud Run Admin and Service Account User on the service account it runs as.
Who can invoke the service
Invoking a service requires the Cloud Run Invoker role (roles/run.invoker). By default, only authorized principals can call it.
Public service
Deploy with --allow-unauthenticated, which grants roles/run.invoker to allUsers. For public websites and APIs.
Private service
Grant roles/run.invoker only to the accounts that must call it, for example the service account of a push subscription or a trigger.
The "Restrict identities by domain" organization policy can prevent adding allUsers.
Ingress: where traffic comes from
IAM access decides who; ingress decides from which network requests are accepted.
| Setting | What it allows |
|---|---|
| All | The least restrictive: everything, including direct internet requests to the run.app URL |
| Internal | The most restrictive: internal Application Load Balancer, VPC networks in the same project, the configured Shared VPC, resources inside the VPC Service Controls perimeter, and certain Google Cloud products in the same project |
| Internal and Cloud Load Balancing | The above plus the external Application Load Balancer. Direct internet requests to run.app are blocked, so everything goes through IAP, Cloud Armor, or Cloud CDN |
Deploying Cloud Run functions
A function is deployed to Cloud Run from source code, specifying the entry point and the runtime base image.
gcloud run deploy my-function --source . \ --function FUNCTION_ENTRYPOINT --base-image python314 --region europe-west1
--function: the function name or fully qualified class that runs.--base-image: the runtime environment, such asnodejs24,python314,go127,java25,dotnet10,ruby40, orphp85.- HTTP functions: respond on the service's HTTPS endpoint, ideal for webhooks.
- Event-driven functions: all use Eventarc triggers to receive events.
- For backward compatibility,
gcloud functions deploy, the Cloud Functions v2 API, and the Terraformgoogle_cloudfunctions2_functionresource still exist.
Eventarc
A serverless, fully managed service to route events asynchronously from a source to a destination, handling delivery, security, authorization, observability, and errors.
- An event is a record that something happened: a database change, a new file, a scheduled job.
- Providers: more than 130 from Google, which send events directly (for example, Cloud Storage or Pub/Sub) or through Cloud Audit Logs entries.
- Google events use Pub/Sub as the transport and reach the destination in CloudEvents format.
- Destinations: Cloud Run (services and functions), Workflows, GKE, and internal HTTP endpoints in a VPC (the last two in preview).
- At-least-once delivery, no ordering guarantee, with retries for 24 hours by default.
Eventarc Standard and Advanced
| Standard | Advanced | |
|---|---|---|
| What for | Deliver events from a provider to a destination with triggers | A central bus where events are published and services subscribe with enrollments |
| Routing | Provider to destination | Many providers to many destinations |
| Filtering | By event type and specific attributes | By any attribute |
| Transformation | No | Yes, with CEL expressions, plus schema conversion |
| Cross-project | No | Yes |
| Dead letter queue | Yes, through a Pub/Sub dead letter topic | No |
| Max event size | 512 KB | 1 MB |
| Limits | 500 triggers per project and region | One bus and 100 pipelines per project and region |
Both use the same data model, so you can move from Standard to Advanced as the use case grows more complex.
Creating an Eventarc trigger
A trigger filters events by source, type, and attributes and sends them to the destination. In the console: Cloud Run → service → Triggers tab → Add trigger.
gcloud eventarc triggers create storage-trigger --location=us-central1 \ --destination-run-service=my-service --destination-run-region=us-central1 \ --event-filters="type=google.cloud.storage.object.v1.finalized" \ --event-filters="bucket=my-bucket" \ --service-account=trigger-sa@PROJECT_ID.iam.gserviceaccount.com
| Event type | When |
|---|---|
google.cloud.storage.object.v1.finalized | Direct event: an object is created in a bucket |
google.cloud.pubsub.topic.v1.messagePublished | A message is published to a topic (existing or created by Eventarc) |
google.cloud.audit.log.v1.written | An audit log entry matching the filter is written, e.g. creating a VM |
- Location: that of the resource you monitor; the Cloud Run service usually goes in the same region.
- Identity: the trigger uses a service account. If you don't specify one, it uses the Compute Engine default service account, which may have excessive permissions. Google recommends a user-managed account with minimal permissions.
- Events reach the service as HTTP requests.
Pub/Sub events: push subscription
Besides Eventarc, a Cloud Run service can receive a topic's messages through a push subscription that makes an HTTP request to the service for each message.
gcloud iam service-accounts create cloud-run-pubsub-invoker gcloud run services add-iam-policy-binding pubsub-tutorial \ --member=serviceAccount:cloud-run-pubsub-invoker@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/run.invoker gcloud pubsub subscriptions create myRunSubscription --topic myRunTopic \ --ack-deadline=600 --push-endpoint=SERVICE-URL/ \ --push-auth-service-account=cloud-run-pubsub-invoker@PROJECT_ID.iam.gserviceaccount.com
The service can stay private: the subscription authenticates with a service account that has roles/run.invoker.
Cloud Storage change notifications
Pub/Sub notifications for Cloud Storage publish a message to a topic with the event and the affected object. The more direct alternative, if you don't want to manage a topic, is a Cloud Run function with a Cloud Storage trigger (the bucket must be in the same project).
| Event | When it is sent |
|---|---|
OBJECT_FINALIZE | An object or new generation is created (including copy, rewrite, or restore). A failed upload doesn't trigger it |
OBJECT_METADATA_UPDATE | An existing object's metadata changes |
OBJECT_DELETE | An object is permanently deleted (including by lifecycle rules) |
OBJECT_ARCHIVE | Only with versioning: the live version becomes noncurrent |
OBJECT_INITIALIZE | An object starts being created in a zonal bucket |
- Up to 100 notification configurations per bucket and 10 for the same event.
- At-least-once delivery: the same event can arrive several times with different IDs.
- For other events, such as object reads or bucket operations, turn on audit logs and route them to Pub/Sub.
Exam scenarios
| Situation | Answer | Why |
|---|---|---|
| Publish a website on Cloud Run that anyone can reach | --allow-unauthenticated (allUsers with run.invoker) | Without it, only authorized principals can invoke. |
| The service must accept internet traffic only through a load balancer with Cloud Armor | "Internal and Cloud Load Balancing" ingress | Blocks direct requests to run.app. |
| Run code every time an object is uploaded to a bucket | Eventarc trigger with google.cloud.storage.object.v1.finalized | A direct Cloud Storage event. |
| React when someone creates a VM | Eventarc trigger on Cloud Audit Logs | Audit events cover API operations. |
| Process messages from an existing topic in a Cloud Run service | Push subscription with an authenticated service account | Pub/Sub delivers over HTTP to the service. |
| Route events from many sources to many destinations and transform them | Eventarc Advanced | Central bus, filtering, and CEL transformation. |
| Deploy a Python function from source code | gcloud run deploy --source . --function | Cloud Run builds the image. |
Common exam traps
❓ Which role does an account need to invoke a private Cloud Run service?
Cloud Run Invoker (roles/run.invoker).
❓ Which identity does an Eventarc trigger use if you don't specify one?
The Compute Engine default service account. Google recommends a user-managed account with minimal permissions.
❓ Does Eventarc guarantee event order?
No. Delivery is at least once with no FIFO guarantee.
❓ Which Eventarc edition supports transforming events and cross-project delivery?
Eventarc Advanced.
❓ Is OBJECT_FINALIZE sent when an upload fails?
No. Only when the object is created successfully.
❓ How do you detect that someone reads an object in a bucket?
Pub/Sub notifications don't cover reads: turn on Data Access audit logs and route them.
Did you get this topic?
Test what you just learned
Every time a PDF invoice is uploaded to a bucket, a private Cloud Run service must process it. The security team requires the service not to be public and an identity with minimal permissions to be used. What should you configure?
Ready to test "Cloud Run, Cloud Run functions, and Eventarc"?
Original questions, each with a full explanation.
Start a mock exam