A developer stores API keys and database passwords in a .env file committed to a public GitHub repository. They remove the file and rotate the credentials. Why is rotating credentials insufficient without reviewing git history?

• A.The deleted file is still served from the GitHub CDN cache (a copy kept for seven days), and the cache can be purged by the repository owner alone through a support request, with rotation changing nothing about that cached copy, leaving the old values readable to anyone holding the direct link
• B.Git commits are permanent - the .env file with the original secrets remains in the repository's full history and is visible to anyone who clones the repo, even after the file is removed from the latest commit. An attacker who cloned the repo during the exposure window (or who finds it via GitHub's search, GitGuardian, or truffleHog) still has the old credentials if the history is not rewritten
• C.Git hooks on the remote restore the deleted file from the reflog on each push (a server-side recovery feature), and the restored copy contains the old credentials, with the new values appearing after a force push, a step that the repository settings block on the default branch