Google ACE Practice Question: A developer accidentally committed a service…

Answer analysis

Option-by-option breakdown

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

• ✗

  Remove the committed file from Git history using `git filter-branch` or BFG Repo Cleaner.

  Why it's wrong here

  Rewriting Git history with filter-branch or BFG removes the key from future visible commits, but it does nothing about the key that was already exposed — secret scanners or anyone who cloned the repo may already have it. The key remains cryptographically valid, so an attacker can still use it to authenticate as the service account. Revocation is the only way to stop active misuse; history rewriting is a slow, error-prone follow-up cleanup step that should never substitute for immediately invalidating the credential.

• ✓

  Immediately delete or disable the service account key in the Cloud Console or via gcloud.

  Why this is correct

  Immediately deleting or disabling the service account key in the Cloud Console or with gcloud revokes the credential at the source, making it invalid for all OAuth token requests regardless of who possesses it. This is the highest-priority action because it stops ongoing unauthorized access in seconds and does not depend on how widely the key was distributed. After this containment step, you can investigate the exposure, rotate remaining keys, and audit usage logs without an active threat.

• ✗

  Make the GitHub repository private to hide the exposed key.

  Why it's wrong here

  Making the GitHub repository private limits who can see the key going forward, but it cannot undo a prior public exposure: the key may already be cached in audit logs, third-party mirrors, or attacker databases. Because the service account key is still active, anyone who obtained a copy before the repo was locked down can keep impersonating the service account. The correct containment action is to revoke the key itself, not to hide the artifact.

• ✗

  Reduce the service account's permissions to limit the blast radius.

  Why it's wrong here

  Reducing the service account's IAM roles narrows what an attacker can do with the compromised key, but the key itself still works for the reduced permissions set. This is a useful damage-limitation step after revocation, but it leaves the credential valid for direct token requests via the Google OAuth 2.0 endpoint. The first priority must be to invalidate the key entirely, because permission changes are reversible and do not terminate existing sessions or cached credentials.

Go deeper

Related to this question