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.

• ✓

  gcloud run deploy my-service --image gcr.io/my-project/my-image --service-account my-sa@my-project.iam.gserviceaccount.com --platform managed

  Why this is correct

  Using the `--service-account` flag with `gcloud run deploy` explicitly assigns the specified IAM service account as the runtime identity for the Cloud Run service. This is the correct syntax because the flag is designed to set the service account that the container will run as, and `--platform managed` ensures the command targets Cloud Run (fully managed) rather than other platforms. The deployed service will inherit the IAM permissions of `my-sa@my-project.iam.gserviceaccount.com`, which is exactly what the DevOps engineer needs.

• ✗

  gcloud run deploy my-service --image gcr.io/my-project/my-image --account my-sa@my-project.iam.gserviceaccount.com

  Why it's wrong here

  The `--account` flag in gcloud is used to override the active user account for the gcloud CLI session, not to set the identity of the deployed service. When you pass a service account email to `--account`, gcloud attempts to authenticate the CLI itself with that identity, which will fail or be ignored in most contexts because it expects a user account or a key that matches the CLI's authentication configuration. To bind a service account to a Cloud Run service, the correct flag is `--service-account`, not `--account`.

• ✗

  gcloud run deploy my-service --image gcr.io/my-project/my-image --impersonate-service-account my-sa@my-project.iam.gserviceaccount.com

  Why it's wrong here

  The `--impersonate-service-account` flag enables gcloud commands to act on behalf of that service account for the duration of the CLI operation, but it does not configure the Cloud Run service's own runtime identity. Even if impersonation is successful, the deployed service will still run with the default compute engine service account unless `--service-account` is specified. This flag is useful for temporarily granting the caller elevated permissions to run gcloud commands, but it is the wrong tool for defining the microservice's long-term IAM identity.

• ✗

  gcloud run deploy my-service --image gcr.io/my-project/my-image

  Why it's wrong here

  This command works but omits the `--service-account` flag, so Cloud Run automatically assigns the default compute engine service account (e.g., `PROJECT_NUMBER-compute@developer.gserviceaccount.com`) as the runtime identity. That default service account typically has broad or overly permissive access to project resources, which violates the principle of least privilege and is often unacceptable for production microservices. The DevOps engineer's intent is to use a dedicated service account (`my-sa@...`), which requires the explicit `--service-account` flag to override the default.

Go deeper

Related to this question