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 my-project --member user:admin@other-project.com --role roles/storage.objectViewer

  Why it's wrong here

  This binds roles/storage.objectViewer to a Google Account user (admin@other-project.com), not to a service account, so it fails the requirement entirely. Even though the target project is correctly my-project, the `--member` prefix `user:` indicates a human identity, and a service account would need the `serviceAccount:` prefix with its IAM email. Granting a role to this user does not give sa@other-project.iam.gserviceaccount.com any access to my-project's Container Registry artifacts.

• ✗

  gcloud iam service-accounts add-iam-policy-binding sa@other-project.iam.gserviceaccount.com --member serviceAccount:sa@other-project.iam.gserviceaccount.com --role roles/storage.objectViewer

  Why it's wrong here

  This uses the wrong gcloud command and resource target: `gcloud iam service-accounts add-iam-policy-binding` modifies the IAM policy of the service account itself, not the IAM policy of my-project or its Cloud Storage/GCR repository. The binding grants the service account the viewer role on its own service account resource, which controls who can view/use that service account, not read access to image artifacts in my-project. The correct operation must target the project that owns Container Registry (my-project) via `gcloud projects add-iam-policy-binding`.

• ✗

  gcloud projects add-iam-policy-binding other-project --member serviceAccount:sa@other-project.iam.gserviceaccount.com --role roles/storage.objectViewer

  Why it's wrong here

  This targets the wrong project in the policy binding command. Adding roles/storage.objectViewer to the service account on `other-project` only affects IAM policies for resources owned by other-project; the Container Registry repository being accessed lives in my-project. Cross-project access requires the binding to be on the resource-owning project, my-project, with the service account listed as the member. Therefore this command leaves the service account without any access to my-project's GCR storage.

• ✓

  gcloud projects add-iam-policy-binding my-project --member serviceAccount:sa@other-project.iam.gserviceaccount.com --role roles/storage.objectViewer

  Why this is correct

  This correctly adds an IAM policy binding on my-project, which owns the Container Registry artifacts, and defines the member as the service account from other-project using the `serviceAccount:` prefix. Since `roles/storage.objectViewer` grants read access to Cloud Storage objects that back GCR, this allows sa@other-project.iam.gserviceaccount.com to pull images and list repositories in my-project without needing a key or user account. The binding is cross-project: the member belongs to other-project, but the resource is in my-project, which is exactly the required configuration.

Go deeper

Related to this question