A developer accidentally pushed an AWS access key to a PUBLIC GitHub repo. What is the correct response order?
Short answer
Treat any pushed secret as burned: revoke and rotate it first, because bots scrape public commits within seconds, then review CloudTrail for misuse and purge it from history. Deleting the commit doesn't help — the key is already cloned, forked, and cached by third parties. Making the repo private leaves a live, already-leaked key in attackers' hands. Adding the file to .gitignore does nothing for a secret that is already committed.
A leaked cloud credential is a clock-is-running incident. Automated bots continuously scrape public GitHub events, and exposed AWS keys are commonly used to spin up crypto-mining fleets within minutes of being pushed. The candidate's instinct must be containment before cleanup.
Why revoke and rotate first
The moment a secret hits a public commit, you must assume it is compromised — there is no way to prove a bot did not grab it. Revoking (deactivating/deleting) and rotating the access key cuts off any attacker who already has it. Only after the live key is dead do you investigate: pull CloudTrail to see what the key did, look for unexpected API calls, new IAM users, launched instances, or data access, and then scrub the secret from git history (for example with git filter-repo) and notify anyone who forked the repo.
Why the distractors are wrong
- Delete the commit. This is the classic weak answer. Once pushed to a public repo, the commit has likely been cloned, forked, indexed by scanners, and cached by GitHub's own event API. Rewriting history does not un-leak the secret — and it gives a false sense of safety while a live key stays valid.
- Make the repo private and keep using the key. The key was already public; flipping repo visibility does nothing about copies already taken. Continuing to use a leaked key is leaving the front door open.
- Add the key file to .gitignore.
.gitignoreonly stops future, untracked files from being staged. It has zero effect on a secret already committed and pushed.
What the interviewer is probing
They want to see that you order your actions by blast-radius reduction: kill the credential, then investigate, then clean up. They also want the situational awareness that public exposure is irreversible, so the only safe assumption is full compromise. Bonus points for mentioning compensating controls — pre-commit secret scanning, short-lived credentials via IAM roles or OIDC, and GitHub push protection — so this never happens again.
Likely follow-ups
- How would you detect whether the leaked key was actually used by an attacker?
- What controls would prevent secrets from being committed in the first place?
- How does the GitHub secret-scanning and AWS quarantine flow change your response?