Cloud Run and Cloud Functions

What you will be able to do

• Explain the five core cloud decisions involved in cloud run and cloud functions.
• Choose a cloud resource or configuration that matches a stated workload requirement.
• Interpret provider state, workload behavior, and operational evidence before changing broader cloud state.
• Apply an inventory, select, configure, verify, recover, and document workflow to a realistic cloud decision.

01

Build the Cloud Decision Map

Choose Cloud Run services, jobs, or functions by matching request, event, and batch execution with identity, revisions, scaling, and evidence.

Cloud services combine provider-managed layers with customer-controlled configuration. A useful design keeps workload need, resource scope, identity, network path, data, health, cost, and recovery visible instead of relying on a product name.

Start with an inventory and read-only evidence. Record the account or project, location, resource identifier, owner, configuration source, dependencies, expected behavior, and current observation before changing state.

02

Cloud Run service

A Cloud Run service exposes a managed HTTPS endpoint and runs stateless container instances that scale with demand. It answers one distinct architecture or operating question within cloud run and cloud functions.

Choose a service for request-driven applications and APIs with a compatible container runtime. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Do not rely on local instance storage as durable application state. The expected evidence is the deployed revision serves the expected authenticated or public endpoint.

03

Cloud Run job

A Cloud Run job runs one or more container tasks to completion without serving requests. It answers one distinct architecture or operating question within cloud run and cloud functions.

Choose a job for bounded batch or scheduled work with explicit completion and retry behavior. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Do not deploy a finite batch task as a permanently listening service. The expected evidence is the execution records task completion and a deterministic result.

04

Cloud Run function

A Cloud Run function deploys single-purpose source code that responds to supported HTTP or event triggers. It answers one distinct architecture or operating question within cloud run and cloud functions.

Define event schema, idempotency, retry, timeout, and failure handling before deployment. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Do not assume an event is delivered exactly once. The expected evidence is repeated delivery produces one safe business outcome.

05

Service identity

A Cloud Run workload uses a service account identity to call authorized Google Cloud APIs. It answers one distinct architecture or operating question within cloud run and cloud functions.

Use a dedicated service account with the minimum required roles. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Do not use broad default credentials or export long-lived keys into the container. The expected evidence is required api calls succeed and excess access is denied.

06

Revision evidence

Cloud Run evidence joins revision, configuration, traffic allocation, request logs, metrics, traces, and dependency outcomes. It answers one distinct architecture or operating question within cloud run and cloud functions.

Trace one request, task, or event to its exact revision and result. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Stop when logs would expose tokens, secrets, or protected payload fields. The expected evidence is the outcome maps to a revision, identity, and dependency path.

07

Verify One Cloud Change

Before changing cloud state, name the exact resource, required authorization, user impact, expected signal, cost effect, and recovery path. Preview the scope with an inventory or policy view and protect data or configuration that cannot be recreated safely.

Make one narrow change and stop. If the provider response, location, identity, dependency, or effective configuration differs from the plan, preserve that evidence and reassess instead of adding unrelated changes.

A successful API response or portal notification proves only that an operation was accepted. Repeat the original workload path, inspect health and security signals, verify the resulting resource state independently, and remove temporary access or test resources.

08

Recap Before Practice and Prove

Start with cloud run service. Choose a service for request-driven applications and APIs with a compatible container runtime. Confirm that the deployed revision serves the expected authenticated or public endpoint.

Keep cloud run job separate. Choose a job for bounded batch or scheduled work with explicit completion and retry behavior. Respect this boundary: do not deploy a finite batch task as a permanently listening service.

Use cloud run function as its own decision. Define event schema, idempotency, retry, timeout, and failure handling before deployment. Preserve the resulting evidence.

Before a broader change, review service identity. Use a dedicated service account with the minimum required roles. Stop when do not use broad default credentials or export long-lived keys into the container.

Finish with revision evidence. Trace one request, task, or event to its exact revision and result. Record the final state, health signal, recovery boundary, owner, and next decision.