Google ACE Practice Question: A startup builds a serverless REST API using…

Answer analysis

Option-by-option breakdown

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

• ✗

  Approximately $0 — all invocations fall within the free tier

  Why it's wrong here

  This is incorrect because the free tier is far too small to cover the stated workload. The free tier includes 2 million invocations and 400,000 GB-seconds per month, but this scenario has 150 million invocations—75 times the free limit—and 7.5M GB-seconds, which is more than 18 times the free compute allowance. Every invocation and GB-second beyond those thresholds is billed, so the total cost will be well above zero. Even with free egress, the invocation and compute-time overages alone would generate a significant bill.

• ✓

  Estimate based on invocation count, compute time (memory × duration), and networking costs beyond the free tier

  Why this is correct

  Cloud Functions billing is consumption-based, charging for three dimensions: the number of invocations, compute time measured in GB-seconds (memory in GB multiplied by execution duration in seconds), and outbound network egress. The monthly free tier (2M invocations, 400K GB-seconds, and 5 GB network egress) is subtracted before per-unit rates apply. With 150M invocations and 7.5M GB-seconds, you would estimate cost by calculating usage above the free tier for each dimension and multiplying by the applicable regional price, making this the only correct approach.

• ✗

  Approximately the same as a continuously-running e2-medium VM — Cloud Functions and VMs are priced equivalently

  Why it's wrong here

  Cloud Functions do not have an hourly price; they are billed per invocation and per GB-second of compute time, while a continuously-running e2-medium VM charges a flat hourly rate regardless of utilization. These pricing models are fundamentally different and cannot be considered equivalent. A serverless function might be cheaper for low, spiky traffic or far more expensive for sustained high throughput like 150M invocations, depending on memory allocated and duration. A VM's cost is predictable and includes always-on capacity, but the per-execution charges of Cloud Functions make any equivalence false.

• ✗

  Fixed monthly rate based on the number of deployed functions, not invocation count

  Why it's wrong here

  Cloud Functions pricing is strictly usage-based and does not include any fixed monthly fee per deployed function. You are charged only for invocations, compute time (GB-seconds), and outbound network traffic; a function that is never called costs nothing beyond minimal source-code storage in some cases. This consumption model means the bill scales directly with actual execution activity, not with the number of function definitions in your project. Therefore, a fixed monthly rate based on deployed function count is an incorrect description of the pricing mechanism.

Go deeper

Related to this question