GitHub Advanced Security GH-500: Secret Scanning

Topic snapshot

Sample questions

These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.

Question 1

Topic: Configure and Use Secret Scanning

An organization uses GitHub Enterprise Cloud. Its public repository sdk-docs already generates secret scanning alerts for supported token patterns. Its private repository payments-api must remain private, and the security team wants the same secret-detection capability there. GitHub Advanced Security is available for the organization. What is the best security action?

Options:

• A. Enable secret scanning for the private repository or through organization policy.

• B. Change the private repository to public.

• C. Enable push protection only for the private repository.

• D. Enable code scanning for the private repository.

Best answer: A

Explanation: Public repositories already receive secret scanning coverage for supported patterns, but private repositories need secret scanning to be enabled through GitHub Advanced Security. Because the repository must stay private, the right action is to enable secret scanning rather than change visibility or use a different feature.

The key distinction is repository visibility. GitHub secret scanning is available for public repositories for supported secret patterns, but private repositories need secret scanning to be enabled through GitHub Advanced Security at the repository, organization, or enterprise scope. In this scenario, the team wants equivalent secret-detection coverage without exposing the code, so enabling secret scanning on the private repository is the correct action.

Push protection helps prevent new secrets from being pushed, but it does not replace secret scanning coverage for secrets that are already in the repository history. Code scanning is for finding code vulnerabilities and insecure patterns, not leaked credentials. Making the repository public would create unnecessary exposure instead of applying the correct GHAS control.

• Push protection only helps block new secret exposures, but it does not provide the same post-commit alert coverage by itself.
• Code scanning targets code security findings, not secret leakage detection.
• Changing visibility is not a security improvement here; it increases exposure instead of enabling the proper feature on a private repo.

Question 2

Topic: Configure and Use Secret Scanning

Your organization uses GitHub Advanced Security with secret scanning and push protection enabled. Commits to files under docs/samples/ are repeatedly blocked because those training examples contain placeholder strings that match supported secret formats. AppSec has verified that this folder is generated sample content and must remain in the repository, but all other paths must continue using default secret scanning behavior.

What is the safest customization to reduce these false positives?

Options:

• A. Require developers to bypass the block for each commit.

• B. Exclude the docs/samples/ path from secret scanning.

• C. Disable push protection for repositories with training content.

• D. Add a custom pattern for the placeholder format instead.

Best answer: B

Explanation: Use the narrowest exclusion that fits the known-safe case. Because only docs/samples/ is approved sample content, excluding that path reduces repeated false positives without weakening secret scanning and push protection for the rest of the repository.

When default secret scanning repeatedly flags known-safe content, the best practice is to use a narrowly scoped exclusion rather than weaken protection globally. In this scenario, AppSec has already confirmed that docs/samples/ is generated training material and that other repository content still needs normal secret scanning coverage.

A path-based exclusion is the safest fit because it limits the exception to the specific folder causing the noise. Disabling push protection affects unrelated files, and repeated manual bypasses create operational risk and poor audit hygiene. Custom patterns are used to detect additional secret formats; they do not safely suppress built-in detections that are already producing false positives.

The key takeaway is to scope secret scanning exceptions as tightly as possible and keep default protections active everywhere else.

• Disabling push protection is too broad because it removes prevention for real secrets in the same repositories.
• Requiring repeated bypasses is not a safe remediation because it normalizes exceptions and increases the chance of an actual secret being committed.
• Adding a custom pattern is the wrong tool because custom patterns extend detection rather than safely excluding known-safe default matches.

Question 3

Topic: Configure and Use Secret Scanning

An organization uses GitHub Advanced Security on a private repository. The main branch requires pull requests, two approvals, and a CodeQL status check. Secret scanning is already enabled, and it created an alert only after a developer pushed a feature branch containing a supported secret type. The security policy now requires a control that warns or blocks the developer before the secret is stored in the repository. Which action should the repository administrator take?

Options:

• A. Enable secret scanning push protection.

• B. Enable secret validity checks for secret scanning alerts.

• C. Require CodeQL analysis on all pull requests.

• D. Review secret scanning alerts before merging pull requests.

Best answer: A

Explanation: The needed control is push protection, because it acts before the secret is accepted into the GitHub repository. Secret scanning alerts and validity checks happen after detection, while CodeQL and pull request review address different parts of the workflow.

