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 credentials are safe because the .env file is listed in .gitignore
• 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.Rotating credentials is always sufficient; GitHub scans and removes secrets from repository history automatically; blind SQL injection cannot exfiltrate data and only confirms whether a database is present; insecure deserialization is limited to Java, as JSON-based stacks cannot execute code during parsing by design; exploiting broken access control requires valid credentials, which is why it ranks below injection in severity