This chapter covers Cloud Functions in both 1st and 2nd generation on Google Cloud, a core compute service for event-driven applications. For the ACE exam, questions on Cloud Functions appear in roughly 5-8% of the exam, focusing on deployment, triggers, scaling, and differences between generations. Understanding the nuances of each generation — including cold starts, concurrency, and integration with Eventarc — is critical for passing the 'Deploy and Implement' domain. This chapter provides the deep technical knowledge needed to answer these questions correctly.
Jump to a section
Imagine a buffet line at a large conference. You (the client) walk up with a specific request: a plate of spaghetti with marinara sauce (an HTTP request to a function). The buffet has two sections: the 1st Gen station is a classic hot plate with a fixed number of serving trays. Each tray (container) holds a specific dish (function). When a guest arrives, a host (the 1st Gen runtime) takes the order, goes to the tray, and serves it. If many guests want the same dish, the host must prepare multiple trays in advance — cold starts happen if no tray is ready. The host also logs every order in a paper ledger (Cloud Logging) and charges per tray used. The 2nd Gen buffet is a modern, automated kitchen. You place your order at a kiosk (Eventarc trigger). The kitchen manager (2nd Gen runtime) immediately dispatches a robot chef (Cloud Run container) to cook your dish from scratch using a recipe (function source). The robot chef works on a new stovetop (Sandboxed container with gVisor) and can handle multiple orders simultaneously with minimal delay (sub-second cold starts). The kitchen manager also tracks everything digitally (Cloud Audit Logs, VPC-compatible logging). The 1st Gen buffet is simpler but rigid; the 2nd Gen kitchen is more flexible, faster, and integrates with modern ordering systems. Both serve food, but the 2nd Gen is built for scale and speed.
What is Cloud Functions?
Cloud Functions is Google Cloud's Functions-as-a-Service (FaaS) platform, allowing you to run single-purpose code in response to events without managing servers. You write a function in Node.js, Python, Go, Java, .NET, Ruby, or PHP, and Google Cloud handles the runtime environment, scaling, and lifecycle. Functions are stateless, ephemeral, and automatically scaled from zero to thousands of instances based on incoming requests. The ACE exam tests both 1st Gen (original GCF) and 2nd Gen (based on Cloud Run and Eventarc).
Why Two Generations?
Google introduced 2nd Gen Cloud Functions in 2022 to address limitations of 1st Gen. 1st Gen uses a custom runtime environment with limited concurrency (1 request per instance at a time), longer cold starts (hundreds of ms to seconds), and no support for advanced networking features like VPC ingress/egress controls. 2nd Gen is built on Cloud Run and Eventarc, providing:
Concurrency: Multiple requests can be processed by a single function instance (default 1, configurable up to 1000).
Faster cold starts: Sub-100ms for many runtimes due to sandboxed containers (gVisor).
Rich event sources via Eventarc: Over 60+ event sources including Cloud Audit Logs, Pub/Sub, and custom sources.
VPC connectivity: Native support for VPC Service Controls, Private Service Connect, and direct VPC egress.
Longer timeout: Up to 60 minutes (vs 9 minutes in 1st Gen).
Larger memory: Up to 32 GiB (vs 8 GiB in 1st Gen).
Despite these improvements, 1st Gen is still supported and may be preferred for simple HTTP triggers with low latency requirements and minimal configuration. The ACE exam expects you to know when to choose each generation.
How Cloud Functions Work Internally
When you deploy a Cloud Function, Google Cloud packages your source code along with runtime dependencies into a container image. For 1st Gen, this image runs in a custom sandbox (not Cloud Run). For 2nd Gen, it runs as a Cloud Run revision. The function is triggered by an event:
HTTP triggers: An HTTPS endpoint is created. When a request arrives, the load balancer routes it to an idle instance or starts a new one. The function runs and returns a response. The instance stays alive for a period (default 5 minutes in 1st Gen, configurable in 2nd Gen) to handle subsequent requests.
Event triggers: An event (e.g., Pub/Sub message, Cloud Storage object change) is delivered to the function via Eventarc (2nd Gen) or direct integration (1st Gen). The function processes the event and acknowledges it.
Cold starts occur when a new instance must be created because no idle instance exists. In 1st Gen, cold starts can take 500ms-2s depending on runtime. In 2nd Gen, they are typically under 200ms. Warm starts (reusing an idle instance) are nearly instantaneous.
Key Components and Defaults
Function name: Must be unique within a project and region. Length 1-62 characters, starts with letter, ends with alphanumeric.
Region: Functions are regional. Choose a region close to your event source or users. Some regions (e.g., us-central1) have more capacity.
Memory: 1st Gen: 128 MiB to 8 GiB (default 256 MiB). 2nd Gen: 128 MiB to 32 GiB (default 256 MiB). CPU is allocated proportionally.
Timeout: 1st Gen: 1-540 seconds (9 minutes). 2nd Gen: 1-3600 seconds (60 minutes). Default 60 seconds for both.
Concurrency: 1st Gen: Always 1 (no concurrency). 2nd Gen: 1-1000 (default 1).
Min instances: 0 (default) to reduce cost; can set to 1+ to avoid cold starts.
Max instances: 1st Gen: Up to 3000 (default). 2nd Gen: Up to 3000 (default).
Ingress settings: 1st Gen: Allow all, allow internal only, or allow internal and Cloud Load Balancing. 2nd Gen: Same but also supports VPC Service Controls.
VPC connector: 1st Gen requires Serverless VPC Access connector for VPC access. 2nd Gen has direct VPC egress via VPC connector or Private Service Connect.
Configuration and Verification Commands
Deploy a 1st Gen HTTP function:
gcloud functions deploy hello-world \
--runtime python312 \
--trigger-http \
--allow-unauthenticated \
--entry-point hello_world \
--region us-central1Deploy a 2nd Gen HTTP function:
gcloud functions deploy hello-world-2nd \
--runtime python312 \
--trigger-http \
--allow-unauthenticated \
--entry-point hello_world \
--region us-central1 \
--gen2Deploy a 2nd Gen function triggered by Pub/Sub:
gcloud functions deploy pubsub-function \
--runtime python312 \
--trigger-topic my-topic \
--entry-point handle_pubsub \
--region us-central1 \
--gen2List functions:
gcloud functions list --region us-central1Describe a function:
gcloud functions describe hello-world --region us-central1View logs:
gcloud functions logs read hello-world --region us-central1Interaction with Related Technologies
Cloud Run: 2nd Gen functions are deployed as Cloud Run services. You can view them in the Cloud Run console and they share the same infrastructure. This means you can use Cloud Run features like traffic splitting, revision management, and concurrency settings.
Eventarc: 2nd Gen functions use Eventarc for event triggers. Eventarc provides a standardized event bus that can filter and route events from many sources. 1st Gen uses direct integrations with limited sources.
Cloud Storage: Both generations support Cloud Storage triggers (object finalize, delete, etc.). 2nd Gen uses Eventarc; 1st Gen uses direct GCS notifications.
Pub/Sub: Both support Pub/Sub triggers. 2nd Gen uses Eventarc; 1st Gen uses direct subscription.
Cloud Scheduler: You can trigger HTTP functions on a schedule via Cloud Scheduler.
VPC: Both generations can access VPC resources via Serverless VPC Access connector. 2nd Gen also supports Private Service Connect for direct access to private IPs.
Cloud Build: Functions are built using Cloud Build when deployed from source.
Cloud Logging and Monitoring: All functions automatically send logs and metrics. 2nd Gen uses Cloud Audit Logs for event triggers.
Scaling Behavior
1st Gen: Scaling is based on request rate. When a request arrives, if no idle instance exists, a new instance is created. Instances are kept alive for a default of 5 minutes (configurable via --min-instances and --max-instances). The maximum number of instances is 3000 by default, but can be increased via quota request.
2nd Gen: Scaling is managed by Cloud Run. The function can handle multiple concurrent requests per instance. The autoscaler adjusts the number of instances based on CPU utilization or request concurrency. Idle instances are kept for a default of 15 minutes (can be configured via --min-instances). Max instances default to 3000.
Cold Start Mitigation
Use --min-instances to keep a baseline of warm instances. This incurs cost even when idle.
Choose a runtime with fast startup (e.g., Go, Node.js, Python).
Keep dependencies minimal.
Use 2nd Gen for lower cold start latency.
For 1st Gen, consider using --min-instances and a lower timeout.
Security Considerations
Authentication: By default, HTTP functions require authentication. Use --allow-unauthenticated to allow unauthenticated access. For event triggers, the function must have appropriate permissions to receive events (e.g., Pub/Sub subscriber role, Eventarc event receiver role).
Service account: Each function runs under a service account. By default, it uses the App Engine default service account. For 2nd Gen, you can specify a custom service account with --service-account.
VPC ingress/egress: Control which networks can invoke the function. 2nd Gen supports VPC Service Controls for perimeter security.
Secrets: Use Secret Manager to store sensitive data; the function can access secrets at runtime.
Differences in Event Sources
1st Gen supports the following event sources natively:
Cloud Storage (finalize, delete, archive, metadata update)
Cloud Pub/Sub (topic messages)
Cloud Firestore (document create, update, delete, write)
Firebase (Authentication, Realtime Database, Remote Config, etc.)
Cloud Logging (log entries matching a filter)
2nd Gen via Eventarc supports all of the above plus:
Cloud Audit Logs (all services)
Cloud Scheduler
BigQuery (job completion)
Cloud Tasks
Custom event sources via Eventarc channels
Pricing Differences
1st Gen: Pay per invocation, compute time (rounded up to 100ms), and network egress. Free tier: 2 million invocations/month, 400,000 GB-seconds, 200,000 GHz-seconds. 2nd Gen: Same pricing model but with higher memory options. No free tier for 2nd Gen (uses Cloud Run pricing). However, Cloud Run has its own free tier.
Migration from 1st Gen to 2nd Gen
To migrate a function: 1. Create a new 2nd Gen function with the same code and trigger. 2. Update event sources to use Eventarc if needed. 3. Test thoroughly, especially for concurrency and timeout behavior. 4. Update clients to point to the new endpoint. 5. Delete the old 1st Gen function.
There is no automated migration tool; you must redeploy.
Write and package function code
You write your function in a supported language (Node.js, Python, Go, Java, .NET, Ruby, PHP). The function must export a handler that accepts a request/event and returns a response. For HTTP functions, the handler receives a Flask-like request object (for Python) or equivalent. For event functions, the handler receives a CloudEvent (2nd Gen) or a background event (1st Gen). You also define dependencies in a package.json (Node), requirements.txt (Python), go.mod (Go), etc. The source code and dependencies are uploaded during deployment.
Deploy using gcloud or console
You run `gcloud functions deploy` specifying the function name, runtime, trigger type, entry point, region, and optionally generation (`--gen2`). The CLI uploads the source code to Cloud Build, which builds a container image. For 1st Gen, it creates a custom runtime. For 2nd Gen, it creates a Cloud Run service. The function is then deployed and an HTTPS endpoint is created for HTTP triggers. For event triggers, the function is registered with Eventarc (2nd Gen) or the event source directly (1st Gen).
Trigger invocation and instance creation
When an event occurs (e.g., HTTP request arrives, Pub/Sub message published), the trigger mechanism delivers the event to the function. If no idle instance exists, a new instance is created (cold start). In 1st Gen, the new instance boots the runtime, loads dependencies, and runs the function. In 2nd Gen, the Cloud Run sandbox starts a container from the pre-built image. The function handler is called with the event data. The instance is considered warm for subsequent requests.
Function execution and response
The function executes its logic. It may access external services (e.g., Cloud Storage, Firestore, external APIs). For HTTP functions, it returns an HTTP response (status code, headers, body). For event functions, it acknowledges the event (e.g., Pub/Sub ack). The execution time is billed in 100ms increments (1st Gen) or 100ms increments (2nd Gen). If the function times out (exceeds the configured timeout), it is terminated and the event may be retried or lost depending on the source.
Instance lifecycle and scaling
After execution, the instance remains idle for a period (default 5 minutes for 1st Gen, 15 minutes for 2nd Gen) to handle new requests. If no new request arrives within that period, the instance is shut down. If traffic increases, new instances are created up to the max instances limit. In 2nd Gen, a single instance can handle multiple concurrent requests (if concurrency > 1). The autoscaler adjusts the number of instances based on load metrics. When traffic drops, excess instances are terminated.
Enterprise Scenario 1: Image Processing Pipeline
A media company uploads user images to Cloud Storage. They need to generate thumbnails and apply watermarks. They deploy a 2nd Gen Cloud Function triggered by Cloud Storage finalize events via Eventarc. The function reads the image, resizes it, adds a watermark, and writes the processed image to another bucket. The function is configured with 2 GiB memory and a 300-second timeout. Concurrency is set to 80 to handle burst uploads. In production, they set min-instances to 10 during business hours to avoid cold starts. They use VPC Service Controls to restrict access to the bucket. Common issues: if the function times out, the event is retried up to 3 times; if it still fails, the event is lost. They monitor with Cloud Logging and set up alerts for high error rates.
Enterprise Scenario 2: Real-time Data Enrichment
A financial services company streams transaction data through Pub/Sub. They deploy a 2nd Gen Cloud Function that enriches each transaction with fraud detection scores from a third-party API. The function is triggered by Pub/Sub and writes results to BigQuery. They set concurrency to 200 and max instances to 500. They use a custom service account with minimal permissions (only Pub/Sub subscriber, BigQuery data writer). They also use Secret Manager to store API keys. The function must complete within 30 seconds; if the external API is slow, the function times out and the transaction is sent to a dead-letter topic. They use Cloud Monitoring to track latency and error rates. Misconfiguration: if concurrency is too high, the external API rate limits cause failures; they tune concurrency based on API limits.
Enterprise Scenario 3: Scheduled Report Generation
A healthcare organization needs to generate daily compliance reports. They use Cloud Scheduler to trigger an HTTP Cloud Function (2nd Gen) at 6 AM daily. The function queries BigQuery for the previous day's data, formats a PDF, and emails it via SendGrid. The function has a 9-minute timeout and 512 MiB memory. They set min-instances to 0 to save cost. If the function fails, Cloud Scheduler retries up to 5 times. They use VPC connector to access a private BigQuery endpoint. Common problem: if the function takes longer than 9 minutes, it is terminated; they optimize the query or increase timeout to 15 minutes (2nd Gen allows up to 60).
The ACE exam tests Cloud Functions under Domain 3.1 'Deploy and Implement' with specific objectives: 'Deploy Cloud Functions (1st and 2nd gen)' and 'Configure triggers for Cloud Functions'. Expect 3-5 questions on these topics.
Most Common Wrong Answers
'1st Gen supports concurrency': Many candidates assume all FaaS platforms support concurrency. 1st Gen does NOT support concurrency; each instance handles one request at a time. 2nd Gen does.
'2nd Gen requires a VPC connector for all VPC access': 2nd Gen can use direct VPC egress via Private Service Connect without a VPC connector. The connector is optional.
'HTTP functions are always public': By default, HTTP functions require authentication. You must explicitly set --allow-unauthenticated to make them public.
'Cloud Functions support any runtime': Only specific runtimes (Node.js, Python, Go, Java, .NET, Ruby, PHP) are supported. Custom runtimes are not allowed.
'Event triggers deliver events in the same format across generations': 1st Gen uses background events (e.g., data and context objects). 2nd Gen uses CloudEvents (standardized format). The exam tests this difference.
Specific Numbers and Terms to Memorize
Default timeout: 60 seconds (both generations).
Maximum timeout: 1st Gen: 540 seconds (9 min). 2nd Gen: 3600 seconds (60 min).
Default memory: 256 MiB.
Max memory: 1st Gen: 8 GiB. 2nd Gen: 32 GiB.
Default concurrency (2nd Gen): 1.
Max concurrency (2nd Gen): 1000.
Default min instances: 0.
Default max instances: 3000.
Cold start idle period: 1st Gen: 5 minutes. 2nd Gen: 15 minutes.
1st Gen event format: Background events. 2nd Gen: CloudEvents.
Trigger types: HTTP, Pub/Sub, Cloud Storage, Firestore, etc.
Edge Cases and Exceptions
If a function times out, the request/event may be retried depending on the source. For HTTP, the client sees a 504. For Pub/Sub, the message is retried up to 7 days (default). For Cloud Storage, the event is not retried.
Functions in the same region can share a VPC connector. The connector must be in the same region.
2nd Gen functions support Cloud Run features like revision tags, traffic splitting, and custom domains.
You can deploy a function from a container image (2nd Gen only) using --source image://....
The --trigger-event-filters flag is used for Eventarc triggers (2nd Gen) to filter events by attributes.
How to Eliminate Wrong Answers
If a question mentions 'concurrency' or 'multiple requests per instance', it must be 2nd Gen.
If a question mentions 'maximum 9-minute timeout', it's 1st Gen.
If a question mentions 'VPC ingress controls' or 'Private Service Connect', it's 2nd Gen.
If a question mentions 'CloudEvents', it's 2nd Gen.
If a question mentions 'background function', it's 1st Gen.
Always check the runtime list — if it's not one of the supported runtimes, it's not a valid deployment.
1st Gen Cloud Functions handle one request per instance; 2nd Gen supports concurrency up to 1000.
Default timeout is 60 seconds for both generations; max is 540 seconds (1st Gen) and 3600 seconds (2nd Gen).
Default memory is 256 MiB; max is 8 GiB (1st Gen) and 32 GiB (2nd Gen).
1st Gen uses background events; 2nd Gen uses CloudEvents via Eventarc.
Cold start idle period: 5 minutes (1st Gen) and 15 minutes (2nd Gen).
2nd Gen functions are built on Cloud Run and can use Cloud Run features like traffic splitting and custom domains.
HTTP functions require authentication by default; use --allow-unauthenticated to make them public.
VPC access requires a Serverless VPC Access connector (both) or Private Service Connect (2nd Gen only).
These come up on the exam all the time. Here's how to tell them apart.
1st Gen Cloud Functions
Concurrency: 1 request per instance (no concurrency).
Max timeout: 540 seconds (9 minutes).
Max memory: 8 GiB.
Event format: Background events (non-standard).
VPC access: Requires Serverless VPC Access connector only.
2nd Gen Cloud Functions
Concurrency: 1-1000 requests per instance (configurable).
Max timeout: 3600 seconds (60 minutes).
Max memory: 32 GiB.
Event format: CloudEvents (standard).
VPC access: VPC connector or Private Service Connect (native).
Mistake
Cloud Functions automatically retry failed invocations for all trigger types.
Correct
Only certain triggers retry. Pub/Sub messages are retried for up to 7 days. HTTP requests are not retried; the client must retry. Cloud Storage events are not retried. 2nd Gen functions can configure dead-letter queues for Eventarc triggers.
Mistake
1st Gen and 2nd Gen functions are interchangeable without code changes.
Correct
The event format differs. 1st Gen uses background events (e.g., `data` and `context` parameters). 2nd Gen uses CloudEvents (standardized `cloudevent` object). Code must be updated to handle the new format.
Mistake
2nd Gen functions always have lower cold start latency than 1st Gen.
Correct
2nd Gen generally has faster cold starts (sub-100ms vs 500ms-2s), but cold starts can still be high if the container is large or dependencies are heavy. Using min-instances helps both generations.
Mistake
You can set concurrency to any value up to 1000 in 2nd Gen without issues.
Correct
High concurrency can cause resource contention (CPU, memory) and external API rate limits. You must test and tune concurrency based on your function's resource usage and downstream dependencies.
Mistake
Cloud Functions can access VPC resources without any configuration.
Correct
By default, functions run in a Google-managed environment with no VPC access. To access VPC resources, you must either use a Serverless VPC Access connector (both generations) or, for 2nd Gen, use Private Service Connect.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Use the `gcloud functions deploy` command with the `--gen2` flag. For example: `gcloud functions deploy my-function --runtime python312 --trigger-http --allow-unauthenticated --entry-point hello --region us-central1 --gen2`. The `--gen2` flag tells the CLI to deploy as a 2nd Gen function, which creates a Cloud Run service behind the scenes.
1st Gen uses direct integrations with event sources like Cloud Storage and Pub/Sub, delivering events in a background event format (with `data` and `context` objects). 2nd Gen uses Eventarc, which delivers events in the CloudEvents standard format. The code must handle the different event structures. Additionally, 2nd Gen supports many more event sources via Eventarc, including Cloud Audit Logs and custom events.
Yes. Both generations support Pub/Sub triggers. For 1st Gen, you deploy with `--trigger-topic TOPIC_NAME`. For 2nd Gen, you deploy with `--trigger-topic TOPIC_NAME --gen2`. The function will be invoked for each message published to the topic. In 2nd Gen, the message is delivered as a CloudEvent. You must acknowledge the message within the timeout; otherwise, it will be redelivered.
Set the `--min-instances` flag to a value greater than 0. This keeps that many instances always warm, even when there is no traffic. For example, `--min-instances 1` ensures at least one instance is always running. Note that this incurs cost even when idle. Additionally, using 2nd Gen with a lightweight runtime (e.g., Node.js, Go) reduces cold start latency.
For 1st Gen, the maximum timeout is 540 seconds (9 minutes). For 2nd Gen, it is 3600 seconds (60 minutes). The default is 60 seconds for both. You can set the timeout using the `--timeout` flag when deploying, e.g., `--timeout=300` for 300 seconds.
Yes, but you need to configure VPC access. For both generations, you can use a Serverless VPC Access connector to connect to a VPC where Cloud SQL is deployed. For 2nd Gen, you can also use Private Service Connect. The function must have the appropriate permissions and use the private IP of the Cloud SQL instance.
Use the `--set-env-vars` flag during deployment. For example: `gcloud functions deploy my-function --set-env-vars KEY1=VALUE1,KEY2=VALUE2`. You can also use `--update-env-vars` to update existing variables. Environment variables are available in the function's runtime environment. For secrets, use Secret Manager instead.
You've just covered Cloud Functions (1st and 2nd Gen) — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?