Google ACE Practice Question: A team needs to run a simple containerized script…

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 Run Services with a timeout set to 24 hours

  Why it's wrong here

  Cloud Run Services are designed for HTTP request/response workloads, not batch processing. Setting a timeout of 24 hours is not allowed—the maximum configurable timeout for a Cloud Run service request is far lower (typically 60 minutes or less). Even if a timeout were permitted, services scale to zero between requests and are billed per request, making them unsuitable for a nightly job that must run to completion without an incoming HTTP trigger.

• ✓

  Cloud Run Jobs triggered by Cloud Scheduler

  Why this is correct

  Cloud Run Jobs execute a container to completion in response to an explicit execution request, making them ideal for a nightly batch script. You can configure the job with a command, environment variables, a timeout (up to 24 hours or more), and the number of parallel tasks, and the job exits with a success/failure exit code. Cloud Scheduler can trigger the job via Pub/Sub or a direct API call using IAM authentication, providing a serverless cron that runs each night without maintaining an HTTP server.

• ✗

  Cloud Functions with a 540-second maximum timeout

  Why it's wrong here

  Cloud Functions are event-driven and stateless, with a maximum timeout of 540 seconds in 1st gen or 3600 seconds in 2nd gen. While 540 seconds might seem sufficient for simple tasks, a nightly batch that processes many files can easily exceed this limit, and batch workloads require explicit exit codes, retry logic, and container-level lifecycle management. Cloud Functions also do not support the same custom runtime control and task parallelism that a dedicated job execution environment provides, so they are not the right choice for a scheduled batch script that runs to completion.

• ✗

  App Engine Standard with a background service

  Why it's wrong here

  App Engine Standard is built for HTTP-serving applications and enforces a strict sandbox that terminates background work when the request handler returns. You cannot run a separate long-running background service inside App Engine Standard without triggering a request, and even then the maximum request timeout is limited (typically 10 minutes for automatic scaling or 60 minutes for manual scaling). A nightly batch script that processes files independently is not a request/response pattern, so App Engine Standard would require awkward workarounds and would not reliably finish the entire job.

Go deeper

Related to this question