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.

• ✗

  Deploy with --allow-unauthenticated and set up a Pub/Sub subscription with OIDC token audience

  Why it's wrong here

  The `--allow-unauthenticated` flag disables IAM checks and permits any HTTP client, including the public internet, to invoke the Cloud Run service. Adding an OIDC token audience to the Pub/Sub subscription only affects the 'aud' claim of the token that Pub/Sub generates; it does not restrict who can reach the endpoint. The service remains exposed because unauthenticated requests are still accepted, so this is not a secure configuration.

• ✗

  Deploy with --no-allow-unauthenticated and create a VPC connector to allow Pub/Sub internal traffic

  Why it's wrong here

  A VPC connector only provides private networking capabilities, such as routing requests through a VPC network or assigning static IP addresses, but it does not authenticate or authorize callers. Pub/Sub push delivery always uses public HTTPS to reach the Cloud Run service URL, and with `--no-allow-unauthenticated`, IAM authentication still requires a valid identity token. The VPC connector does not supply or manage identity tokens, so Pub/Sub requests will be rejected with a 403 unless a service account is explicitly configured.

• ✓

  Deploy with --no-allow-unauthenticated and configure the Pub/Sub subscription to use a service account that has the roles/run.invoker role on the Cloud Run service

  Why this is correct

  Deploying with `--no-allow-unauthenticated` enforces that only authenticated requests carrying a valid OIDC token are accepted by the Cloud Run service. When the Pub/Sub subscription is configured with a service account that has the `roles/run.invoker` role on the service, Pub/Sub uses that identity to mint an OIDC token with the correct audience, and Cloud Run recognizes the token as authorized. This is the recommended secure pattern for triggering Cloud Run from Pub/Sub.

• ✗

  Use Cloud Functions instead, which is more secure for Pub/Sub triggers

  Why it's wrong here

  Choosing Cloud Functions does not fundamentally alter the security model, because Cloud Functions also requires explicit IAM roles and can be publicly exposed if configured with `--allow-unauthenticated`. The team's stated requirement is to deploy a microservice to Cloud Run, so switching to Cloud Functions changes the compute platform rather than solving the authentication problem. It also introduces a different execution environment and operational overhead, making it an irrelevant and non-compliant alternative.

Go deeper

Related to this question