Google ACE Practice Question: A security team discovers that a 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 service account key to generate a new one, keeping the old key active briefly for transition

  Why it's wrong here

  Rotating the key while keeping the old key active for transition leaves the leaked credential valid during that entire period, which defeats the purpose of containment. In GCP, a proper rotation means creating a new key and immediately deleting the compromised one, not overlapping their validity. Because the leaked key has already been exposed, an attacker can use it to mint access tokens until it is deleted, so the only safe action is to delete the old key right now, then create a replacement key to restore service.

• ✓

  Delete the leaked key immediately, audit Cloud Audit Logs for unauthorized activity using the key, then create a new key or switch to keyless authentication

  Why this is correct

  Deleting the compromised service account key immediately revokes the attacker's primary authentication credential, effectively cutting off their direct API access through that key. After deletion, audit Cloud Audit Logs—specifically the Data Access and Admin Activity logs—to determine whether the key was used to call any GCP APIs, identify the scope of exposure, and check for unusual patterns such as token creation or IAM changes. Then issue a new key if the workload still requires a long-lived credential, or better, eliminate static keys entirely by adopting keyless authentication such as Workload Identity Federation, which binds short-lived credentials to the workload's identity.

• ✗

  Change the service account's display name and email to invalidate the leaked key

  Why it's wrong here

  Changing the service account's display name or email is purely a metadata operation that does not affect the underlying cryptographic key material or the key's validity. The leaked key is an RSA private key that remains bound to the service account's ID; it will continue to authenticate as the service account until it is explicitly deleted or rotated. Moreover, the service account's email is immutable and cannot be changed, and an attacker who still holds the key can simply ignore the new display name and keep calling the IAM generateAccessToken API to obtain fresh tokens.

• ✗

  Remove all IAM roles from the service account to deny all actions until the investigation completes

  Why it's wrong here

  Removing IAM roles from the service account temporarily prevents the key from authorizing actions, but the leaked key still exists and can be used to request OAuth2 tokens whenever roles are re-added. The secret is compromised, not just the permissions; as long as the key remains, it is a credential that an attacker can present to obtain any future access granted to that service account. A proper first response must delete or invalidate the key itself, with IAM role removal as an additional containment measure, not a substitute.

Go deeper

Related to this question