Study guide
8.1 Deploying Applications to Cloud Run and Cloud Functions
Google Cloud Associate Cloud Engineer ACE
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Introduction & Exam Overview
1.1 About the GCP Associate Cloud Engineer Exam 1.2 How to Use This Study Guide & Build a Study Plan
2 Chapter 2: Resource Hierarchy, IAM Basics & Cloud Identity
2.1 The GCP Resource Hierarchy: Organizations, Folders & Projects 2.2 Organization Policies & Granting IAM Roles 2.3 Cloud Identity: Managing Users and Groups
3 Chapter 3: APIs, Quotas & Billing Configuration
3.1 Enabling APIs and Provisioning Cloud Operations Suite 3.2 Assessing and Requesting Quota Increases 3.3 Billing Accounts, Project Linking & Billing Exports 3.4 Billing Budgets and Alerts
4 Chapter 4: Planning Compute & Storage Resources
4.1 Choosing the Right Compute Option: GCE vs. GKE vs. Cloud Run vs. Cloud Functions 4.2 Spot VMs, Custom Machine Types & Cost-Optimized Compute Planning 4.3 Choosing a Data Storage Product: Cloud SQL, BigQuery, Firestore, Spanner & Bigtable 4.4 Cloud Storage Classes & Persistent Disk Types
5 Chapter 5: Planning Network Resources
5.1 Load Balancing Options and Use Cases 5.2 Regional Resource Placement & High Availability Planning 5.3 Network Service Tiers: Premium vs. Standard
6 Chapter 6: Deploying Compute Engine Workloads
6.1 Launching Compute Engine Instances: Disks, SSH Keys & Availability Policies 6.2 Managed Instance Groups, Instance Templates & Autoscaling 6.3 OS Login and VM Manager for Fleet Configuration
7 Chapter 7: Deploying Google Kubernetes Engine Workloads
7.1 Installing and Configuring kubectl 7.2 Deploying GKE Clusters: Autopilot, Regional, Private & GKE Enterprise 7.3 Deploying Containerized Applications to GKE
8 Chapter 8: Deploying Serverless & Event-Driven Applications
8.1 Deploying Applications to Cloud Run and Cloud Functions 8.2 Event-Driven Architectures: Pub/Sub, Cloud Storage Triggers & Eventarc
9 Chapter 9: Deploying Data Solutions
9.1 Deploying Data Products: Cloud SQL, Firestore, Spanner, BigQuery & AlloyDB 9.2 Deploying Pub/Sub, Dataflow & Loading Data into Google Cloud
10 Chapter 10: Deploying Networking Resources & Infrastructure as Code
10.1 Creating VPCs, Subnets & Shared VPC 10.2 Firewall Rules, Cloud VPN & VPC Network Peering 10.3 Infrastructure as Code: Terraform, Config Connector, Cloud Foundation Toolkit & Helm
11 Chapter 11: Managing Compute Engine & GKE in Production
11.1 Connecting to and Managing Running Compute Engine Instances 11.2 Working with Snapshots and Custom Images 11.3 Managing GKE Clusters: Node Pools, Workloads & Artifact Registry Access 11.4 Horizontal and Vertical Pod Autoscaling in GKE
12 Chapter 12: Managing Cloud Run, Storage & Database Operations
12.1 Managing Cloud Run Revisions, Traffic Splitting & Scaling 12.2 Managing and Securing Cloud Storage Objects & Lifecycle Policies 12.3 Querying, Estimating Costs, Backup & Job Monitoring for Databases (Cloud SQL, BigQuery, Spanner, Dataflow)
13 Chapter 13: Networking Operations, Monitoring & Logging
13.1 Networking Operations: Subnets, Static IPs, Cloud DNS & Cloud NAT 13.2 Cloud Monitoring: Alerts, Custom Metrics & Dashboards 13.3 Cloud Logging: Buckets, Log Analytics, Routers & Filtering 13.4 Diagnostics, Ops Agent, Managed Service for Prometheus & Audit Logs
14 Chapter 14: IAM Policies & Role Types
14.1 IAM Policies: Structure, Bindings & Policy Hierarchy 14.2 IAM Role Types: Basic, Predefined & Custom Roles
15 Chapter 15: Service Accounts & Security Configuration
15.1 Creating Service Accounts & Assigning Least-Privilege Permissions 15.2 Assigning Service Accounts to Resources & Managing SA IAM Policies 15.3 Service Account Impersonation & Short-Lived Credentials
16 Chapter 16: Exam Readiness — Scenarios & Test-Day Strategy
16.1 Common ACE Exam Scenarios & Decision Frameworks 16.2 Test-Day Logistics, Time Management & Final Review Checklist
8.1 Deploying Applications to Cloud Run and Cloud Functions
Key Takeaways Explain This Topic AI
Domain 3 (Deploying and implementing a cloud solution) is 25% of the ACE exam, the single largest domain, and sub-topic 3.3 tests Cloud Run vs. Cloud Run functions (Cloud Functions) vs. GKE/Knative serving deployment decisions.
Cloud Run functions 1st gen caps execution at 9 minutes with 1 concurrent request per instance; 2nd gen reaches 60 minutes (HTTP), 16 GiB RAM/4 vCPU, and 1,000 concurrent requests per instance.
Cloud Run supports source-based deploys with no Dockerfile (Buildpacks via Cloud Build), immutable revisions, and traffic-split rollouts.
Cloud Run concurrency defaults to 80 (Console) or 80x vCPU count (CLI/Terraform) and can be raised to a hard ceiling of 1,000; maximum instances defaults to 100 per revision.
"Cloud Run for Anthos" is the legacy name for Knative serving on a self-managed GKE cluster — pick it only when the scenario needs cluster-level control, not scale-to-zero simplicity.
Last updated: July 2026
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:
- Characteristic 1st Gen 2nd Gen
- Max execution timeout 9 minutes (all triggers) 60 minutes (HTTP-triggered), 9 minutes (event-triggered)
- Max memory / CPU 8 GiB RAM / 2 vCPU 16 GiB RAM / 4 vCPU
- Concurrency per instance 1 request Up to 1,000 requests
Event source coverage 7 built-in event sources Any Eventarc-supported source — 90+ event types via Cloud Audit Logs
Underlying infrastructure Google's internal function runtime Runs as a Cloud Run service under the hood
CloudEvents support Ruby, .NET, PHP only (others need "Background functions") All runtimes support CloudEvents uniformly
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
If the scenario needs… Choose
A stateless container, full control over runtime/multiple processes, long-running requests up to 60 minutes, scale-to-zero Cloud Run
A small, single-purpose piece of code bound directly to one event trigger with minimal boilerplate Cloud Run functions (Cloud Functions)
Deep Kubernetes integration, custom nodes/GPUs, or the workload must share a cluster with other GKE-managed services GKE / Knative serving (legacy "Cloud Run for Anthos")
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.