Cloud Functions Study Notes

Cloud Functions is a serverless execution environment for running small, single-purpose pieces of code in response to events or HTTP requests, without provisioning servers. Google manages scaling and infrastructure, and you pay based on invocations and compute time. Under the current generation, functions are built and run using Cloud Run infrastructure under the hood while keeping the functions deployment experience.

Key facts

• Functions are triggered either by HTTP requests or by events from services such as Cloud Storage uploads, Pub/Sub messages, and Firestore changes, depending on the trigger you configure.
• Each function is stateless and scoped to one task; any data that must persist between invocations belongs in an external service such as Firestore, Cloud Storage, or Cloud SQL.
• Supported runtimes cover common languages including Python, Node.js, Go, Java, and others, and dependencies are declared in the standard file for that language, such as requirements.txt or package.json.
• The execution environment may reuse instances between invocations, so global variables can persist for performance, but you must never rely on that reuse for correctness.
• Event-driven functions can be configured for retries on failure, while HTTP functions return a response to the caller and are not automatically retried by the platform in the same way.
• Functions have configurable memory, timeout, concurrency in the second generation, and maximum instances, letting you limit cost and protect downstream systems.
• VPC connectivity is available through a Serverless VPC Access connector so a function can reach private resources, and ingress settings control which networks can invoke an HTTP function.
• Secrets should be supplied through Secret Manager integration rather than hard-coded in source code or plain environment variables checked into a repository.

What the exam expects you to know

• Matching an event source, such as an image uploaded to Cloud Storage or a message published to Pub/Sub, to a function trigger in a scenario.
• Choosing Cloud Functions for small, event-driven glue code versus Cloud Run for a full containerized service with custom dependencies.
• Understanding idempotency: event delivery is at-least-once in many cases, so a function may run more than once for the same event and must handle duplicates safely.
• Configuring retries, timeouts, and maximum instances to control runaway costs and repeated failures.
• Securing an HTTP function with IAM invoker permissions instead of leaving it publicly callable when the use case is internal.
• Supplying configuration and secrets through environment variables and Secret Manager rather than embedding them in the function code.

Cloud Functions vs Cloud Run: when to use which

Choose Cloud Functions when the work is a small piece of code reacting to an event, such as processing a file on upload or transforming a Pub/Sub message, and you do not want to build a container. Choose Cloud Run when you need a full service, custom system libraries, a specific container image, or more complex request handling. The criteria are unit of work and control: functions optimize for speed of development on events, while Cloud Run optimizes for portable containers and service behavior. See also the Cloud Run notes.

Useful gcloud commands

gcloud functions deploy my-function --runtime=python312 --trigger-http --allow-unauthenticated
gcloud functions list
gcloud functions logs read my-function
gcloud functions call my-function

Common exam traps

• Assuming a function runs exactly once per event: at-least-once delivery means duplicates happen, so writes and external side effects must be designed to be idempotent.
• Storing state on the local filesystem or in memory between calls: instances can be discarded at any time, so persistent state must live in an external store.
• Leaving retries enabled on a function whose downstream call is not safe to repeat, which can multiply charges, emails, or database writes after a failure.
• Hard-coding API keys in the source: use Secret Manager and grant the function's service account access to only the secrets it needs.

Frequently asked questions

What triggers can start a Cloud Function?

A function can be invoked by an HTTP request, by messages published to a Pub/Sub topic, by changes to a Cloud Storage bucket such as a new object upload, and by events from other services including Firestore and the eventing system based on Eventarc. You choose one trigger type when you deploy the function.

Why must functions be idempotent?

Many event sources deliver messages at least once, and the platform may retry a failed invocation, so the same event can be processed two or more times. An idempotent function produces the same safe result on repetition, for example by checking whether an output file or record already exists before creating it again.

How do I give a function access to a private database?

Attach a Serverless VPC Access connector to the function so its traffic can enter your VPC, place the database on a private address reachable from that network, and connect using the database's private IP or its proxy integration. Also grant the function's service account only the IAM roles and secrets it actually needs.

Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.