TL;DR: Rotate first, investigate second, clean history last. The key is compromised the moment it is pushed to a public repo, and automated collection may happen quickly, so revoke promptly while containment proceeds. Rewriting history does not un-publish anything and it is the step people reach for first.
How to approach it
Lead with the ordering and the reason. The interviewer is testing whether you understand that the exposure is already complete, so containment is revocation rather than deletion.
A strong answer
Minute zero: revoke. Deactivate the access key immediately, preserve its identifier and investigation metadata, then delete it after response needs are satisfied. Not rotate later, not after checking whether anyone used it. Public repositories are scraped continuously by automated tooling and credentials may be exercised before a human notices the exposure. Any hesitation is spent on the attacker's side of the clock. If the key belongs to a service that will break, break it: an outage is recoverable and a compromised production credential may not be.
Minutes one to fifteen: assess blast radius. What could that key do? Pull its attached policies and answer honestly, because "it was only a read key" is frequently wrong. Then go to CloudTrail and look for use of that access key ID from unfamiliar IPs, unusual regions, or possible reconnaissance calls such as GetCallerIdentity, ListBuckets, DescribeInstances. Unexpected RunInstances across regions can indicate compute abuse; investigate the launched workloads rather than treating that API call alone as proof of mining.
Minutes fifteen to thirty: contain anything it touched. If it was used, this stops being a secret-leak incident and becomes a compromise: revoke sessions derived from it, look for IAM users or keys it created for persistence, check for modified trust policies, and follow your incident process. If CloudTrail shows nothing, record that you checked and keep monitoring, because absence of evidence at hour two is weak evidence.
Then history. Only now, and understanding what it does and does not achieve. git filter-repo or BFG rewrites the commits, everyone re-clones, and the old objects eventually go. What it does not do: undo the copies that already exist. Forks retain it, GitHub keeps unreferenced objects reachable by SHA for a period, mirrors and CI caches have it, and anyone watching has it. History rewriting is hygiene, not remediation. Say that sentence in the interview.
Then prevention, which is what a senior answer spends its last minute on. Pre-commit hooks with gitleaks or similar catch it before it leaves the laptop; a CI scan catches what the hook missed; push protection at the platform level catches what CI missed. All three, because each is bypassable. Structurally: stop having long-lived keys at all. OIDC federation from your CI to the cloud provider issues short-lived credentials per run with no static secret to leak, and that removes the entire class of incident rather than detecting it faster.
What interviewers probe next
"It was in a private repo. Does that change it?" Treat it as an exposure requiring prompt revocation; assess repository access and integrations to establish scope. Every employee and every integration with repo access had it, and private repos become public by accident.
"How do you know what the key could do?" Its policies plus anything it could assume. Enumerate rather than assume, since roles chain.
"What if it is in a container image on a public registry?" Same rule: rotate first. Deleting the tag does not remove the layer from anyone who pulled it.
Common mistakes
Rewriting history first. It feels like fixing it and it protects nobody.
Not checking CloudTrail, so you never learn whether this was a scare or a breach.
Treating detection as the fix. Scanning finds the next one faster; federation removes stored long-lived keys, while temporary tokens still require protection. AWS access-key management.