Question

Difficulty: Very hardPlanning Serverless Compute Options (Cloud Run and Cloud Functions)

An enterprise telemetry team is designing a serverless architecture on Google Cloud to handle two distinct workload components:

1. An HTTP webhook ingestion endpoint that receives high-concurrency bursty web traffic and depends on a custom compiled C++ shared library binary.
2. An event-driven data transformation pipeline that processes incoming files uploaded to Cloud Storage, where individual file transformation runs take up to 25 minutes to complete.

You need to recommend a serverless compute architecture that minimizes operational overhead while satisfying all technical limits and runtime dependencies. Which TWO architectural decisions should you recommend? (Select TWO answers.)

  1. Deploy the HTTP webhook ingestion service to Cloud Run using a custom container image configured to handle multiple concurrent requests per instance.Answer
  2. Deploy the 25-minute data transformation workload to Cloud Run triggered asynchronously by Cloud Storage object creation events via Eventarc.Answer
  3. C
    Deploy the HTTP webhook ingestion service to Cloud Functions (2nd gen) using standard zip source code deployment with embedded C++ binary wrappers.
  4. D
    Deploy the 25-minute data transformation workload directly as a Cloud Storage-triggered Cloud Functions (2nd gen) function with its timeout configured to 30 minutes.

Answer

The correct architecture uses Cloud Run with a custom container image for the HTTP webhook service to support multi-concurrency and native C++ binary dependencies, and uses Cloud Run triggered via Eventarc for the 25-minute Cloud Storage data transformation pipeline to exceed the 9-minute event-driven function limit.
The design correctly pairs Cloud Run with both requirements: first, Cloud Run accepts custom container images containing custom compiled binary dependencies (like C++) while allowing request concurrency per instance; second, Cloud Run supports request/task timeouts up to 60 minutes when invoked asynchronously via Eventarc for Cloud Storage events, bypassing the 9-minute event timeout restriction of Cloud Functions.

Step-by-Step Solution

1
Analyze requirement 1 (HTTP webhook with C++ binary dependency and high concurrency)
Cloud Run allows packaging any runtime environment or binary inside a Docker container image and supports up to 1000 concurrent requests per container instance, making it ideal for high-throughput HTTP endpoints with custom system dependencies.
Cloud Functions zip deployments only support standard high-level language runtimes and do not support low-level custom compiled binaries or full OS environment customization.
2
Analyze requirement 2 (25-minute file processing triggered by Cloud Storage)
Event-driven Cloud Functions (both 1st and 2nd gen) have a hard maximum timeout limit of 9 minutes (540 seconds) for event triggers. Workloads exceeding 9 minutes triggered by Cloud Storage events must run on Cloud Run services or Cloud Run jobs via Eventarc, which support HTTP/event timeouts up to 60 minutes.
Attempting to configure a 30-minute timeout on an event-driven Cloud Function violates GCP platform quota boundaries.

Key Concept

Selecting Cloud Run vs Cloud Functions based on custom binary dependencies, concurrency capabilities, and event-driven timeout boundaries.
Estimated Time:3m 0s
Rate this question