Google ACE Configuring Access and Security Practice Question
A company wants to allow developers to create and manage secrets in Secret Manager, but prevent them from viewing secret values. Which TWO predefined roles should be combined to achieve this?
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
✓
roles/secretmanager.secretManager
The roles/secretmanager.admin role includes permissions to create and manage secrets but not to access secret versions (i.e., view values). However, it includes the permission to access versions. Actually, the admin role includes secretmanager.versions.access, so it can view values. To separate manage from view, you need roles/secretmanager.secretVersionManager (manage versions without access) and roles/secretmanager.secretManager (manage secrets). Wait, the correct combination is roles/secretmanager.secretVersionManager (create/disable/destroy versions) and roles/secretmanager.secretManager (create/update/delete secrets). Neither includes secretmanager.versions.access. The roles/secretmanager.viewer allows viewing metadata but not values. The roles/secretmanager.secretAccessor allows accessing versions. To manage without viewing, combine roles that exclude access. Check accurate roles: roles/secretmanager.admin includes all permissions including access. roles/secretmanager.secretManager includes manage secrets but not access versions? Let's verify: roles/secretmanager.secretManager has permissions: secretmanager.secrets.create, secretmanager.secrets.delete, secretmanager.secrets.get, secretmanager.secrets.update, secretmanager.secrets.list. It does NOT include secretmanager.versions.access. roles/secretmanager.secretVersionManager has permissions: secretmanager.versions.create, secretmanager.versions.disable, secretmanager.versions.destroy, secretmanager.versions.enable, secretmanager.versions.get, secretmanager.versions.list. It does NOT include secretmanager.versions.access. So combining these two roles allows managing secrets and versions but not accessing the payload. roles/secretmanager.viewer allows viewing metadata but not accessing payload. roles/secretmanager.secretAccessor allows accessing payload. So the correct two are secretManager and secretVersionManager.
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.admin
Why it's wrong here
roles/secretmanager.admin is a superset role that includes every Secret Manager permission, most critically secretmanager.versions.access, which returns the decrypted secret payload. Granting this to developers would allow them to read actual secret values, directly violating the requirement to prevent access to secret data. This role is too broad for lifecycle managers who should never see the secrets themselves.
- ✗
roles/secretmanager.secretAccessor
Why it's wrong here
roles/secretmanager.secretAccessor is narrowly scoped to retrieving secret versions and their payloads via secretmanager.versions.access. It grants no permissions to create, update, or delete secrets, so developers would be able to see secret values but would be unable to perform the required lifecycle management. This role is the opposite of what is needed, as it exposes secret data while lacking management capabilities.
- ✓
roles/secretmanager.secretManager
Why this is correct
roles/secretmanager.secretManager grants permissions to create, get, list, update, and delete secret resources, plus view metadata, but deliberately omits secretmanager.versions.access. This lets developers fully manage the secret lifecycle without ever being able to view the sensitive payload, making it the correct least-privilege choice for the stated requirement to create and manage secrets while preventing access to values.
- ✓
roles/secretmanager.secretVersionManager
Why this is correct
roles/secretmanager.secretVersionManager focuses on managing secret versions—creating, disabling, destroying, getting, and listing versions—while explicitly excluding payload access via secretmanager.versions.access. Although it avoids exposing secret values, it lacks permissions to create or delete the top-level secret resource itself, so developers could not create and manage secrets at the secret level, only manage their versions. This role is useful for version rotation but not for full secret lifecycle ownership.
- ✗
roles/secretmanager.viewer
Why it's wrong here
roles/secretmanager.viewer grants read-only access to secret metadata such as name, labels, replication, and create time, but includes no write, update, delete, or version-management permissions. Developers would be unable to create or manage secrets, and while this role also prevents payload access, it is far too restrictive for someone who needs to build and maintain the secret lifecycle.
Go deeper
Related to this question
About these practice questions
One of 775 original ACE practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.