Google ACE Practice Question: A developer wants to deploy a Cloud Function that…

Answer analysis

Option-by-option breakdown

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

• ✗

  Use a Pub/Sub topic and a push subscription to invoke the Cloud Function

  Why it's wrong here

  Using Pub/Sub adds an unnecessary intermediary; Cloud Storage natively supports direct event notifications to Cloud Functions via the `google.storage.object.finalize` event type, eliminating the latency and cost of an extra hop. This option tempts because Pub/Sub is the standard decoupling layer for asynchronous workflows, and would be correct if the function required guaranteed delivery, fan-out to multiple subscribers, or integration with other services beyond a single trigger.

• ✓

  Create a Cloud Function with a Cloud Storage trigger and specify the bucket and event type

  Why this is correct

  Creating a Cloud Function with a Cloud Storage trigger is the native event-driven integration: after you specify the bucket and the `google.storage.object.finalize` event type, Cloud Storage automatically invokes the function whenever a new object is written. No custom infrastructure, no polling, and no intermediate services are needed. This is the simplest, lowest-latency approach because the execution is driven directly by the storage event and automatically scales to zero when idle.

• ✗

  Use a Compute Engine instance to watch the bucket and call the function

  Why it's wrong here

  Running a Compute Engine instance solely to watch a bucket and then call the function introduces a persistent virtual machine that must be patched, monitored, and kept running 24/7. The instance would have to either poll for bucket changes using the JSON/XML API or implement object change notifications, adding latency and operational overhead. This contradicts the serverless best practice of letting the event source trigger the function directly, and it is more expensive and less reliable than a managed Cloud Storage trigger.

• ✗

  Set up a Cloud Scheduler job to periodically scan the bucket and invoke the function

  Why it's wrong here

  A Cloud Scheduler job that periodically scans the bucket and invokes the function cannot provide real-time, event-driven behavior; it only sees changes that occur between scheduled runs and may miss or duplicate work if the bucket is modified multiple times in a short window. You are also forced to design a custom polling or listing loop inside the scheduled job, which adds code, cost, and an unnecessary dependence on Scheduler quotas and latency. This is inefficient and error-prone compared to a Cloud Storage trigger that fires immediately on object finalize.

Go deeper

Related to this question