Google ACE Practice Question: A team wants to configure a Cloud Scheduler job…

Answer analysis

Option-by-option breakdown

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

• ✗

  Include a Bearer token in the Authorization header of the scheduled HTTP request

  Why it's wrong here

  A static Bearer token embedded in a scheduled request is a long-lived secret and introduces a significant security risk if exposed. More importantly, Cloud Run recognizes only Google-issued OIDC identity tokens (or tokens from a verified third-party identity provider if configured) for authenticated invocations; a manually supplied static Bearer token is not a valid Google identity token. Cloud Scheduler's built-in OIDC support generates a short-lived token automatically, so a hardcoded Bearer token is neither secure nor correctly authenticated.

• ✓

  Configure the Cloud Scheduler job with OIDC authentication using a service account that has Cloud Run Invoker permission

  Why this is correct

  Cloud Scheduler can authenticate HTTP targets using OIDC by automatically generating a short-lived Google-issued identity token for a configured service account. That token is placed in the Authorization header as 'Bearer <token>' for each scheduled request. The service account must be granted the roles/run.invoker role on the target Cloud Run service so that the token is accepted. This is the recommended pattern because the token is ephemeral, automatically rotated, and tied to a specific service, making it both secure and auditable.

• ✗

  Make the Cloud Run service publicly accessible and use Cloud Armor to restrict access to Cloud Scheduler IPs

  Why it's wrong here

  This approach is insecure and unreliable because Cloud Scheduler does not guarantee a stable, published set of source IP addresses that you can safely allowlist. Cloud Armor can restrict traffic at a load balancer, but exposing a Cloud Run service publicly and relying on IP filtering still leaves the endpoint reachable from any allowed range and bypasses per-request identity verification. The proper method is to keep the Cloud Run service private and use IAM-based OIDC authentication from Cloud Scheduler, which ensures only requests with a valid identity token can invoke the service.

• ✗

  Configure an API key for the Cloud Run service and include it in the scheduled request URL

  Why it's wrong here

  Cloud Run does not accept API keys as a form of authentication for service invocation. Requests to a private Cloud Run service require a Google-issued OIDC identity token in the Authorization header, not a static key. Additionally, placing an API key in the URL can leak the key through logs and is against Google's security best practices. Since Cloud Run's only supported non-public auth mechanism is IAM-based, an API key would be ignored and the request would be rejected as unauthenticated.

Go deeper

Related to this question