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

Enable and configure GitHub Secret Protection at the repository and organization levels, and contrast behaviour for public versus private and enterprise repositories.

Enable and configure GitHub Secret Protection at both the repository and organisation settings levels, applying the correct toggles and options for each. Contrast the scanning behaviour for public repositories, which is always on, with the configuration requirements for private repositories and GitHub Enterprise environments.

secret scanningSecret Protectionrepository settingsorganization settings

Practice question for this objective

Free sampleConfigure and use Secret Protectionmedium

An open-source maintainer hosts a popular public repository on GitHub.com and has never purchased any paid security product for it. They want to confirm whether secret scanning will detect leaked tokens such as a published cloud provider key in that public repository at no extra cost. What is the correct position for a public repository under GitHub.com?

ASecret scanning runs on the public repository only after the maintainer buys a "GitHub Advanced Security" or "Secret Protection" licence and assigns a seat.
BSecret scanning is available free of charge for the public repository, so it can detect supported leaked credentials without any paid product. Correct
CSecret scanning only ever runs on public repositories that belong to a paid organisation account, not on personal public repositories.
DSecret scanning is unavailable for public repositories because exposed secrets there are treated as already public and beyond remediation.

Recognise that secret scanning is free for public repositories on GitHub.com whereas private and internal repositories need a paid Secret Protection licence. GitHub funds "secret scanning" for public repositories so that leaked credentials in open-source code are caught without cost, including partner notification for many provider tokens. The paid "Secret Protection" entitlement is what extends the same detection to private and internal repositories, which is why no purchase is required for the public case.

Why A is wrong: This is tempting because private and internal repositories do require a paid "Secret Protection" licence, but public repositories on GitHub.com receive secret scanning free of charge, so no purchase or seat assignment is needed.

Why B is correct: GitHub provides "secret scanning" for public repositories at no cost as part of the platform, so the maintainer can detect supported partner and provider secrets without buying "Secret Protection". This matches the free public-repository entitlement.

Why C is wrong: Account type is not the gate here. Free public-repository secret scanning applies regardless of whether the repository is owned by a personal account or an organisation, so restricting it to paid organisations is incorrect.

Why D is wrong: Public exposure makes detection more urgent, not pointless, and GitHub still scans and alerts on it. The premise that public secrets are beyond remediation is wrong, so this option misstates the behaviour.

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.

The repository administrator lacks the security manager role, so the secret scanning control is hidden until an organisation owner assigns that role to them.
Why it is wrong: A missing role would typically restrict alert management, not remove the feature control instance-wide; on Enterprise Server the more fundamental gate is whether the feature has been turned on for the instance at all.
Full configuration including selecting which partner patterns run and authoring custom secret scanning patterns, because public repositories receive the same configurable feature set as paid private ones.
Why it is wrong: Custom patterns are a Secret Protection capability; the free public-repository offering does not grant custom-pattern authoring or per-pattern selection, so claiming the same configurable set as paid private repositories is wrong.
Enable secret scanning for all current repositories only, then revisit the settings periodically to enable it on any repositories created since the last visit.
Why it is wrong: Enabling for current repositories alone leaves a gap for future ones, and manual revisits are exactly the per-repository toil the owner is trying to avoid, so it satisfies only half the requirement.

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