Google ACE Practice Question: Order the steps to set up a Cloud IAM policy that…

Answer analysis

Option-by-option breakdown

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

• ✓

  Step 1: Identify the user (email) and the project ID. Step 2: Use gcloud to add IAM policy binding: `gcloud projects add-iam-policy-binding PROJECT_ID --member=user:EMAIL --role=roles/compute.admin` Step 3: Verify the binding using `gcloud projects get-iam-policy PROJECT_ID`. Step 4: Test access by having the user attempt to use Compute Engine resources.

  Why this is correct

  The correct sequence begins by identifying the exact user principal (email address) and the target project ID, because both are required parameters for any gcloud IAM command. Then `gcloud projects add-iam-policy-binding` creates a new binding between that principal and the `roles/compute.admin` role, modifying only the specified binding without touching unrelated bindings. Next, `gcloud projects get-iam-policy` retrieves the project's full IAM policy so you can confirm the binding is present and correctly associated with the user and role. Finally, having the user attempt to use Compute Engine resources verifies that the policy is effective in practice, not just present in the policy document.

• ✗

  Step 1: Use gcloud to set the IAM policy by reading the current policy, modifying it locally, and writing it back. Step 2: Identify the user and project. Step 3: Verify the binding. Step 4: Test access.

  Why it's wrong here

  This approach is incorrect because `gcloud projects set-iam-policy` replaces the entire IAM policy, so if a stale version of the policy was fetched before another change was made, you can accidentally remove other users' roles or service account permissions. Additionally, the sequence has the user and project identification occurring after a policy-modifying command, which means you would be attempting to set a policy without knowing the target resource and principal, or you would have to restart the process. The safer and simpler method is to identify the entities first and then use `add-iam-policy-binding`, which applies an incremental update and avoids the risk of clobbering the existing policy.

• ✗

  Step 1: Verify the binding using `gcloud projects get-iam-policy`. Step 2: Identify the user and project. Step 3: Use gcloud to add IAM policy binding. Step 4: Test access.

  Why it's wrong here

  Running `gcloud projects get-iam-policy` as the first step is logically invalid because the user and project have not yet been identified, so you cannot specify the correct project ID to query. More fundamentally, verifying a binding before it has been granted will only show the policy as it currently exists; until the `add-iam-policy-binding` step executes, there is no binding to verify, making the verification step meaningless. The correct order is to identify the principal and project, add the binding, then verify that the new binding appears in the resulting policy.

• ✗

  Step 1: Identify the user and project. Step 2: Test access to confirm no current access. Step 3: Use gcloud to add IAM policy binding. Step 4: Verify the binding.

  Why it's wrong here

  Pre-testing the user's access before granting the role is an unnecessary and misleading step: it does not affect the outcome, and the absence of access at that point is expected because the binding hasn't been added yet. This extra probe also slows down the process and could fail for unrelated reasons such as authentication issues or resource-specific errors, which would needlessly complicate troubleshooting. Grant the binding first, verify it, and only then test access if you want confirmation of the end-to-end behavior.

Go deeper

Related to this question