Examkin

Question

Difficulty: HardSecrets Management and Service Account Lifecycle Security

A health-tech company hosts a data ingestion microservice on Google Cloud Compute Engine Managed Instance Groups (MIGs) in Project A. The microservice needs to access sensitive third-party API credentials stored in GCP Secret Manager located in a central security project (Project B). The security team mandates strict enforcement of least privilege, zero exposure of static service account key JSON files, and proper service account lifecycle controls. Which TWO actions should the Lead Cloud Architect recommend to establish a secure authentication and access pattern? (Select TWO)

  1. Attach a dedicated custom service account to the Compute Engine instances and grant it the Secret Manager Secret Accessor role (`roles/secretmanager.secretAccessor`) strictly on the target secret resource in Project B.Answer
  2. B
    Assign the primitive Editor role (`roles/editor`) to the Compute Engine Default Service Account at the project level to simplify cross-project resource access.
  3. Configure cross-project service account impersonation by granting the caller service account in Project A the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`) on the resource identity in Project B.Answer
  4. D
    Grant the caller service account in Project A the Service Account Admin role (`roles/iam.serviceAccountAdmin`) on the target service account to manage impersonation and service account lifecycle credentials.
  5. E
    Require the application to manage raw encryption keys locally using Customer-Supplied Encryption Keys (CSEK) to encrypt secret values before uploading them to Secret Manager.

Answer

The architect should attach a dedicated custom service account to the compute instances with the Secret Manager Secret Accessor role granted on the specific secret resource, and configure cross-project impersonation using the Service Account Token Creator role.
Securing Secret Manager access and service account lifecycles requires using dedicated custom service accounts with narrow IAM roles. Assigning the Secret Manager Secret Accessor role directly on the targeted secret resource enforces granular access control. For cross-project identity delegation without downloading keys, granting the Service Account Token Creator role enables short-lived impersonation while maintaining strict governance.

Step-by-Step Solution

1
Identify compute identity requirements
Avoid using default service accounts and static service account JSON keys by creating a dedicated custom service account attached to Compute Engine VMs.
Default service accounts often carry broad permissions, and static key files create credential leakage risks.
2
Apply least-privilege secret access
Grant `roles/secretmanager.secretAccessor` at the secret resource level rather than the project level.
Restricting access to the specific secret prevents the service account from accessing other secrets or modifying secret metadata.
3
Configure cross-project identity delegation
Grant `roles/iam.serviceAccountTokenCreator` on the target service account to generate short-lived OAuth2/ID tokens.
Token creation allows keyless impersonation across GCP projects without assigning excessive administrative privileges.

Key Concept

Service Account Lifecycle & Least-Privilege Secret Access
Rate this question

Topics

Secrets Management and Service Account Lifecycle Security

More questions from this topic