Google ACE Practice Question: A Cloud Run service needs to read secrets from…

Answer analysis

Option-by-option breakdown

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

• ✗

  Grant `roles/secretmanager.admin` on the project.

  Why it's wrong here

  Granting `roles/secretmanager.admin` at the project level gives the principal full management control over every secret in the project, including creating, updating, deleting secrets, and setting IAM policies, in addition to all access permissions. This is a massive over-provisioning if the only requirement is reading one secret's value, and it violates the principle of least privilege by allowing the principal to alter or delete unrelated secrets. The administrator role should be reserved for users who manage secrets, not for applications that consume them.

• ✓

  Grant `roles/secretmanager.secretAccessor` on the specific secret resource.

  Why this is correct

  The `roles/secretmanager.secretAccessor` role contains the exact `secretmanager.versions.access` permission required to retrieve the value of a secret version. By binding this role to the specific secret resource rather than the project or the version, the principal is limited to reading only that secret's payload and cannot enumerate or access other secrets. This scoped binding is the standard least-privilege pattern for granting a compute instance or service account access to a single secret.

• ✗

  Grant `roles/viewer` on the project.

  Why it's wrong here

  The `roles/viewer` project role grants read access to most resource metadata, including secret details such as labels and create time, but it does not include `secretmanager.versions.access`, the permission that decrypts and returns the secret payload. Therefore, a viewer can see that a secret exists but cannot retrieve its value. This common misconception confuses metadata visibility with data access; Secret Manager deliberately separates these two authorization layers.

• ✗

  Grant `roles/secretmanager.secretVersionManager` on the secret.

  Why it's wrong here

  The `secretmanager.secretVersionManager` role includes permissions to create, disable, destroy, and list secret versions, but it does not include `secretmanager.versions.access`, which is the only permission that returns the secret's decrypted payload. Even when scoped directly to the secret resource, this role cannot be used to retrieve the secret value needed by the application. This separation of version lifecycle management from data access is intentional in Secret Manager's IAM model.

Go deeper

Related to this question