Google ACE Practice Question: Ensure that a Cloud Run service can only be…

Answer analysis

Option-by-option breakdown

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

• ✗

  Add a Cloud Armor security policy to the Cloud Run service blocking all IPs except Cloud Scheduler.

  Why it's wrong here

  Cloud Armor security policies can only be attached to external HTTPS load balancers, not directly to Cloud Run services. Furthermore, Cloud Scheduler does not publish a fixed set of source IP ranges, so an IP-based allowlist cannot reliably identify its requests. Rejecting all other IPs also does not prevent requests from within a VPC or from other Google services. The correct pattern is IAM-based authentication with OIDC tokens, not network-layer filtering.

• ✓

  Disable unauthenticated invocations on the Cloud Run service, grant `roles/run.invoker` to the Scheduler SA, and configure Scheduler to use OIDC authentication.

  Why this is correct

  This is the correct approach because it leverages Cloud Run's native IAM integration. Disabling unauthenticated invocations makes the service require a valid Google-issued OAuth2/OIDC token for every request. Granting roles/run.invoker to the Cloud Scheduler service account authorizes precisely that identity to invoke the service. When Scheduler is configured with OIDC authentication, it attaches an OIDC token for that service account, which Cloud Run validates against the invoker role—thereby allowing only scheduled calls and blocking all other callers.

• ✗

  Deploy the Cloud Run service in a VPC and use a VPC firewall rule to block all traffic except Cloud Scheduler.

  Why it's wrong here

  Cloud Run is a fully managed serverless platform; instances are not deployed into a VPC, and VPC firewall rules do not apply to inbound traffic destined for Cloud Run. VPC connectors are used only for outbound connections from the service to VPC resources, not to control who can call the service. Even if a VPC were used, Cloud Scheduler has no fixed IP addresses to allow in a firewall rule. The service's ingress is controlled by IAM and by Google Front Ends, so the only valid way to restrict callers is via IAM-based authentication and authorization.

• ✗

  Add a secret header to Cloud Scheduler requests and validate it in the Cloud Run application code.

  Why it's wrong here

  Adding a secret header is an application-level custom authentication mechanism that is fragile and insecure. The header value must be stored and shared outside of IAM, making it vulnerable to leakage, and it can be brute-forced if the application does not implement additional protections. Cloud Run's built-in authentication, using OIDC tokens and IAM roles, is the standard, managed solution. A secret header also bypasses the service's IAM enablement—anyone who knows the header can invoke the service even when unauthenticated invocations are disabled.

Go deeper

Related to this question