Question 1

What are Cloud Functions?

Accepted Answer

Cloud Functions is GCP's functions-as-a-service offering: you deploy a single function in a supported runtime — Node.js, Python, Go, Java, .NET, Ruby, PHP — and Google runs it in response to an HTTP request or an event, scaling automatically and billing only for execution time. There is no server or container to define. The framing to lead with is "smallest unit of deployable compute": one function, one responsibility, triggered by one kind of event. It suits glue code and event handlers, and becomes awkward as soon as you want several related endpoints, which is where Cloud Run fits better.

Question 2

What is the difference between Cloud Functions 1st gen and 2nd gen?

Accepted Answer

2nd gen is built on Cloud Run and Eventarc, so it inherits much longer timeouts (up to 60 minutes for HTTP), larger instances up to 16 GiB and 4 vCPU, concurrency of up to 1000 requests per instance, traffic splitting between revisions, and access to more than 90 event sources through Eventarc. 1st gen has shorter timeouts, one request per instance and a limited trigger set. The concurrency difference is the most consequential: 1st gen handled exactly one request per instance, so ten simultaneous requests meant ten instances and ten cold starts. 2nd gen behaves like Cloud Run, which changes both latency and cost substantially.

Question 3

What trigger types do Cloud Functions support?

Accepted Answer

HTTP triggers, which invoke the function on a request; and event triggers, including Pub/Sub messages, Cloud Storage object changes, Firestore document changes, Firebase events, Cloud Scheduler jobs, and — through Eventarc in 2nd gen — any GCP service that emits audit logs. The audit-log trigger is the powerful and often-missed one: it means you can react to almost any GCP action, such as a firewall rule being changed or a BigQuery dataset being made public. The caveat is higher latency than a direct source trigger.

Question 4

What is a cold start and what causes it in Cloud Functions?

Accepted Answer

A cold start is the extra latency when a request arrives and no warm instance exists, so the platform must allocate an instance, load the runtime, initialise your code and dependencies, and only then handle the request. It is caused by scaling from zero, scaling out under load, and instance recycling. The controllable part is your initialisation: heavy imports, large dependency trees, establishing database connections and loading models at module scope all extend it. Doing that work lazily, or setting minimum instances, are the two levers, and naming both with their cost implications is the complete answer.

Question 5

How do you reduce cold-start latency?

Accepted Answer

Set minimum instances so warm instances always exist; keep the deployment package and dependency tree small; move expensive initialisation out of the request path or make it lazy; reuse connections and clients across invocations by declaring them in global scope; and choose a runtime with faster startup for latency-critical paths. The global-scope reuse point is important and subtly different from initialisation cost: a database client created inside the handler is recreated on every invocation, while one in global scope is reused by subsequent invocations on the same warm instance. That is a code-level fix with a large effect.

Question 6

What is the difference between global scope and function scope in a Cloud Function?

Accepted Answer

Code at module or global scope runs once per instance, when the instance is initialised, and its values persist across invocations on that instance. Code inside the handler runs on every invocation. Expensive, reusable objects — database clients, HTTP agents, loaded configuration — belong in global scope; per-request state must not. The bug this prevents is storing request-specific data in a global variable, which then leaks between invocations because instances are reused. That is a genuine security issue if the leaked value is user data, and it is exactly the kind of thing interviewers probe.

Question 7

What retry behaviour do Cloud Functions have?

Accepted Answer

HTTP functions are not retried automatically — the caller decides. Event-driven functions can be configured to retry on failure, in which case the platform redelivers the event with backoff for up to seven days until the function succeeds. Retry is off by default and must be enabled explicitly. The danger to name is enabling retries without idempotency and without a termination condition: a function that always fails on a particular message retries for seven days, consuming resources and potentially repeating partial side effects. A check on event age inside the function is the standard guard.

Question 8

How do you make an event-driven Cloud Function idempotent?

Accepted Answer

Use the event ID, which is stable across retries of the same event, or a business key, and record processed identifiers in Firestore or another store with a uniqueness constraint, checking before performing side effects. Prefer naturally idempotent operations such as upserts over increments. The distinction to make is between the event ID, which deduplicates retries of the same delivery, and a business key, which also deduplicates a genuine republish of the same logical event. Which one you need depends on the source, and knowing that shows depth.

Question 9

How do you secure an HTTP-triggered Cloud Function?

