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.

• ✓

  gcloud projects add-iam-policy-binding

  Why this is correct

  gcloud projects add-iam-policy-binding PROJECT_ID --member=user:email@example.com --role=roles/viewer is the correct command because it performs an additive update to the project's IAM policy. It reads the current policy, appends the new binding (role + member) to the existing set, and writes the merged policy back atomically, leaving all other bindings untouched. This is the standard CLI operation for granting a specific role to a user at the project scope.

• ✗

  gcloud iam service-accounts add-iam-policy-binding

  Why it's wrong here

  gcloud iam service-accounts add-iam-policy-binding operates on the IAM policy attached to a service account resource, not the project. If you run it, you are granting permissions on that service account (e.g., roles/iam.serviceAccountUser or roles/iam.serviceAccountAdmin) to a principal, which is a different object entirely. To add a binding to the project, the target resource must be the project, identified by a project ID or number, not a service account email. Therefore, it does not achieve the goal of adding a binding to a project's IAM policy.

• ✗

  gcloud projects set-iam-policy

  Why it's wrong here

  gcloud projects set-iam-policy replaces the entire IAM policy for the project with the policy supplied in a JSON or YAML file via the --policy-file flag. Because it is a full overwrite, invoking it to add a single binding without including the current bindings would delete all existing grants and could cause an accidental service outage or lockout. The correct approach is to use an additive command like add-iam-policy-binding; set-iam-policy is intended for complete policy management, such as during infrastructure-as-code deployments where you know the full desired state.

• ✗

  gcloud iam roles update

  Why it's wrong here

  gcloud iam roles update modifies the definition of a custom role, such as roles/my.customRole, by changing its included permissions, title, or description. This command does not touch any resource's IAM policy, so it cannot grant a role to a user on a project. Bindings are separate from role definitions; a role must already exist with the desired permissions, and then you bind that role to members on a specific resource. Thus, this command is irrelevant to the task of adding an IAM binding to a project.

Go deeper

Related to this question