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.

• ✓

  roles/secretmanager.secretAccessor

  Why this is correct

  roles/secretmanager.secretAccessor is the correct and minimal predefined role for service accounts that need to retrieve secret payloads. It includes the `secretmanager.versions.access` permission, which allows the caller to access the encryption-decrypted secret value from a specified version, and `secretmanager.versions.get` for metadata of that version. It does not permit creating, deleting, or modifying secrets, nor changing IAM policies, making it the exact role for a workload that reads a secret at runtime without administrative side effects.

• ✗

  roles/secretmanager.admin

  Why it's wrong here

  roles/secretmanager.admin grants the principal full control over the Secret Manager service, including creating, deleting, and updating secret resources, and—critically—the ability to set IAM policies on secrets. While it can also access secret values, granting it to a service account that merely needs to read a secret violates the principle of least privilege because it allows the account to permanently modify or revoke access for other principals. A reader should never be given administrative, policy-writing capabilities that extend beyond the immediate `secretAccessor` purpose.

• ✗

  roles/iam.serviceAccountUser

  Why it's wrong here

  roles/iam.serviceAccountUser is unrelated to Secret Manager; it grants permission to impersonate a service account (`iam.serviceAccounts.actAs`) so the caller can run jobs, start Compute Engine instances, or deploy resources that use that service account as their identity. It does not include any `secretmanager` permissions, so a service account with this role cannot read a secret value. Granting this role in response to a secret-access requirement is a common mix-up because it sounds 'user-like' but actually controls delegation, not resource data access.

• ✗

  roles/secretmanager.viewer

  Why it's wrong here

  roles/secretmanager.viewer is a read-only role, but it is limited to viewing metadata about secrets, their versions, labels, and IAM policies (e.g., `secretmanager.secrets.get`); it explicitly does not include the `secretmanager.versions.access` permission. Therefore, a principal with only the viewer role can see that a secret exists and list its versions, but the actual secret payload remains hidden. This role would leave a service account unable to fetch the value needed by the application, hence it is insufficient for the task of accessing a secret's contents.

Go deeper

Related to this question