Google ACE Configuring Access and Security Practice Question
A DevOps engineer needs to grant a service account the ability to pull images from a specific Container Registry repository in project 'my-project'. The service account is in project 'other-project'. Which command should the engineer use?
⚠ Common exam trap
The trap is confusing the resource the policy is bound to (must be the project owning the registry) with the member's home project, and confusing service-account-level IAM bindings (who can use the SA) with project-level bindings (what the SA can do).
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
gcloud projects add-iam-policy-binding my-project --member serviceAccount:sa@other-project.iam.gserviceaccount.com --role roles/storage.objectViewer
To grant a service account from 'other-project' permission to pull images from a repository in 'my-project', the IAM policy binding must be applied to the resource-owning project ('my-project') with the service account as the member. Option D does exactly this: it binds roles/storage.objectViewer on my-project to the service account from other-project.
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
Learn chapter
Cloud Storage Retention Policies and Locks
Key term
IAM policy
An IAM policy is a set of rules that determines who can access specific cloud resources and what actions they are allowed to perform.
Key term
Container
A container is a lightweight, standalone software package that includes everything needed to run an application, such as code, runtime, system tools, and libraries.
About these practice questions
Courseiva writes every ACE question from scratch — 775 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Google Cloud exam blueprint
This ACE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the ACE exam.