Google ACE Deploying and Implementing a Cloud Solution Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Create a Serverless VPC Access connector and configure the Cloud Run service to use it for all outbound traffic.

  Why it's wrong here

  A Serverless VPC Access connector allows Cloud Run services to reach resources in a VPC network, but it controls outbound traffic from Cloud Run, not inbound access to it. The requirement is to restrict incoming requests to the backend API. Using a connector does not prevent public access to the Cloud Run service; it only enables private connectivity from the service to other VPC resources.

• ✗

  Configure the backend Cloud Run service with --allow-unauthenticated and rely on firewall rules to block external traffic.

  Why it's wrong here

  --allow-unauthenticated makes the Cloud Run service publicly accessible, and VPC firewall rules do not apply to Cloud Run's managed ingress. Cloud Run has its own ingress controls, and allowing unauthenticated access would expose the service to the internet regardless of firewall rules. This violates the security requirement and does not restrict access to the frontend service alone.

• ✓

  Deploy the Cloud Run service with --ingress=internal and --no-allow-unauthenticated.

  Why this is correct

  Setting --ingress=internal restricts traffic to sources within the same project or VPC network, blocking public internet access. --no-allow-unauthenticated requires authentication for all requests, ensuring that only authorized callers can invoke the service. This combination enforces both network-level and identity-level restrictions, which is necessary to prevent public access while allowing the frontend to authenticate.

• ✓

  Grant the frontend's service account the Cloud Run Invoker role on the backend Cloud Run service.

  Why this is correct

  When a Cloud Run service requires authentication, callers must present a valid identity token, and the caller's identity must have the Cloud Run Invoker role on the service. Granting this role to the frontend instances' service account allows them to obtain an identity token from the metadata server and authenticate to the backend. Without this role, the frontend would receive HTTP 403 errors even with a valid token.

• ✗

  Set up a private Service Connect endpoint for the Cloud Run service and configure the frontend to use it.

  Why it's wrong here

  Private Service Connect can provide private connectivity to Cloud Run services, but it is typically used for consuming services across VPC networks or projects. It does not replace the need to set ingress controls and authentication on the Cloud Run service itself. Additionally, configuring Private Service Connect for a Cloud Run service requires additional setup and is not the minimal or standard approach for restricting access from a frontend in the same project.

Go deeper

Related to this question