Accepted Answer

Do not allow unauthenticated invocations. Grant roles/cloudfunctions.invoker (or run.invoker for 2nd gen) only to the specific identities that should call it, so callers must present a Google-signed ID token verified before your code runs. For public endpoints, front it with a load balancer plus Cloud Armor, and validate any webhook signature in code. The webhook case is worth calling out separately: a third-party webhook cannot present a Google token, so the function must be public and must verify the provider's HMAC signature itself. Recognising that split — IAM for internal callers, signature verification for external ones — is the practical answer.

Question 10

How do you connect a Cloud Function to resources in a VPC?

Accepted Answer

Through Direct VPC egress in 2nd gen, or a Serverless VPC Access connector, which gives the function a path to private IPs — Cloud SQL private IP, Memorystore, internal load balancers, or on-premises resources over VPN or Interconnect. Egress settings control whether all traffic or only private-range traffic uses that path. The egress-setting detail matters for cost and for security: routing all traffic through the VPC lets you apply firewall rules and a NAT with a static IP, which is what a partner allowlisting your outbound address requires. Naming that use case makes the answer concrete.

Question 11

How do you manage secrets in a Cloud Function?

Accepted Answer

Reference Secret Manager secrets in the function configuration, either as environment variables or mounted as files, and grant the function's service account roles/secretmanager.secretAccessor. Never put secrets in plain environment variables or in the source, which are visible to anyone with viewer access and end up in deployment configuration. The rotation consideration is worth adding: mounting "latest" means a rotated secret takes effect on the next instance start with no redeploy, while pinning a version is more predictable but requires a deploy to rotate. Which you choose depends on whether predictability or automatic rotation matters more.

Question 12

What are the main limits of Cloud Functions you should design around?

Accepted Answer

Timeout up to 60 minutes for 2nd gen HTTP functions and 9 minutes for 1st gen; memory up to 16 GiB and 4 vCPU in 2nd gen; a maximum instance count you should set explicitly; request and response size limits; and an ephemeral in-memory filesystem, so anything written to /tmp counts against memory. The /tmp-counts-as-memory point is the one that produces confusing production failures: a function downloading files to /tmp appears to leak memory and is eventually killed. Naming it demonstrates you have debugged a real function rather than only deployed one.

Question 13

When would you use Cloud Functions instead of Cloud Run?

Accepted Answer

When the unit of work is genuinely a single event handler, you do not want to write or maintain a Dockerfile, and the deployment story of "push source, get an endpoint" is worth more than container control. Cloud Run is better for multi-endpoint services, custom runtimes, sidecars, and anything you want portable across platforms. Since 2nd gen runs on Cloud Run anyway, the honest framing is that this is a developer-experience choice rather than a capability one. Saying that plainly, rather than inventing technical distinctions that no longer exist, is the accurate answer.

Question 14

How is Cloud Functions priced?

Accepted Answer

By invocation count, by compute time measured in GB-seconds and GHz-seconds at 100 millisecond granularity, and by network egress. There is a generous perpetual free tier, and no charge when the function is idle because it scales to zero — unless you have set minimum instances, which bill continuously. The minimum-instances caveat is the practical cost trap: setting it to remove cold starts converts a scale-to-zero service into an always-on one. Quantifying that trade-off — a few rupees a day per warm instance versus a few hundred milliseconds of latency — is what makes the recommendation credible.

Question 15

What is Eventarc and how does it relate to Cloud Functions?

Accepted Answer

Eventarc is the unified event routing layer that delivers events from GCP sources, custom applications and third parties to targets including Cloud Functions 2nd gen, Cloud Run and Workflows, in the CloudEvents format. It is what gives 2nd gen functions access to far more trigger sources than 1st gen had. The two source classes to distinguish are direct sources, which are low latency, and audit-log sources, which cover nearly every GCP action but add latency measured in seconds to tens of seconds. Choosing between them based on how quickly you must react is the design decision.

Question 16

What is a CloudEvent?

Accepted Answer

CloudEvents is a CNCF specification for describing event data in a common format, with standard attributes such as id, source, type, subject and time alongside the payload. Eventarc and Cloud Functions 2nd gen deliver events in this format, so handlers have a consistent shape regardless of source. The practical benefit is portability and consistency: a handler written against CloudEvents works the same whether the event came from Cloud Storage or from a custom publisher, and the id attribute is the natural deduplication key for idempotency.

