Answer: 1. Create a general service account “g-sa” to orchestrate the batch jobs. 2. Create one service account per batch job “b-sa-[1-5]”, and grant only the permissions required to run the individual batch jobs to the service accounts. 3. Grant the Service Account Token Creator role to g-sa. Use g-sa to obtain short-lived access tokens for b-sa-[1-5] and to execute the batch jobs with the permissions of b-sa-[1-5].

Option D is correct because it best adheres to the principle of least privilege. It creates separate service accounts for each batch job (b-sa-[1-5]) with only the permissions needed for their specific tasks, minimizing the attack surface. The general service account (g-sa) acts as an orchestrator with the Service Account Token Creator role, allowing it to generate short-lived tokens for the batch job service accounts. This eliminates the need for long-lived credentials (unlike Option A, which stores service account keys in Secret Manager, creating security risks) and avoids granting excessive permissions to a single account (unlike Option B, which gives all batch job permissions to g-sa). Option C is overly complex for this Compute Engine VM scenario, as Workload Identity Federation is typically used for external identity providers rather than GCP-native workloads. The community discussion strongly supports D, with 100% consensus and upvoted comments emphasizing least privilege and the security benefits of short-lived tokens over stored keys.

Author: LeetQuiz Editorial Team