Study guide
15.1 Source Deployment, Event Receivers, and API Versions
Google Cloud Professional Cloud Developer Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam and Compute Platform Decisions
1.1 Current Exam, Sources, and Scenario Method 1.2 Cloud Run Execution and Platform Selection 1.3 GKE Modes and Compute Engine Trade-offs
2 Chapter 2: Container Engineering and API Contracts
2.1 Stateless Microservices and Multi-stage Builds 2.2 Container Hardening, Signals, and Layer Caching 2.3 REST, gRPC, and Protobuf Contracts
3 Chapter 3: gRPC Compatibility and Geographic Routing
3.1 Schema Evolution and gRPC Routing 3.2 Geography, Network Tiers, and Load Balancers 3.3 Serverless NEGs, Sessions, and Edge Controls
4 Chapter 4: API Management and Caching
4.1 API Management & Rate Limiting with Apigee and API Gateway 4.2 Memorystore and Cache Access Patterns 4.3 Cache Invalidation, Capacity, and Failover
5 Chapter 5: Messaging, Task Dispatch, and Orchestration
5.1 Event-Driven Messaging with Cloud Pub/Sub 5.2 Task Queues & Rate Throttling with Cloud Tasks 5.3 Event Routing and Service Orchestration: Eventarc & Cloud Workflows
6 Chapter 6: Resilience and Relational Availability
6.1 Designing Resilient Systems: Circuit Breaking, Retries & Failover 6.2 Cloud SQL Availability and Recovery 6.3 Connection Budgets and Spanner Consistency
7 Chapter 7: Distributed Schemas and NoSQL Data Models
7.1 Spanner Keys, Indexes, and Transactions 7.2 Firestore Data, Indexes, and Transactions 7.3 Bigtable Row Keys and Replication
8 Chapter 8: Object Storage and Application Identity
8.1 Cloud Storage Lifecycle and Signed Access 8.2 Workload Identity and Service Authentication 8.3 Secret Delivery, Rotation, and IAP
9 Chapter 9: Security, Data Integration, and Developer Credentials
9.1 Private Communication, Key Rotation, and Vulnerability Response 9.2 AlloyDB Schemas and BigQuery Ingestion 9.3 CLI Configurations, Local ADC, and Cloud Shell
10 Chapter 10: Managed Development and Automated Tests
10.1 Cloud Workstations and the Container Inner Loop 10.2 Emulating Google Cloud Services & Database Auth Proxies 10.3 Automated Testing Strategies: Unit, Integration, and Mocking
11 Chapter 11: AI Development Tools and Build Pipelines
11.1 AI Coding Assistants, Context, MCP, and Test Review 11.2 Cloud Build Workers and Step Dependencies 11.3 Builders, Substitutions, Triggers, and IAM
12 Chapter 12: Artifact Security and Admission Policies
12.1 Artifact Management and Vulnerability Scanning with Artifact Registry 12.2 Build Provenance and Admission Concepts 12.3 Attestors, Policy Enforcement, and Break-glass
13 Chapter 13: Cloud Run and GKE Deployment Configuration
13.1 Cloud Run Deployment and Scaling Configuration 13.2 Cloud Run CPU, Private Egress, and Secrets 13.3 GKE Workload Controllers and Gateway Routing
14 Chapter 14: Kubernetes Resources, Health, and Progressive Releases
14.1 GKE Resources, OOM Diagnosis, and Autoscaling 14.2 Container Health Probes, Lifecycle Hooks & Graceful Shutdown 14.3 Progressive Delivery: Traffic Splitting, Canary, and Blue/Green Rollouts
15 Chapter 15: Source/Event Deployment and Cloud API Integration
15.1 Source Deployment, Event Receivers, and API Versions 15.2 Client Libraries, Service Enablement, and ADC 15.3 API Responses, Pagination, Caches, and Retries
16 Chapter 16: Tracing, Sampling, and Monitoring
16.1 Trace Context and OpenTelemetry Export 16.2 Custom Spans, Trace Analysis, and Sampling 16.3 Application Metrics, Health Checks & Alerting with Cloud Monitoring
17 Chapter 17: Structured Logs, Routing, and Error Management
17.1 Structured Logs, Trace Correlation, and Queries 17.2 Log Routing, Export Destinations, and Exclusions 17.3 Error Reporting Formats and Regression Handling
18 Chapter 18: Profiling, Generative AI, and Assisted Troubleshooting
18.1 Cloud Profiler Types and Flame Graph Analysis 18.2 Generative AI Integration with the Google Gen AI SDK 18.3 Evidence-Based Troubleshooting with AI Assistance
15.1 Source Deployment, Event Receivers, and API Versions
Key Takeaways Explain This Topic AI
Cloud Run source deployment uses a build pipeline, image registry and runtime identity; their permissions are separate.
An Eventarc receiver processes CloudEvents, while a Pub/Sub push receiver must understand its configured wrapper format.
Acknowledge an event only after the required durable effect or durable handoff; delivery can be repeated.
A new immutable revision is not automatically a new public API version.
Use stable contracts, authenticated invocation, measured canaries and compatible schemas when introducing a new API version.
Last updated: October 2026
Source Deployment, Event Receivers, and API Versions
A developer can deploy an application without manually building a container first, but source deployment does not eliminate the build, registry, identity or runtime boundaries. The blueprint expects a working application deployment, not merely a command that uploads code. Verify the complete path from source to an invokable service and from an incoming event to a durable application result.
From Source to a Revision
With Cloud Run source deployment , Google Cloud builds source into a container using the supported build process and stores the image in Artifact Registry before deploying it. A repository Dockerfile can control the build; otherwise supported buildpacks can detect the runtime. This is not a process that runs arbitrary source files directly on the service frontend. Review the actual build logs and resulting image when dependencies or startup fail. ## Example for a prepared test project and supported source directory.
- gcloud run deploy order-api \
- -source=. \
- -region=us-central1 \
- -service-account=order-runtime@my-project.iam.gserviceaccount.com \
- -no-allow-unauthenticated
The deployer , build service account , service agent and runtime identity have different duties. Current source-deployment guidance uses Cloud Run Source Developer for the deployer, the appropriate permission to use the runtime service account, and Cloud Run Builder for the configured build account, along with required service-usage access. Do not give runtime code deployment or signing authority simply because the builder needs it. Check project policy and current default build-account selection rather than assuming the legacy Cloud Build account is always used.
A failed dependency download belongs to the build stage. A container that never binds to the configured port belongs to startup. A successfully running service that returns 403 to a caller belongs to invocation authentication/authorization or ingress, not necessarily the compiler. Inspect these stages separately. Keep application configuration and secrets outside the image and verify that the built artifact is the one actually deployed.
Configure Delivery and the Receiver Together
Eventarc can invoke a Cloud Run receiver for supported events using CloudEvents. A direct Cloud Storage finalized trigger selects the event type and bucket, uses a trigger identity authorized to invoke the service, and must meet the source/trigger/destination location rules. Verify the relevant service-agent permissions and event-provider configuration as well as the receiver's own runtime IAM. A receiver's permission to read an object does not authorize Eventarc to invoke the service.
A Pub/Sub push subscription can instead send an authenticated HTTPS request directly. Its default envelope contains message data encoded as base64 plus attributes and delivery metadata; an explicitly configured unwrapped payload has a different shape. A CloudEvent receiver should not blindly parse every Pub/Sub POST as if its raw HTTP body were the original business JSON. Select a framework/parser matching the actual transport and write a contract test with an authentic representative event shape.
When using OIDC invocation, set an audience appropriate for the Cloud Run service and grant Invoker to the delivery identity. Validate business payload fields in the application. IAM verification authenticates the caller; it does not prove an object name, tenant ID or payment amount is semantically valid. If the service uses internal ingress, verify that the delivery path qualifies under Cloud Run's documented project/perimeter and URL rules.
Durable Processing and Failure Handling
Events can be delivered more than once. Use a stable business event ID and commit the business effect plus processed receipt atomically when they share a database. Acknowledge only after that commit or after a durable handoff to the next queue. Returning success before an in-memory background task completes can lose work if the container is terminated. Returning an error after an external payment succeeded can cause duplicate payment unless the external API uses an idempotency key.
Separate transient failures from invalid messages. A temporary database outage may need retry with bounded backoff and monitoring. A permanently malformed payload needs a deliberate dead-letter/quarantine path rather than an infinite crash loop. Retain enough context to repair/replay failed events without logging secret payloads. Monitor age and retries, not only whether the service process is alive.
Cloud Scheduler is for recurring cron-like triggers. It can invoke a supported HTTP target or publish a Pub/Sub message; it is different from a one-off per-customer Cloud Tasks schedule. Select the time zone deliberately, and account for daylight-saving changes if wall-clock scheduling is required. Recurring dispatch is not exactly-once execution: make the job idempotent and use an explicit business period/key so a retry cannot repeat a monthly charge. An OIDC-protected HTTP target still needs an authorized scheduler identity and the appropriate audience. Scheduling success is not proof that downstream business processing finished.
API Versioning Is a Public Contract
An immutable Cloud Run revision identifies deployed configuration/code, while an API version identifies a consumer contract. A new revision can implement the same /v1/orders API with a bug fix. A breaking field or behavior change might require /v2/orders or another explicit versioning strategy. Route versions through API Gateway, Apigee or the application as appropriate; versioning is not achieved by renaming a container tag alone.
Keep authentication and authorization requirements consistent across versions unless an intentional reviewed change requires otherwise. For an API Gateway config, deploy a new immutable config and update the gateway deliberately. For Apigee, distinguish proxy revisions/deployment environments from the externally exposed API version and product access rules. Continue to validate the backend's business input; a gateway definition does not automatically enforce every payload constraint.
Before shifting production traffic, test old and new clients, schema compatibility, event receiver formats and downstream effects. Use a tagged candidate revision for authorized tests and then a measured canary where suitable. An A/B experiment needs a defined cohort and business measurement; random routing weights alone do not guarantee the same user stays in the same cohort. Roll back traffic if the candidate is unhealthy, while accounting for any persisted data changes that routing cannot undo.
Sources checked October 18, 2026: Cloud Run source deployment , deployment IAM , Eventarc documentation , Cloud Scheduler documentation .
Deployment Verification Checklist
- Boundary Evidence to inspect Common mismatch
- Source build Build result and stored image digest Successful upload but failed dependency installation
- Runtime startup Ready revision, port binding and startup logs Image exists but process never listens
Event invocation Delivery identity, audience, ingress and receiver format Valid event sent to an unauthorized or incompatible receiver
Business completion Committed effect/receipt or durable handoff Success response before required work survives termination