Secret scanning alerts and push protection apply at different stages. A secret scanning alert is created after a secret has already been committed and pushed to the repository, so it supports detection, triage, and remediation. Push protection moves enforcement earlier by inspecting pushes for supported secrets and stopping the push or requiring an explicit bypass before the secret is stored in GitHub.

In this scenario, pull request approvals, branch protection, and required CodeQL checks still help govern code review and vulnerability analysis, but they do not prevent a secret from landing on a feature branch before the pull request is reviewed. Validity checks can help prioritize a detected secret, but they do not provide pre-push prevention. The key distinction is prevention at push time versus alerting after the secret already exists in repository history.

• Validity checks help prioritize detected secrets, but the secret must already be in the repository before that signal exists.
• CodeQL checks find code vulnerabilities and data-flow issues, not leaked credentials during a push.
• PR alert review improves remediation workflow, but it still happens after the secret was pushed to the feature branch.

Question 4

Topic: Configure and Use Secret Scanning

Your GitHub Enterprise Cloud organization has GHAS enabled for all private repositories. Secret scanning is already generating alerts when developers push supported cloud API tokens to feature branches, but the security team wants to stop those tokens from being written to repository history before the push is accepted. They also want any exception to require an explicit user justification during the push flow. What is the best security action?

Options:

• A. Keep secret scanning alerts enabled and expand alert notifications.

• B. Enable secret scanning push protection at the organization level.

• C. Require CodeQL code scanning to pass before pull requests merge.

• D. Use validity checks to automatically close alerts marked inactive.

Best answer: B

Explanation: The team needs a preventive control, not only detection after exposure. Secret scanning alerts are post-commit findings, while push protection checks supported secrets during the push and can block the push until the secret is removed or a bypass is justified.

Secret scanning and push protection solve related but different problems. Secret scanning alerts are created after a secret has already been committed and pushed to the repository, which means the secret may already exist in Git history and require rotation, cleanup, and alert triage. Push protection adds a preventive control in the push path for supported secret types, warning or blocking the user before the remote repository accepts the change.

In this scenario, the organization already has post-commit detection, but that still leaves cleanup work after exposure. The better action is to enable push protection at the organization level so repositories are covered consistently and developers must remove the secret or provide a documented bypass reason. Validity checks can help prioritize alerts, but they do not prevent exposure, and code scanning addresses code vulnerabilities rather than leaked credentials.

• Expanding secret scanning notifications still leaves the secret in repository history because detection happens after the push.
• Automatically closing alerts based on validity confuses prioritization with prevention and can hide secrets that still need response actions.
• Requiring CodeQL checks helps find code issues, not credentials embedded in pushed content.

Question 5

Topic: Configure and Use Secret Scanning

Your organization uses GitHub Advanced Security with a custom secret-scanning pattern for internal API tokens. A private monorepo has repeated false positives in generated files under tests/fixtures/. A developer proposes this change to reduce alert noise:

paths-ignore:
  - "**/*.json"

The repository also stores deployment and environment configuration in JSON outside tests/fixtures/. What is the best security action?

Options:

• A. Change the exclusion to tests/fixtures/** only

• B. Turn off the custom pattern for this repository

• C. Keep **/*.json and review JSON changes manually

• D. Dismiss fixture alerts and keep **/*.json

Best answer: A

Explanation: The proposed exclusion is too broad because it suppresses secret scanning for every JSON file in the repository, including configuration files where real secrets may be pasted. The best action is to narrow the exclusion to the specific generated path causing noise.

Secret scanning exclusions should be as specific as possible. A file-type-wide exclusion like **/*.json creates a blind spot across the repository, which is risky when deployment or environment files are also stored as JSON. If the false positives come from a predictable location such as generated fixtures, the safer approach is to exclude only that path and keep scanning enabled everywhere else.

This preserves coverage for real leaks while reducing noise from known test artifacts. It also avoids weakening detection for the organization’s internal token format, which is why disabling the custom pattern is not the right fix. The key takeaway is to solve false positives with the smallest effective exclusion, not a broad pattern that hides real secrets.

• Manual review only is weaker than automated scanning and does not remove the blind spot created by excluding all JSON files.
• Disable the pattern fails because the custom pattern may be the only detector for the organization’s internal token format.
• Dismiss and keep broad exclusion handles current noise but still hides future real secrets in non-test JSON files.

Question 6

Topic: Configure and Use Secret Scanning

