Cloud Digital Leader Trust and security with Google Cloud Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Delete the commit from GitHub history using git rebase; the key is safe once removed from the repository

  Why it's wrong here

  GitHub history cannot reliably be purged — the data may already be cached, indexed, or copied. Even if removed from history, the key must be treated as compromised because it was publicly visible. Deletion from Git history is not a remediation; revocation of the key is.

• ✓

  Immediately revoke/delete the exposed service account key in Google Cloud IAM, review Cloud Audit Logs for unauthorized access, and generate a new key distributed through secure channels

  Why this is correct

  This is the complete correct response: (1) Revoke the key immediately to stop any ongoing unauthorized access. (2) Review Admin Activity and Data Access audit logs to determine if the key was used after exposure. (3) Issue a new key through a secure distribution channel (ideally Secret Manager, not environment variables). Time to revocation is critical.

• ✗

  Change the service account's permissions to read-only to limit the damage from potential misuse

  Why it's wrong here

  Reducing the service account's IAM roles to viewer or read-only narrows what an attacker can do after authenticating with the stolen key, but it does nothing to stop the authentication itself — the key remains cryptographically valid. An attacker who obtained the private key can still impersonate the service account and invoke any allowed method; moreover, legitimate workloads breaking due to permission changes creates urgency to revert, potentially leaving the key exposed longer. The only proper control is to delete the key as soon as exposure is known, then reissue a new key via Secret Manager and redeploy, because a leaked credential is always treated as compromised regardless of subsequent authorization changes.

• ✗

  Send an internal email informing the security team and wait for their guidance before taking any action

  Why it's wrong here

  Pausing for internal escalation before revocation is operationally indefensible: authentication with the exposed key is already possible for anyone who extracted it, and IAM does not retroactively invalidate credentials based on access patterns. The security team's guidance can be solicited in parallel, but the immediate, unambiguous act of deleting the key in the IAM console or via the API (projects.serviceAccounts.keys.delete) must never be deferred for process reasons. Any delay, even minutes, extends the risk window for an attacker to call Cloud APIs, exfiltrate data, or pivot to other resources using the compromised identity.

Go deeper

Related to this question