8.1 Deploying Applications to Cloud Run and Cloud Functions

Why This Sub-Domain Matters

Domain 3, Deploying and implementing a cloud solution, carries the single heaviest weight on the Associate Cloud Engineer (ACE) exam at 25% — a quarter of every 50-60 question exam form touches this domain. Inside it, official sub-topic 3.3, "Deploying and implementing Cloud Run and Cloud Functions resources," is tested almost entirely through scenario questions: a team describes an application (a stateless web API, a single-purpose image resizer, a long-running batch job) and you must pick the correct compute product and the correct gcloud invocation to deploy it. Getting the decision framework wrong — for example, reaching for a full container platform when a single function would do, or vice versa — is one of the most common wrong-answer patterns on the real exam.

Core Services and Terminology

Three closely related but distinct products live under this sub-topic:

• Cloud Run — a fully managed serverless platform for running stateless HTTP containers. It scales automatically, including down to zero instances when idle, and you pay only while a container instance is actively handling requests (plus any configured minimum instances).
• Cloud Run functions (the current, 2024-rebranded name for what the industry and many older exam materials still call Cloud Functions) — a lightweight, single-purpose, event-triggered or HTTP-triggered function service. Google folded Cloud Functions under the Cloud Run brand so that both products share the same underlying infrastructure and feature set. The exam guide's own wording ("Cloud Functions") predates the rebrand, so expect to see both names used interchangeably on the real exam and in the console.
• Cloud Run for Anthos — the legacy name for running the open-source Knative serving API on a GKE (Google Kubernetes Engine) cluster you manage yourself. Google has since archived the "Cloud Run for Anthos" branding in favor of "Knative serving" running on GKE Enterprise (formerly Anthos) fleets. It still appears as an option in the official exam guide's wording ("Cloud Run, Cloud Run for Anthos, or Cloud Functions"), so know it as the answer when a scenario requires cluster-level control (custom nodes, GPUs, no scale-to-zero requirement, integration with other workloads already running on the same GKE cluster).

Cloud Run Functions: 1st Gen vs. 2nd Gen

Cloud Functions/Cloud Run functions ship in two generations with materially different limits — a frequent source of exam trap questions:

The practical exam takeaway: if a scenario needs more than 9 minutes of processing, more than one concurrent request per instance, or an unusual event source, the answer is 2nd gen, deployed with the --gen2 flag.

Deploying to Cloud Run

The baseline deployment command is:

gcloud run deploy SERVICE_NAME --image=IMAGE_URL --region=REGION

Key mechanics you must know cold for the exam:

• Source-based deploys. Omit --image and point gcloud run deploy at a source directory instead — Cloud Run automatically builds a container using Buildpacks (via Cloud Build) with no Dockerfile required. This is a common exam trap: candidates assume a Dockerfile is mandatory for Cloud Run, but it is not.
• Revisions are immutable. Every deployment creates a new, immutable revision. When you deploy an image referenced by a mutable tag, Cloud Run resolves it to an immutable digest at deploy time, so a given revision always serves that exact digest even if the tag is later repointed.
• Traffic splitting. You can send 100% of traffic to the newest revision immediately, or hold it back ("no traffic sent to the new revision") for a gradual, percentage-based rollout — the mechanism behind canary deployments and blue/green rollouts on Cloud Run.
• Concurrency. The maximum concurrent requests a single instance will accept is configurable. Services created through the Console default to 80; services created via CLI/Terraform default to 80 × number of configured vCPUs. The hard ceiling either way is 1,000 concurrent requests per instance.
• Request timeout. Configurable up to 60 minutes for HTTP requests.
• Autoscaling. Minimum instances default to 0 (true scale-to-zero, cheapest, but introduces cold starts); raising it keeps warm instances running to eliminate cold-start latency at a cost. Maximum instances defaults to 100 per revision — Google explicitly recommends starting with a low cap (as low as 3) during testing to protect against runaway cost from unexpected traffic spikes, and setting the cap at the service level (not per revision) once multiple revisions may be splitting traffic.
• Authentication. --allow-unauthenticated exposes a public endpoint; --no-allow-unauthenticated requires callers to hold the roles/run.invoker IAM role — the default and recommended posture for internal or event-driven services.

Decision Framework

Exam Scenario

A team has containerized a Python Flask API that must autoscale from zero during quiet nights to hundreds of instances during a flash sale, and one endpoint occasionally runs a 45-minute nightly export job. There is no existing GKE cluster. The correct answer is Cloud Run, because Cloud Run functions' HTTP timeout tops out at 60 minutes only in 2nd gen and per-instance request handling for a full multi-route API is a poor fit for single-purpose functions; standing up GKE purely for this workload adds unnecessary operational overhead the scenario doesn't call for.

A second team needs a small piece of code that resizes an image the instant it lands in a Cloud Storage bucket, with no other responsibilities. The correct answer is Cloud Run functions (2nd gen) with a Cloud Storage-triggered Eventarc binding — exactly the pairing covered in the next section.