An engineer accidentally commits an active cloud credential and pushes it to your repo. Walk me through your response and what order you do things in.

technical-conceptual · Senior level · cloud-devops-security

What the interviewer is really asking

Assesses whether the candidate treats a committed live secret as compromised the instant it's pushed — rotate/revoke first, assess blast radius and check for use, then scrub history as secondary — and can reason about why deleting the commit is not remediation and how to prevent recurrence, rather than reaching for git history surgery first.

What to say

• Establish the mental model and the first action: a secret pushed to a repo is compromised the moment it lands — assume it's already scraped — so the first move is revoke/rotate the credential, not edit Git. Until it's revoked, nothing else you do matters because the key still works.
• Then assess and contain: figure out what that credential could reach, pull the cloud audit logs (CloudTrail and the like) to check whether it was already used, and treat any anomalous use as an incident with proper severity rather than assuming you caught it in time.
• Scrub and prevent last: removing it from history (git filter-repo / BFG, force-push, invalidate forks/caches) is a hygiene and compliance step, not the security fix; the recurrence fix is push protection plus pre-commit/server-side secret scanning so the next one is blocked before it lands.

What to avoid

• Reaching for git history rewriting first to 'remove' the secret — deleting the commit doesn't un-leak a credential that's already been pushed and likely scraped; the key still works until you revoke it.
• Assuming that because the repo is private, a quick force-push fixes it — it may already be in clones, forks, CI caches, and bot scrapers, so you must rotate regardless.
• Stopping at rotation without checking the audit logs for whether the credential was actually used, so you miss an active compromise.

Example answers

Strong: A pushed secret is compromised the instant it lands, so step one is revoke and rotate the credential — until that's done, scrubbing Git is pointless because the key still works and scrapers hit public and even private leaks fast. Step two is blast radius: what could it reach, and pull CloudTrail to see if it was already used; if it was, that's an incident with a real severity, not a near-miss. Only then do I scrub history with filter-repo and invalidate forks and caches — that's hygiene, not the fix. Then I turn on push protection and pre-commit scanning so the next one never lands.

Weak: I'd remove the credential from the repo and rewrite the Git history with filter-repo so the commit is gone, then force-push the clean history. Once it's no longer in the repo the secret isn't exposed anymore, so that handles it.