Google ACE Practice Question: Refer to the exhibit

Exhibit

{
  "bindings": [
    {
      "role": "roles/compute.instanceAdmin.v1",
      "members": [
        "user:admin@example.com",
        "serviceAccount:my-sa@project.iam.gserviceaccount.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "user:admin@example.com"
      ]
    }
  ]
}

Refer to the exhibit. A user 'admin@example.com' attempts to create a Compute Engine instance but fails with a permission error. Which permission is missing?

⚠ Common exam trap

Google Cloud often tests the `iam.serviceAccounts.actAs` permission as a hidden requirement, trapping candidates who assume that `compute.instances.create` alone is sufficient for instance creation with a service account.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

iam.serviceAccounts.actAs

The error occurs because when a user creates a Compute Engine instance with a service account, they need the `iam.serviceAccounts.actAs` permission on that service account. This permission allows the user to impersonate the service account and delegate its identity to the instance. Without it, the creation fails even if the user has `compute.instances.create`.

Answer analysis

Option-by-option breakdown

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

✗
compute.instances.get
Why it's wrong here
compute.instances.get lets you read instance metadata and status, and it is already granted via roles/compute.instanceAdmin.v1 to this user. This permission is read-only and has nothing to do with provisioning resources or authorizing a service account identity. Merely viewing an instance cannot satisfy the IAM check that Compute Engine performs when attaching a service account at creation time, so this is not the missing permission.
✓
iam.serviceAccounts.actAs
Why this is correct
iam.serviceAccounts.actAs is the 'Service Account User' permission, required to delegate the new instance's identity to a specific service account. Even with compute.instanceAdmin.v1, Compute Engine's authorization layer checks whether the caller can 'actAs' the service account on the project; without this, the create request is denied with a permissions error. Granting this on the service account (or project) allows the user to create instances that run as that service account, making it the exact missing permission.
✗
compute.instances.create
Why it's wrong here
compute.instances.create is certainly necessary to provision any VM, and it is already present in the compute.instanceAdmin.v1 role the user holds. However, this permission only authorizes the creation of the instance resource itself, not the binding of a service account to it. The failure occurs specifically at the actAs check, not at the create permission, so this is not the missing piece.
✗
compute.instances.setServiceAccount
Why it's wrong here
compute.instances.setServiceAccount is used to change the service account on an existing instance, typically requiring the instance to be stopped first. It is neither part of compute.instanceAdmin.v1 nor required during the initial creation flow. Since the user is trying to create a new instance, this permission is irrelevant; the missing grant is the actAs permission on the service account.

Go deeper

Google ACE Practice Question: Refer to the exhibit

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question