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

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.check_circle 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.

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.