Question 17

How do you trigger a function when a file is uploaded to Cloud Storage?

Accepted Answer

Deploy a 2nd gen function with an Eventarc trigger on the google.cloud.storage.object.v1.finalized event type for the bucket. The function receives the bucket and object name in the CloudEvent, then reads the object. It must be idempotent because delivery is at-least-once. Two failure modes to pre-empt: the finalize event fires on overwrite as well as first creation, so an unguarded handler reprocesses; and a handler that writes back into the same bucket can trigger itself recursively, which is a classic runaway-cost incident.

Question 18

How would you schedule a Cloud Function to run every night?

Accepted Answer

Create a Cloud Scheduler job with a cron expression that invokes the function's HTTP endpoint using an OIDC token from a dedicated service account granted the invoker role, so the endpoint stays private. Alternatively have Scheduler publish to a Pub/Sub topic that triggers the function. The Pub/Sub route has an operational advantage worth naming: the message is retained and retried if the function fails, whereas a direct HTTP invocation that fails is simply logged. For anything that must not be missed, the Pub/Sub path is more robust.

Question 19

What happens if a Cloud Function throws an unhandled exception?

Accepted Answer

For an HTTP function the caller receives a 500 and the error is logged and grouped in Error Reporting. For an event-driven function, the invocation is marked failed; if retry is enabled the event is redelivered with backoff, and if not, the event is dropped. Either way the exception appears in Cloud Logging. The silent-loss case is the important one: an event function without retry that throws simply loses the event, with only a log line to show for it. Alerting on function error rate, not just on availability, is the mitigation to name.

Question 20

How do you test Cloud Functions locally?

Accepted Answer

Use the Functions Framework, the same open-source library the runtime uses, to run the function locally as an HTTP server, and post sample CloudEvents to it. Combine that with the Pub/Sub, Firestore and Cloud Storage emulators for integration tests, and unit test the business logic separately from the handler. The design advice that follows is to keep the handler thin — parse the event, call a plain function, format the response — so the logic is testable without any framework at all. That separation is what makes serverless code maintainable.

Question 21

What is the maximum concurrency of a Cloud Function and why does it matter?

Accepted Answer

In 2nd gen, concurrency is configurable up to 1000 requests per instance, defaulting to 1 for backwards compatibility with 1st gen behaviour. Raising it means fewer instances for the same traffic, which lowers cost and cold starts but requires the code to be thread-safe and to have enough memory and CPU headroom. The default of 1 catches people migrating from 1st gen: they get 2nd gen's capabilities but none of the concurrency benefit until they change the setting. Naming that default explicitly is a strong practical detail.

Question 22

What are the risks of a recursive function trigger?

Accepted Answer

A function triggered by a Cloud Storage write that itself writes to the same bucket, or a Pub/Sub function that republishes to its own topic, will invoke itself indefinitely, scaling out and generating unbounded cost until someone notices. It is one of the most common serverless cost incidents. The mitigations to name are writing to a different bucket or prefix, adding a guard on object metadata or a message attribute, and always setting a maximum instance count so the blast radius is bounded even if the logic is wrong. Budget alerts are detection, not prevention.

Question 23

How do you monitor Cloud Functions in production?

Accepted Answer

Cloud Monitoring provides invocation count, execution time distribution, active instance count and memory utilisation; Cloud Logging captures structured logs and stdout; Error Reporting groups exceptions by stack trace with alerting; and Cloud Trace shows latency across a distributed call chain. Alert on error rate, on execution time approaching the timeout, and on instance count hitting the maximum. Execution time approaching the timeout is the leading indicator worth naming — it warns you before functions start failing, whereas alerting on failure means you find out after the fact.

Question 24

What runtime service account does a Cloud Function use and what should it be?

Accepted Answer

By default it uses the App Engine or Compute Engine default service account, which is over-privileged. You should assign a dedicated service account per function with only the roles it needs on the specific resources it touches, so a compromise of one function does not expose the whole project. This is one of the highest-value and least-applied hardening steps in serverless GCP. Naming the default service account as the problem, rather than speaking generally about least privilege, is what shows you have actually reviewed a real project.

Question 25

How do you deploy Cloud Functions through CI/CD?

Accepted Answer

