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

Control access with role-based and delegated bypass policies, configure alert recipients and exclusions for Secret Protection.

Configure role-based access and delegated bypass policies to control who can view and manage Secret Protection alerts. Set up alert recipients and define secret scanning exclusions to reduce noise while preserving coverage for high-risk paths.

delegated bypassalert recipientssecret scanning exclusionsrole-based access

Practice question for this objective

Free sampleConfigure and use Secret Protectionmedium

A repository stores deliberately fake credentials inside a directory of test fixtures, and these constantly generate non-actionable secret scanning alerts. The team wants secret scanning to stop analysing only that directory while continuing to scan the rest of the repository, and they prefer a configuration committed alongside the code. Which approach achieves this?

# .github/secret_scanning.yml
paths-ignore:
  - 'tests/fixtures/**'
  • AAdd the fixture directory to the repository's top-level '.gitignore' file so that secret scanning no longer indexes those paths.
  • BAdd a 'secret_scanning.yml' file under '.github' that lists the fixture directory under 'paths-ignore', so secret scanning skips matching paths. Correct
  • CDisable secret scanning for the whole repository in its security settings, then re-enable it only for the directories that matter.
  • DResolve each fixture alert as 'used in tests' so that future detections in the same directory are suppressed automatically.
Exclude specific paths from secret scanning using a 'secret_scanning.yml' file with a 'paths-ignore' list while scanning continues elsewhere. Secret scanning reads a 'secret_scanning.yml' file in the repository's '.github' directory and skips any path matching its 'paths-ignore' patterns. This scopes the exclusion to the fixture directory only, unlike '.gitignore', a full feature disable, or per-alert resolution, none of which stop future detections in just that path.

Why A is wrong: A '.gitignore' entry stops Git from tracking files, which is tempting because it also keeps content out of the repository. But files already committed remain scannable, and '.gitignore' does not configure secret scanning exclusions; the dedicated 'secret_scanning.yml' does.

Why B is correct: A 'secret_scanning.yml' file in the '.github' directory with a 'paths-ignore' list is the supported, in-repository way to exclude specific paths from secret scanning. It targets only the fixture directory while leaving scanning active everywhere else, exactly as required.

Why C is wrong: Secret scanning is enabled or disabled at the repository level, not per directory, so there is no per-directory re-enable toggle. Disabling it wholesale would also stop scanning the rest of the codebase, which the team explicitly wants to keep.

Why D is wrong: Marking individual alerts as used in tests closes those specific alerts but does not stop new detections in that directory from raising fresh alerts. Ongoing suppression of a path requires an exclusion in 'secret_scanning.yml', not per-alert resolution.

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.

  • No secret scanning alert is created, because choosing a bypass reason is itself the disposition that closes out the detection for that secret.

    Why it is wrong: It is tempting to treat the bypass reason as the alert resolution, but bypassing only allows the push to proceed; secret scanning still creates an alert for the committed secret so it can be triaged.

  • If the developer bypasses with the reason that the secret is used only in tests, GitHub blocks the push a second time and requires an organisation owner to approve before the commit can proceed.

    Why it is wrong: Tempting because test fixtures feel like they need oversight, but without delegated bypass any contributor can self-serve the used-in-tests reason; the push proceeds immediately and the alert is closed rather than being escalated for owner approval.

  • Enable push protection on each repository as it is created, and rely on branch protection rules on the default branch to decide which users can override a blocked push.

    Why it is wrong: Manually enabling each new repository does not guarantee future coverage, and branch protection governs merges into branches, not who may bypass a push protection block. Both halves miss the org-wide enablement and the dedicated bypass restriction.

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