Q: A developer accidentally committed an AWS access key and pushed it to the public repo. The team noticed 30 minutes later. What's the correct response, in priority order?

Treat the credential as compromised the moment it touches a public surface. Order matters:

• Rotate the credential first, before anything else. In AWS IAM, deactivate the leaked key and issue a new one. Anything you do to Git history is secondary — the key was public for 30 minutes, scrapers are constant, and assume it was harvested.
• Audit usage. Check CloudTrail for any calls authenticated with that key — region, source IP, services touched. If anything looks suspicious, escalate to security.
• Remove the secret from history. A plain git revert is not enough — the file is still in old commits in .git/objects and visible on GitHub forever. Use git filter-repo (the modern replacement for filter-branch):

or --replace-text to redact a string everywhere. Then force-push (this rewrites history; coordinate with the team). The order is non-negotiable: rotate → audit → scrub → prevent. Reversing 1 and 3 is a common mistake — you can't un-leak a key, but you can stop it from being valid. --- ## 🔴 Advanced

git filter-repo --path secrets.env --invert-paths

• Invalidate forks and caches. GitHub caches the SHA — open a support ticket asking them to purge the leaked commit, and tell anyone with a fork to re-clone.
• Add prevention. Pre-commit hook with gitleaks or detect-secrets, plus push protection / secret scanning enabled at the org level so this is blocked next time.