A private repository uses a protected main branch and required code scanning checks on pull requests. Secret scanning is enabled, but notifications currently go only to repository administrators. After a placeholder token was merged, the security policy now requires the central AppSec team to receive secret scanning notifications for this repository only. The team already has permission to view secret scanning alerts and should not receive admin access.

What should the repository administrator do?

Options:

• A. Require AppSec review on pull requests with a repository ruleset.

• B. Grant the AppSec team the organization security manager role.

• C. Enable CodeQL analysis and SARIF uploads on pull requests.

• D. Add the AppSec team as repository secret scanning alert recipients.

Best answer: D

Explanation: Secret scanning supports configured alert recipients beyond repository administrators. Because the requirement applies to only one repository and the AppSec team already has alert-view permissions, adding that team as secret scanning alert recipients is the best fit.

This scenario is about who gets notified when secret scanning creates an alert, not about pull request enforcement or broader security permissions. GitHub lets you configure secret scanning alert recipients so specific users or teams can receive notifications beyond repository administrators. Since the policy applies to one repository only, the repository-level recipient configuration is the most targeted choice.

• Use secret scanning alert recipients to route secret leak notifications.
• Use broader roles only when you need broader access, not just notification changes.
• PR rules and CodeQL affect review and code scanning workflows, not secret scanning alert delivery.

The key distinction is between alert visibility permissions and notification recipient configuration.

• Broader role assigning the security manager role expands organizational security access, but it is not the repository-specific notification control asked for here.
• PR workflow control requiring AppSec review changes merge governance for pull requests, not who receives secret scanning alerts after detection.
• Wrong GHAS feature enabling CodeQL and SARIF addresses code scanning findings, not leaked-secret alert notifications.

Question 7

Topic: Configure and Use Secret Scanning

A private repository has GitHub Advanced Security and secret scanning enabled. After a merge to main, GitHub creates this alert:

Type: Secret scanning
Location: config/prod.env
Finding: Provider token pattern
Validity check: Not supported
Status: Open

What is the best next action?

Options:

• A. Wait for Dependabot to propose a dependency update

• B. Open a code scanning investigation for insecure data flow

• C. Dismiss the alert because only confirmed valid secrets require action

• D. Rotate or revoke the exposed credential and remove it from the repository

Best answer: D

Explanation: This alert indicates that secret scanning found content matching a secret pattern in the repository. Even when validity cannot be confirmed, the safest response is to treat it as a potential credential exposure and remediate it.

Secret scanning is designed to detect secrets and credentials that appear in repository content, such as tokens, keys, or other sensitive values. In this scenario, GitHub found content matching a provider token pattern in a committed file, which means the repository may contain an exposed secret. A validity check can help prioritize alerts, but lack of one does not make the alert safe to ignore.

The right response is to:

• rotate or revoke the secret
• remove it from the repository and update any affected configuration
• then close the alert when remediation is complete

This is different from code scanning, which finds insecure code patterns, and Dependabot, which addresses vulnerable dependencies.

• Ignoring validity fails because secret scanning can identify exposed secrets even when GitHub cannot confirm they still work.
• Using code scanning is wrong because this alert is about a leaked credential in content, not a code vulnerability path.
• Using Dependabot is wrong because Dependabot remediates dependency issues, not exposed secrets.

Question 8

Topic: Configure and Use Secret Scanning

A private GitHub Enterprise Cloud repository uses a ruleset that requires pull requests and approvals before merging to main. Secret scanning and push protection are enabled. A developer bypasses push protection on a feature branch, opens a pull request, and GitHub creates a secret scanning alert after the commit. The AppSec team is named in SECURITY.md, but team members have only read access and report that they cannot see the alert or its notifications. Which configuration should the organization owner change?

Options:

• A. Enable Dependabot security updates for the repository.

• B. Require CodeQL code scanning on pull requests.

• C. Assign the AppSec team as organization security managers.

• D. Require AppSec approval in the branch protection rule.

Best answer: C

Explanation: This is an alert access problem, not a pull request policy problem. In a private repository, naming a team in SECURITY.md and giving it read access does not let that team view or triage secret scanning alerts, so the owner should grant a security role such as organization security manager.

Secret scanning alerts are governed by security access, not by pull request reviewer settings. In this scenario, push protection was bypassed, so the secret was committed and a secret scanning alert was generated afterward. Because the repository is private, the AppSec team still needs appropriate security permissions to see and manage that alert.

Assigning the team as organization security managers is the best fit when they are responsible for triage across repositories. That role is designed for security workflows and gives access to GitHub Advanced Security alerts without making the team full repository administrators. By contrast, branch protection and rulesets control merge behavior, and CodeQL or Dependabot address different types of findings.

