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.

• ✗

  Add the auditor's email as a member with the Storage Admin role on the project.

  Why it's wrong here

  Storage Admin (roles/storage.admin) grants full read/write/delete permissions on all Cloud Storage buckets and objects in the project, as well as the ability to configure bucket IAM policies. For an external auditor, this massively exceeds the principle of least privilege, exposing the organization to accidental or malicious data deletion or permission changes. A read-only role such as Storage Object Viewer is the appropriate baseline, and even then should be scoped to specific buckets using IAM Conditions.

• ✗

  Use a signed URL for each object the auditor needs to see.

  Why it's wrong here

  Signed URLs provide time-bound, HMAC-signed links to a single object or, at most, a small set of explicit objects, and they grant access to anyone holding the URL without requiring a Google identity. They are not a governance mechanism for ongoing, auditable read access to a set of buckets: each object needs a separate URL, new URLs must be generated when the auditor returns, and URL expiration forces constant re-issuance. For an ongoing audit requirement, IAM with a scoped read-only role is more manageable, secure, and centrally revocable.

• ✗

  Add the auditor's email as a member with the Storage Object Viewer role on each individual bucket.

  Why it's wrong here

  Adding the auditor as Storage Object Viewer (roles/storage.objectViewer) individually on each bucket is functionally correct, providing read-only access to those buckets, but it becomes unmanageable when many buckets are involved because each bucket's IAM policy must be edited separately for every access change. There is also no central view of the auditor's effective permissions, making it easy to accidentally miss a bucket or leave stale access behind. A project-level role with an IAM Condition that matches only the intended bucket names achieves the same read-only scope from a single policy point, simplifying management and audit.

• ✓

  Add the auditor's email as a member with the Storage Object Viewer role on the project, and use IAM Conditions to restrict access to specific bucket resources.

  Why this is correct

  Assigning Storage Object Viewer at the project level grants read-only access to all objects in all buckets by default, but binding that grant with an IAM Condition that checks the resource name (e.g., resource.name.startsWith("projects/_/buckets/audit-")) restricts the access to exactly the intended buckets at access time. The auditor can then list and read objects only within those matches, while the project-level policy remains a single, centrally managed binding that can be audited and adjusted without touching each bucket. This delivers the least-privilege read-only guarantee the auditor needs while keeping operations scalable and governance clean.

Go deeper

Related to this question