Google ACE Practice Question: A startup processes uploaded videos — each video…

Answer analysis

Option-by-option breakdown

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

• ✗

  Upload the video and synchronously wait for transcoding to complete before responding

  Why it's wrong here

  Synchronously waiting for transcoding to finish before returning a response forces the client to hold an open HTTP connection for 5–30 minutes, which exceeds typical proxy, load balancer, and browser timeout limits. This blocks the client and ties up server resources for the entire duration, making the system vulnerable to upload bursts and poor network conditions. The operation cannot scale because every request consumes a worker plus a connection slot for minutes, and it provides zero user value during the wait. An asynchronous pattern with a job ID and status polling is the accepted alternative.

• ✓

  Publish a transcoding job to Cloud Pub/Sub after upload; respond immediately; workers consume and process jobs asynchronously

  Why this is correct

  Immediately returning an acknowledgment after publishing the job to Cloud Pub/Sub gives the user a fast response while decoupling API availability from transcoding latency. Cloud Pub/Sub durably buffers the messages, so a burst of uploads doesn't cause lost work or API saturation. Autoscaling Compute Engine or Cloud Run workers pull messages at their own pace and perform transcoding independently, making the pipeline elastic and burst-tolerant. This is the canonical asynchronous, event-driven media-processing pattern on Google Cloud.

• ✗

  Use Cloud Spanner to store video metadata and transcode synchronously in a Cloud SQL stored procedure

  Why it's wrong here

  Cloud Spanner is excellent for globally distributed metadata storage, but a Cloud SQL stored procedure is not a media-processing engine—SQL was never designed for pixel manipulation or codec conversion. Invoking a stored procedure that performs transcoding would serialize work in the database, consume database CPU/connection slots for minutes, and block transactional throughput. This architecture misplaces the compute layer, mixes operational concerns, and creates a severe scalability ceiling. Metadata should be stored in Spanner or Cloud SQL independently, while transcoding belongs in dedicated workers or the Cloud Transcoder API.

• ✗

  Deploy the transcoding directly in the API server and scale the API server horizontally for bursts

  Why it's wrong here

  Running transcoding synchronously inside the API server couples CPU-heavy, long-running work to the request path. Every video upload consumes API server memory and compute for minutes, blocking other requests and causing timeouts during bursts; horizontal scaling merely replicates a bottleneck rather than removing it. This design also forces the API server into a special-purpose compute role, complicating autoscaling policies (API traffic vs. transcoding load). It creates a poor user experience and does not survive transient infrastructure failures as gracefully as an isolated worker pool.

Go deeper

Related to this question