Google ACE Practice Question: A developer wants to verify which IAM roles they…

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 iam roles list --project=[PROJECT_ID]

  Why it's wrong here

  `gcloud iam roles list --project=[PROJECT_ID]` enumerates the role definitions that exist in the project — both predefined roles (e.g., roles/compute.admin) and any custom roles you created — but it does not inspect the project's IAM policy. Each listed entry shows metadata like role ID, title, permissions, and stage, not the principals (users, groups, or service accounts) that are assigned to the role. Therefore, this command cannot tell you who has which role on the project.

• ✓

  gcloud projects get-iam-policy [PROJECT_ID]

  Why this is correct

  `gcloud projects get-iam-policy [PROJECT_ID]` fetches the complete IAM policy object for the specified project, which is structured as a list of bindings where each binding maps one role to a set of members. The output includes the policy version, etag, and bindings, so you can see exactly which members are assigned each role (e.g., serviceAccount:..., user:...). This is the direct, correct way to query current member-role bindings on a project.

• ✗

  gcloud auth list --project=[PROJECT_ID]

  Why it's wrong here

  `gcloud auth list --project=[PROJECT_ID]` is used to display the accounts that are currently authenticated on your local gcloud SDK, such as your personal Google account or a service account key that has been activated, along with an ACTIVE indicator for the current credential. It performs no API call to Cloud IAM and returns no information about the project's policy or its members; the `--project` flag is not relevant to this local credential listing. Thus, it cannot reveal how roles are bound in the project.

• ✗

  gcloud iam service-accounts get-iam-policy [PROJECT_ID]

  Why it's wrong here

  `gcloud iam service-accounts get-iam-policy [PROJECT_ID]` is incorrectly scoped because this command expects a service account resource identifier (email or ID) as its positional argument, not a project ID, and it returns the IAM policy of that specific service account (e.g., who can use or manage that service account). The project ID passed here would be treated as a non-existent service account, and even if a valid service account were supplied, the output would be a resource-level policy, not the project-level member-role bindings.

Go deeper

Related to this question