Examkin

Question

Difficulty: HardManaging IAM Roles and Permissions

An application deployed on a Compute Engine virtual machine in a Google Cloud project named `payments-service-prod` requires access to database credentials stored in Secret Manager. The application's service account must be able to read secret payload values at runtime to establish database connections. To meet strict enterprise security guidelines, the service account must not be granted permissions to modify secrets, create new secrets, or access resources in any other projects. Which IAM role binding strategy adheres to the principle of least privilege while fulfilling these requirements?

  1. Grant the service account the Secret Manager Secret Accessor role (roles/secretmanager.secretAccessor) resource binding on the payments-service-prod project.Answer
  2. B
    Grant the service account the primitive Viewer role (roles/viewer) resource binding on the payments-service-prod project.
  3. C
    Grant the service account the Secret Manager Secret Accessor role (roles/secretmanager.secretAccessor) resource binding at the parent Folder level containing payments-service-prod.
  4. D
    Grant the service account the Secret Manager Admin role (roles/secretmanager.admin) resource binding on the payments-service-prod project.

Answer

Grant the application service account the predefined Secret Manager Secret Accessor role (`roles/secretmanager.secretAccessor`) bound specifically at the project level (`payments-service-prod`).
The Secret Manager Secret Accessor role (`roles/secretmanager.secretAccessor`) provides the exact permission (`secretmanager.versions.access`) required to retrieve secret payload values. Binding this role specifically at the project resource level ensures access is limited to secrets inside `payments-service-prod` without over-granting permissions or broad inheritance across sibling projects.

Step-by-Step Solution

1
Identify required permission capability
The application needs to read secret payload values at runtime (`secretmanager.versions.access`).
Reading secret payload values requires specific data access permissions rather than secret metadata viewing or administration.
2
Select the narrowest predefined IAM role
The Secret Manager Secret Accessor role (`roles/secretmanager.secretAccessor`) grants payload access without granting secret creation or modification permissions.
Using predefined roles enforces the principle of least privilege over broad primitive roles (such as Viewer or Editor) or administrative roles (such as Secret Manager Admin).
3
Determine proper resource hierarchy scope
Bind the role at the project level (`payments-service-prod`).
Assigning permissions at the project level restricts access to secrets within that project and prevents inheritance leakage to other projects under the parent folder.

Key Concept

Principle of Least Privilege with Predefined IAM Roles and Hierarchy Scoping
Estimated Time:2m 0s
Rate this question

Topics

Managing IAM Roles and Permissions

More questions from this topic