Cloud Digital Leader Google Cloud Products and Services Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Cloud Functions

  Why this is correct

  Cloud Functions is the ideal fit because it is a managed Function-as-a-Service platform that executes code in response to a Pub/Sub event, scaling to zero when idle. It bills only for the actual invocation time, measured in 100ms increments, so a small Python snippet that runs once or twice undergoes no idle cost or container overhead. Its event-driven trigger model and built-in Pub/Sub subscription abstraction remove the need to run a web server or manage infrastructure, making it the most cost-effective and operationally simple choice for this task.

• ✗

  Cloud Run

  Why it's wrong here

  Cloud Run is not the most cost-effective choice here because its billing model, based on container instance duration and CPU/memory usage, is less granularly optimised for extremely infrequent, sub-second executions than a function-as-a-service offering. It is tempting as it offers serverless container deployment and scales to zero, making it ideal for event-driven web services or APIs that might require custom runtime environments or have slightly longer, more consistent execution profiles.

• ✗

  Compute Engine with preemptible VM

  Why it's wrong here

  Compute Engine, even when using preemptible VMs, bills for the time the virtual machine exists, not for the number of invocations of your code; you must provision and boot an instance, and you continue paying per-second (after a 1-minute minimum) even while it sits idle. For an infrequent, sub-second Python script, the orchestration and cost overhead are vastly higher than a FaaS alternative. Additionally, a preemptible VM can be terminated by Google at any time, adding availability risk that is unacceptable for a simple, quick task that could simply be triggered on-demand.

• ✗

  App Engine Standard Environment

  Why it's wrong here

  App Engine Standard is a PaaS designed around the web application lifecycle: your code must implement an HTTP (or, for some runtimes, a push) handler, and a Pub/Sub subscription would need to be configured to deliver messages to an HTTP endpoint on your service. This forces a small Python snippet to be wrapped in a web server and deployed as an app, introducing unnecessary architectural complexity. While App Engine does scale to zero, its billing model and runtime constraints are optimised for persistent or request-driven services, not for a one-off utility triggered by a message bus.

Go deeper

Related to this question