Build and deploy from Cloud Build or GitHub Actions authenticating with Workload Identity Federation, using gcloud functions deploy or Terraform for declarative management. Deploy to a staging project first, run integration tests, then promote. For 2nd gen you can also use traffic splitting to canary a revision. The Terraform-versus-gcloud choice is worth an opinion: declarative management keeps configuration such as service accounts, secrets and triggers reviewable, whereas gcloud flags in a script drift silently. Recommending Terraform for the infrastructure and a pipeline for the code is the balanced answer.

Question 26

What is the difference between a Cloud Function and a Cloud Run job?

Accepted Answer

A function responds to a request or event and is expected to complete quickly per invocation. A Cloud Run job runs a container to completion for batch work, supports many parallel tasks with task indices, has its own retry and timeout policy, and does not serve traffic at all. The selection rule is whether the work is triggered per event or is a bounded batch. Using a function with a long timeout to process an entire file set is the anti-pattern; a job with parallel tasks is the right shape and is far easier to observe and retry.

Question 27

How would you process a large uploaded CSV file with serverless components?

Accepted Answer

A Cloud Storage finalize event triggers a small function that validates the file and either enqueues work or starts a Cloud Run job. The job streams the file rather than loading it into memory, processes in chunks, writes results to BigQuery or a database, and records progress so a retry resumes rather than restarting. For very large files, Dataflow is the better processor. The streaming-rather-than-loading point is what the question is really testing, because the in-memory filesystem and memory limit make "download then parse" fail at scale. Naming a checkpointing strategy for resumability completes the answer.

Question 28

What is the difference between at-least-once and at-most-once delivery, and which do Cloud Functions get?

Accepted Answer

At-least-once means an event may be delivered more than once but never lost; at-most-once means it may be lost but never duplicated. Event-driven Cloud Functions get at-least-once delivery, because the underlying Pub/Sub and Eventarc infrastructure retries on failure or ambiguity. The reason at-least-once is the right default is that losing an event is usually worse than handling one twice, provided the handler is idempotent. Framing idempotency as the price of not losing data is a clear way to explain why it is non-negotiable.

Question 29

How do you handle a function that must call a slow third-party API?

Accepted Answer

Do not block on it in an event handler. Enqueue the call through Cloud Tasks with a configured dispatch rate and retry policy so you control the load on the third party, set a sensible client timeout, implement retries with exponential backoff and jitter, and add a circuit breaker so repeated failures stop hammering a broken dependency. Cloud Tasks is the GCP-specific piece and it is the right answer because it provides rate limiting per queue, which Pub/Sub does not. Naming the circuit breaker as well shows you think about the dependency's health, not only your own retries.

Question 30

What is the cost of the "one function per endpoint" pattern?

Accepted Answer

Each function is a separate deployment with its own cold starts, its own configuration, its own IAM binding and its own monitoring surface. For a service with twenty endpoints, that is twenty of everything, and shared code must be duplicated or packaged. A single Cloud Run service with a router is usually simpler at that point. The threshold to name is roughly when endpoints share state, dependencies or a deployment lifecycle — at that point they are one service and should deploy as one. Recognising when functions stop being the right granularity is a genuinely senior judgement.

Question 31

How do you pass configuration to a Cloud Function?

Accepted Answer

Non-sensitive configuration through environment variables set at deploy time, ideally managed in Terraform so it is reviewable. Sensitive values through Secret Manager references. Dynamic configuration that changes without a deploy through Firestore or a config service read at startup and cached, with a refresh strategy. The trade-off to state is that environment variables require a redeploy to change, which is a feature for auditability and a limitation for feature flags. Naming that distinction, and when each is appropriate, is better than listing mechanisms.

Question 32

What happens to in-flight work when a function instance is shut down?

Accepted Answer

The platform sends a termination signal and allows a short grace period before killing the instance. Work that has not completed is lost unless the event source retries it. Background work started outside the request lifecycle — a fire-and-forget promise — is particularly at risk because the platform does not know it exists. The fire-and-forget case is the trap: code that returns a response and then continues processing asynchronously will often be killed mid-work, and it also loses CPU allocation. Anything that must complete has to be part of the invocation or handed to a durable queue.

Question 33

How do you version and roll back Cloud Functions?

Accepted Answer

