A developer commits a new Stripe live key into a file and runs git push to a repository where push protection is enabled. They expect the alert to appear on the Security tab after the push completes, as it would with secret scanning alone. At what point does push protection act on the supported secret, and what is the immediate effect on the developer?
- AAfter the push is accepted, push protection retroactively rewrites the offending commit and closes the resulting secret scanning alert automatically.
- BBefore the local commit is created, a pre-commit hook installed by push protection refuses to record the commit until the secret is deleted.
- CDuring the push, before the commit reaches the remote branch, the push is rejected and the developer is shown which secret type was detected so they can remove it. Correct
- DOn a schedule after the push, the next secret scanning run quarantines the secret in a hidden ref and notifies the security team to approve release.
Why A is wrong: This is tempting because push protection and secret scanning are paired, but push protection never rewrites accepted history; it intervenes before the push is accepted. Rewriting commits is the developer's job after a secret is already exposed.
Why B is wrong: Push protection runs server side on the push, not as a locally installed pre-commit hook, so it does not stop the commit being created on the developer's machine. Assuming a client-side hook misplaces where the control actually operates.
Why C is correct: Push protection scans the push as it arrives and blocks it before the content lands on the remote, returning the detected secret type and location so the credential is removed at the source. This prevents exposure rather than reporting it afterwards.
Why D is wrong: Secret scanning detection of already-pushed secrets is event-driven and creates alerts, but there is no scheduled quarantine-and-approve workflow, and that flow describes neither push protection nor secret scanning. The secret would already be exposed by then.