Google ACE Configuring Access and Security 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 custom role and assign it to the instance's service account through the instance metadata.

  Why it's wrong here

  Instance metadata is a key-value store for instance attributes like startup scripts, not a mechanism for IAM authorization. A custom role must be bound to the service account through an IAM policy on the project, folder, or resource being accessed; putting a role name in metadata has no effect on IAM's permissions engine. Therefore, this approach fails to grant the service account any permissions.

• ✓

  Use gcloud compute instances create with the --service-account flag pointing to the custom service account.

  Why this is correct

  When creating an instance, you must specify the service account with `gcloud compute instances create --service-account <SA_EMAIL>`, which attaches that identity to the instance for its entire lifetime. Once attached, the instance metadata server returns OAuth credentials for that service account, so all API calls from the instance are made as that identity. This is the correct way to ensure the instance uses a custom, least-privileged service account, provided the account has been granted the necessary IAM roles.

• ✗

  Set the project-wide default service account to the custom service account in the project settings.

  Why it's wrong here

  Compute Engine has a built-in default service account per project, but it is not configurable as a project-wide default in project settings; instances use it only when no explicit service account is provided at creation. There is no project setting to change that default to a custom service account, and even if there were, it would apply to all instances, not just the one needing the custom account. You must explicitly choose the custom service account for each instance individually.

• ✗

  Create a startup script that configures the instance to use the custom service account after boot.

  Why it's wrong here

  A startup script runs post-boot and cannot alter the service account the instance was created with, because that identity is fixed by the instance metadata server and is used for all credential requests. At most, a startup script could run `gcloud auth login` or generate its own keys, but that would not change the instance's actual service account identity for API calls like GCS or Cloud SQL. The only proper time to set or change the service account is at creation, or on a stopped instance via the `set-service-account` API.

Go deeper

Related to this question