GH-500 - Configure and use Secret Protection (18% of the exam) - Section 2.2

Explain how push protection prevents secrets at the source, and describe validity checks and prioritized alerting for high-confidence secrets.

Explain how push protection blocks a commit containing a high-confidence secret before it reaches the remote, and describe how validity checks confirm whether a detected secret is still active. Distinguish the bypass push protection options available to developers and when each is appropriate.

push protectionvalidity checkshigh-confidence secretsbypass push protection

Practice question for this objective

Free sampleConfigure and use Secret Protectionhard

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.

Explain that push protection blocks a supported secret during the push, before it reaches the remote, surfacing the detected type so the developer removes it. Push protection works at the point of the push: GitHub inspects the incoming push for supported secret types and rejects it before the content is written to the remote branch, telling the developer what was found. This prevents the secret from ever being committed to the remote, which is fundamentally different from secret scanning raising an alert on content that has already arrived.

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.

See more GH-500 practice questions, answers explained.

Exam traps in Configure and use Secret Protection

Answers that look right on this material and are not. Each one is a distractor from a different question in the GH-500 bank for this domain.

Force-push the branch with a lease, because push protection only inspects the tip commit and a deletion in the latest commit clears the block once the remote ref is overwritten.
Why it is wrong: Tempting because force-pushing is the usual way to overwrite a remote branch, but push protection inspects every commit in the push set, not only the tip, so the key still present in the third commit keeps the push blocked regardless of how the ref is updated.
Any contributor who triggers the block can still bypass it themselves, but the bypass list members are emailed a notification afterwards for visibility.
Why it is wrong: This describes the default behaviour without delegated bypass, where the pushing user chooses a reason and proceeds. Delegated bypass exists precisely to remove that self-service bypass, so leaving it with the contributor is wrong.
The push to the experiment branch succeeds because push protection is scoped to the default branch, but secret scanning will retroactively block the branch the next time it is scanned.
Why it is wrong: Tempting because branch protection rules are often default-branch scoped, but push protection is not limited to the default branch and applies to pushes to any branch; secret scanning detection also does not retroactively block a push after the fact.

Examworthy is not affiliated with or endorsed by GitHub. Original, blueprint-aligned practice material only.