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.

• ✗

  Use gcloud iam service-accounts add-iam-policy-binding to grant the instance access.

  Why it's wrong here

  This command modifies the IAM policy that governs who can impersonate or manage the service account itself, granting roles on the service account resource. It does not cause a compute instance to assume that service account identity. The service account attached to an instance is a property of the instance resource, configured separately with set-service-account, not an IAM role binding.

• ✓

  Stop the instance, update it with the --service-account flag using gcloud compute instances set-service-account, then start it.

  Why this is correct

  Compute Engine requires an instance to be in the TERMINATED state before its service account can be changed, so you must stop the instance first. The gcloud compute instances set-service-account command updates the attached service account (and optionally the access scopes), and then you start the instance to apply the change. This approach preserves the existing VM, avoids resource recreation or workload migration, and is the documented way to attach a service account to an existing instance.

• ✗

  Use gcloud compute instances add-iam-policy-binding to assign the service account to the instance.

  Why it's wrong here

  The add-iam-policy-binding operation on an instance grants IAM principals permissions to perform actions on that instance resource, such as compute.instances.get or compute.instances.delete. It does not select or change the service account that the VM uses to authenticate outbound API calls. Assigning a service account to an instance is an attribute update performed via set-service-account, not a policy binding on the instance itself.

• ✗

  Create a new instance with the service account and migrate the application.

  Why it's wrong here

  Creating a new instance with the desired service account and migrating the application would eventually work, but it is a far heavier operation than necessary. It forces full VM re-creation, requires copying or reattaching disks, reconfiguring network interfaces, and risks downtime during migration. Since the existing instance can be updated in-place with set-service-account while stopped, the rebuild-and-migrate approach is unnecessary and not the recommended best practice.

Go deeper

Related to this question