The key takeaway is that missed secret scanning alerts in a private repo often point to alert visibility or recipient configuration, not to PR enforcement settings.

• Branch protection mismatch requiring AppSec approval can gate merges, but it does not grant secret scanning alert access.
• Wrong alert type CodeQL code scanning is for code vulnerabilities and data-flow findings, not leaked secrets.
• Dependency feature Dependabot security updates remediate vulnerable packages, not secret scanning visibility or notifications.

Question 9

Topic: Configure and Use Secret Scanning

A GitHub Enterprise Cloud organization uses GHAS. Secret scanning is enabled on a private monorepo, and alert notifications go to the AppSec team. A developer commits an internal deployment token formatted as ACMEDEPLOY-<24 uppercase letters>. The token is for an in-house service that is not a GitHub-supported secret scanning partner. No alert appears after the commit reaches the default branch. What is the best security action?

Options:

• A. Upload a SARIF result so code scanning can track the secret.

• B. Enable push protection to generate an alert for the existing commit.

• C. Wait for validity checks to confirm the token before alerting.

• D. Create a custom secret scanning pattern for the token format.

Best answer: D

Explanation: No built-in alert is expected for an unsupported in-house token format, even when secret scanning and notifications are enabled. GitHub generates secret scanning alerts from supported partner patterns or custom patterns, so the right action is to define a custom pattern.

Secret scanning generates alerts when repository content matches a supported secret pattern or a custom pattern that you define. In this scenario, the committed token belongs to an internal service that GitHub does not natively recognize, so no built-in secret scanning alert or notification should be expected. Notifications only occur after an alert is created.

Custom patterns extend secret scanning to organization-specific token formats. Push protection helps prevent future exposures during push, but it does not retroactively create alerts for an already committed unsupported secret. Validity checks can help prioritize a detected secret, but they do not create detections on their own. Code scanning SARIF uploads are for code analysis findings, not leaked credential detection.

The key takeaway is that unsupported secret formats need custom secret scanning patterns before alerting workflows can function.

• Push protection timing fails because push protection prevents future pushes and does not create an alert for an already committed unsupported secret.
• Validity check confusion fails because validity checks apply after a secret is detected; they do not trigger detection for an unknown pattern.
• Wrong GHAS feature fails because SARIF and code scanning handle code analysis results, not secret scanning detections.

Question 10

Topic: Configure and Use Secret Scanning

A security engineer commits the same supported token pattern to two new repositories in the same GitHub organization. The organization has GitHub Advanced Security available for private repositories, but no policy has enabled secret scanning there.

What is the best next action?

Options:

• A. Enable secret scanning for private repos at repo or org scope.

• B. Wait; new private repos get secret scanning automatically after indexing.

• C. Treat the missing private alert as proof no exposure occurred.

• D. Enable code scanning for payments-api to detect leaked secrets.

Best answer: A

Explanation: This scenario is about default coverage by repository visibility. Public repositories can generate secret scanning alerts without manual enablement, while private repositories need secret scanning turned on, so the right response is to enable it for the private repo or by organization policy.

The key concept is that repository visibility affects default secret scanning behavior. For supported secret patterns, public repositories are scanned by default, so an alert can appear even when no one explicitly enabled the feature. Private repositories do not get that same default behavior; if secret scanning has not been enabled for the repository or through an organization policy, the lack of an alert is expected.

The best follow-up is to enable secret scanning for the private repository or apply an organization-level policy so private repositories receive the same coverage. Code scanning is for code vulnerabilities, not leaked credentials, and waiting for indexing does not activate a disabled feature. The absence of an alert in an unenabled private repository is not evidence that no secret was exposed.

• The code scanning option uses the wrong GHAS feature; leaked credentials are handled by secret scanning.
• The waiting option fails because the stem says secret scanning was not enabled for private repositories.
• The option treating no alert as proof of safety ignores that missing coverage can explain the missing alert.

Continue with full practice

Use the GitHub Advanced Security GH-500 Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try GitHub Advanced Security GH-500 on Web View GitHub Advanced Security GH-500 Practice Test

Related focused pages

• Free GitHub Advanced Security GH-500 Full-Length Practice Exam
• GHAS Features
• Dependabot Review
• Codeql Code Scanning
• GHAS Results

Free review resource

Read the GitHub Advanced Security GH-500 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.