In 2nd gen, deployments create Cloud Run revisions, so you can split traffic between them and roll back by shifting traffic to the previous revision. In 1st gen there is no traffic splitting, so rollback means redeploying the previous source, which is why keeping deployment artefacts and source versions is essential. The practical implication is that 2nd gen supports progressive delivery and 1st gen does not, which alone is a reason to migrate. Naming that capability difference is more useful than listing the other 2nd gen improvements.

Question 34

What is the role of Cloud Functions in a microservices architecture?

Accepted Answer

They fit best as glue and reactive components — reacting to storage or database events, transforming and forwarding messages, handling webhooks, running scheduled maintenance — rather than as the primary service tier. Core request-serving services with multiple endpoints and shared state belong on Cloud Run or GKE. The judgement being tested is whether you use functions everywhere because they are cheap to start with. A system of a hundred functions with implicit dependencies is harder to reason about than five well-defined services, and being willing to say that is a mark of experience.

Question 35

How do you debug a Cloud Function that works locally but fails in production?

Accepted Answer

Check logs and Error Reporting first for the actual exception; verify the runtime service account has the permissions the code needs, since local runs use your own credentials; check whether it needs VPC access to reach a private resource; confirm environment variables and secrets are set in the deployed configuration; and check timeout and memory limits, which are unbounded locally. The credentials difference is the single most common cause: locally the code runs as a developer with broad permissions, in production as a minimal service account. Leading with that shows you understand the actual delta between the two environments.

Question 36

What is a Cloud Function's relationship to Firebase?

Accepted Answer

Cloud Functions for Firebase is the same underlying product with a Firebase-flavoured SDK and deployment tooling, adding triggers for Firebase Authentication, Realtime Database, Firestore, Remote Config and Firebase Hosting rewrites. Functions deployed either way run on the same infrastructure and appear in the same GCP project. The point that matters for an interview is that they are not separate products — a Firebase project *is* a GCP project — so the same IAM, logging, monitoring and billing apply. Candidates who treat them as different platforms usually reveal they have only used one side.

Question 37

What is the difference between synchronous and asynchronous invocation, and which do Cloud Functions use?

Accepted Answer

Synchronous invocation blocks the caller until the function returns a response — HTTP triggers work this way. Asynchronous invocation hands the event to the platform, which delivers it independently — event triggers work this way, so the publisher does not wait and does not learn whether processing succeeded. The consequence to draw out is error visibility: with asynchronous invocation the producer has no idea a handler failed, so monitoring and dead-lettering are the only feedback path. That is why event-driven systems need much more deliberate observability than request-response ones.

Question 38

How would you build a webhook receiver on GCP?

Accepted Answer

Expose an HTTP Cloud Function or Cloud Run service, allow unauthenticated invocation because the third party cannot present a Google token, and verify the provider's signature in code before doing anything. Acknowledge quickly with a 2xx and publish the payload to Pub/Sub for asynchronous processing, so a slow processor never causes the provider to time out and retry. The acknowledge-fast-then-process pattern is the substance: most webhook providers retry aggressively on timeouts, and doing the work inline turns a slow database into a flood of duplicate webhooks. Front it with a load balancer and Cloud Armor rate limiting to complete the design.

Question 39

What is the cold start impact of a large dependency tree, and how do you measure it?

Accepted Answer

Every dependency must be downloaded into the image at build time and loaded at instance startup, so a large tree directly extends cold-start latency, sometimes by seconds. Measure it by comparing the first invocation latency after a deploy against steady-state latency, and by logging a timestamp at module load and at the first request. The remedies are trimming unused dependencies, importing submodules rather than whole libraries where the runtime supports it, and deferring imports of rarely-used paths into the function body. Measuring before optimising is the part that makes the answer engineering rather than folklore.

Question 40

Design a serverless image-processing pipeline on GCP.

Accepted Answer

Clients upload directly to Cloud Storage with a signed URL, so no compute proxies the bytes. A finalize event triggers a function that validates the object and publishes to Pub/Sub. A Cloud Run service or job generates thumbnails and variants, writing to a separate output bucket to avoid recursive triggers, and records metadata in Firestore. A global load balancer with Cloud CDN serves the output bucket. Everything is idempotent on the object generation, with a dead-letter topic and alerting for failures. The closing scenario. The markers are the signed-URL direct upload, writing outputs to a different bucket to prevent recursion, and keying idempotency on the object generation rather than the name — because a re-upload of the same filename is a genuinely different object.

GCP Cloud Functions & Eventarc Interview Questions and Answers

How to use this set