Question

Difficulty: MediumSecrets Management and Service Account Lifecycle Security

An organization runs an automated database maintenance script on a Compute Engine virtual machine located in project `prod-workloads`. The script needs to retrieve a database password stored in Google Cloud Secret Manager within project `prod-secrets`. Company security policies strictly prohibit the creation and management of downloadable service account JSON keys. Which access management configuration follows Google-recommended best practices to allow the workload to authenticate while enforcing least privilege?

  1. Attach a dedicated service account to the Compute Engine instance in `prod-workloads` and grant that service account the Secret Manager Secret Accessor role (`roles/secretmanager.secretAccessor`) on the specific secret resource in `prod-secrets`.Answer
  2. B
    Attach a dedicated service account to the Compute Engine instance in `prod-workloads` and grant it the Service Account Admin role (`roles/iam.serviceAccountAdmin`) in `prod-secrets` so it can impersonate the secret owner service account.
  3. C
    Attach a dedicated service account to the Compute Engine instance in `prod-workloads` and grant it the Editor primitive role (`roles/editor`) at the project level on `prod-secrets`.
  4. D
    Configure Secret Manager in `prod-secrets` to use Customer-Supplied Encryption Keys (CSEK) and store the raw cryptographic key file on the local boot disk of the Compute Engine instance.

Answer

Attach a dedicated service account to the Compute Engine instance in `prod-workloads` and grant that service account the Secret Manager Secret Accessor role (`roles/secretmanager.secretAccessor`) on the specific secret resource in `prod-secrets`.
Attaching a dedicated service account to the VM instance allows the workload to automatically authenticate using Application Default Credentials (ADC) without requiring static JSON service account keys. Granting `roles/secretmanager.secretAccessor` directly on the targeted secret resource in the secret project enforces granular cross-project access following the principle of least privilege.

Step-by-Step Solution

1
Identify the authentication mechanism that avoids downloading static service account keys.
Using built-in service accounts attached to Compute Engine instances enables keyless authentication via metadata server and Application Default Credentials (ADC).
Security policy forbids downloadable service account keys.
2
Determine the minimal IAM role required to read secret values in Secret Manager.
The `roles/secretmanager.secretAccessor` role grants permission to read secret payloads without administrative rights over the secret metadata.
Least privilege principles dictate granting accessor roles rather than admin or editor roles.
3
Determine the resource scope for binding the IAM role across projects.
Bind the role directly to the specific secret resource in `prod-secrets` rather than applying project-wide broad permissions.
Resource-level IAM bindings prevent unnecessary exposure to other secrets stored in the same project.

Key Concept

Cross-Project Secret Manager Access using Service Account Metadata and Resource-Level IAM Roles
Rate this question