Google ACE Practice Question: A security review identifies that service account…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Rotate the key files every 90 days and redistribute them securely

  Why it's wrong here

  Rotating key files every 90 days reduces the exposure window if a key leaks but leaves the fundamental vulnerability in place: a private key file still lives on developer laptops, CI/CD systems, or application servers. Each rotation triggers a new secure distribution process, which itself introduces opportunties for interception or accidental disclosure. Google recommends against long-lived service account keys altogether; using metadata server tokens or service account impersonation provides short-lived credentials that rotate automatically and require no key distribution.

• ✗

  Encrypt the JSON key files using Cloud KMS before distributing

  Why it's wrong here

  Encrypting JSON key files with Cloud KMS before distribution merely adds a layer of obfuscation while assuming the key must exist; the application still has to call Cloud KMS to decrypt the key at runtime, which requires a separate credential and IAM permission to access the KMS key. Once decrypted, the key material is written to local memory or disk, so a host compromise yields both the encrypted key and the ability to decrypt it. This is a defense-in-depth measure that reduces risk slightly, but it does not eliminate the danger inherent in using service account keys.

• ✓

  Remove the key files and use service account impersonation or Workload Identity for workloads that need GCP access

  Why this is correct

  The correct approach is to eliminate service account key files entirely. For workloads on GCE or GKE, attach a service account to the resource and let the metadata server provide OAuth2 tokens automatically; GKE can use Workload Identity to bind a Kubernetes service account to a Google service account. For external or on-premises workloads, configure Workload Identity Federation to exchange tokens from an external identity provider for short-lived GCP access tokens. This removes the risk of private key material being stolen and relies on IAM to define exactly which identities get which permissions.

• ✗

  Store the key files in Secret Manager and retrieve them at application startup

  Why it's wrong here

  Storing the JSON key in Secret Manager and loading it at application startup improves key management but still requires the raw key material to exist in the application's runtime environment. Every time the service starts, it must retrieve or decrypt the key and hold it in memory, so if the process or container is compromised the key can be exfiltrated. Secret Manager is appropriate for storing secrets, but it doesn't address the core problem: a long-lived service account key should not exist at all when GCP-native short-lived credentials are available.

Go deeper

Related to this question