GH-500 — GitHub Advanced Security Scenario Practice Guide

This independent scenario guide is for candidates preparing for the GitHub Advanced Security exam, GH-500. It focuses on how to read scenario-based questions, identify the real security decision, and choose the most defensible GitHub Advanced Security action from the facts provided.

GH-500 scenarios often describe repositories, organizations, security alerts, workflows, dependencies, secrets, permissions, or developer processes. The best answer is usually not the most dramatic security action. It is the action that directly satisfies the stated goal, fits the scope, respects least privilege, and avoids unnecessary disruption.

Start by identifying the security decision

Before comparing answer choices, decide what kind of decision the scenario is asking you to make.

Ask:

• Is the scenario asking how to enable a security capability?
• Is it asking how to configure a feature for a repository, organization, or enterprise?
• Is it asking how to detect a risk, such as vulnerable dependencies, exposed secrets, or insecure code?
• Is it asking how to prevent a risk before code is merged or pushed?
• Is it asking how to triage or remediate an alert?
• Is it asking how to delegate access without granting excessive permissions?
• Is it asking how to integrate GitHub Advanced Security with an existing workflow or third-party tool?

Once you know the decision type, many attractive but indirect answers become easier to eliminate.

Read the scenario in layers

Do not read a GH-500 scenario as one block of text. Read it in layers and mark the facts that change the answer.

1. Identify the environment

First determine where the action must happen.

Look for:

• Repository-level, organization-level, or enterprise-level scope
• Public, private, or internal repositories
• A single repository versus many repositories
• GitHub-hosted workflows versus external CI
• Code hosted in GitHub versus alerts imported from another tool
• A team, security team, repository administrator, or developer persona
• Existing GitHub Advanced Security features already enabled or not enabled

Scope matters. If the requirement is organization-wide consistency, a repository-by-repository action may be less defensible. If the requirement is limited to one repository, a broad organization change may be unnecessary.

2. Find the asset or risk

Next, identify what is being protected or detected.

Common GH-500 scenario signals include:

• Source code vulnerabilities
• Exposed credentials, tokens, or keys
• Vulnerable open-source dependencies
• Risk introduced by a pull request
• Unreviewed or stale security alerts
• Inconsistent security coverage across repositories
• Excessive permissions for users or teams
• Lack of visibility for security teams

The risk type usually points toward the relevant GitHub Advanced Security capability.

3. Determine the requested outcome

Separate the goal from the background.

For example:

• “Detect insecure code patterns” points toward code scanning.
• “Use CodeQL with a custom build process” points toward advanced CodeQL setup.
• “Show alerts from an existing third-party scanner in GitHub” points toward SARIF upload.
• “Prevent credentials from being pushed” points toward secret scanning push protection.
• “Find vulnerable dependencies already in the project” points toward Dependabot alerts and dependency graph data.
• “Review dependency risk introduced by a pull request” points toward dependency review.
• “Give security staff access to manage security alerts” points toward an appropriate security-focused role or permission model.

The answer should map to the outcome, not merely to the general topic.

4. Separate constraints from preferences

Scenario constraints are facts the answer must obey. Preferences are useful, but less decisive.

Strong constraints often include:

• “Must apply to all repositories in the organization”
• “Must not require every repository administrator to configure it manually”
• “Must integrate with an existing CI system”
• “Must use least privilege”
• “Must avoid blocking developer work unless a high-confidence risk is detected”
• “Must scan a compiled language that requires custom build steps”
• “Must allow security teams to manage alerts without making them repository admins”
• “Must surface results inside GitHub”
• “Must prevent new secrets, not just detect existing ones”

When an answer violates a constraint, eliminate it even if it is technically related.

Match the scenario to the GitHub Advanced Security capability

Use the scenario facts to choose the capability that best fits the job.

Code scanning and CodeQL

Choose code scanning when the scenario is about finding security weaknesses in code.

Key interpretation points:

• If the scenario asks for GitHub-native static analysis, CodeQL is often the relevant capability.
• If the repository can use a simple supported setup and the scenario emphasizes ease of enablement, a simpler setup is more defensible.
• If the project requires custom build commands, special language handling, custom queries, or a tailored workflow, advanced setup is more appropriate.
• If the organization already uses a third-party scanner and wants results visible in GitHub code scanning alerts, uploading SARIF is usually the relevant integration path.
• If the question is about investigating a code scanning failure, inspect the workflow, build steps, permissions, and analysis logs before changing the security strategy.

A good code scanning answer usually fits both the language/build environment and the operational requirement.

Secret scanning and push protection

Choose secret scanning when the scenario is about credentials, tokens, keys, or other sensitive strings appearing in repositories.

Read carefully for timing:

• If the secret is already exposed, the first priority is to treat it as compromised, such as revoking or rotating it through the appropriate provider or owner process.
• If the goal is to detect committed secrets, secret scanning is the relevant capability.
• If the goal is to stop supported secrets before they are pushed, push protection is more directly aligned.
• If the organization has internal token formats, a custom secret scanning pattern may be needed.
• If developers need a controlled way to proceed after a push protection block, look for review, bypass, or documented justification processes rather than disabling protection broadly.

For secret scenarios, distinguish detection from prevention. Detecting a leaked secret is not the same as preventing a new one from entering the repository.

Dependency management and supply chain risk

Choose dependency-focused features when the scenario describes vulnerable packages, manifests, lockfiles, dependency changes, or pull request dependency risk.

Common mappings:

• Existing vulnerable dependency in a repository: Dependabot alerts.
• Automated pull requests to update vulnerable dependencies: Dependabot security updates.
• Routine version maintenance, not necessarily security-driven: Dependabot version updates.
• Reviewing whether a pull request introduces a vulnerable dependency: dependency review.
• Organization-wide visibility into repository security posture: security overview and related organization-level views.

Pay attention to the timing. A pull request introducing a dependency is a different decision from a vulnerability already present on the default branch.

Security overview and organization visibility

Choose security overview when the scenario is about aggregate visibility, prioritization, and security posture across repositories.

This is especially relevant when the scenario mentions:

• Security teams needing a centralized view
• Many repositories
• Comparing coverage across teams
• Prioritizing unresolved alerts
• Identifying repositories without expected security features enabled
• Tracking remediation progress

If the question asks for centralized visibility, do not jump straight to individual repository settings unless the scenario narrows the scope to one repository.

Permissions, roles, and least privilege

GH-500 scenarios often include a user or team that needs to manage alerts, configure security features, or view security data.

Read permission facts carefully:

• Does the user need to administer the entire repository?
• Do they only need to view or triage security alerts?
• Is the access needed for one repository, many repositories, or the whole organization?
• Is the organization trying to avoid broad administrative permissions?
• Is the action operational, such as managing alerts, or governance-focused, such as enforcing settings?

The most defensible answer grants the minimum access that allows the required security work. Avoid choosing broad repository admin access when a security-specific role or narrower permission would satisfy the scenario.

Use a decision sequence for GH-500 scenarios

When the scenario feels dense, use this sequence before looking at the options.

Step 1: What is the problem category?

Classify the issue:

• Code vulnerability
• Secret exposure
• Dependency vulnerability
• Pull request risk
• Security visibility
• Alert triage
• Permission delegation
• Workflow or integration failure
• Organization policy or rollout

Step 2: What is the desired state?

Convert the scenario into a single sentence.

Examples:

• “The organization wants all repositories to have consistent secret protection.”
• “The team wants CodeQL results for a compiled project with custom build steps.”
• “The security team wants to see third-party scanner results in GitHub.”
• “Developers need to know when a pull request adds a vulnerable dependency.”
• “A non-admin security group needs to manage alerts across repositories.”

This one-sentence version is the decision point.

Step 3: What facts limit the answer?

Identify constraints such as:

• Scope: repo, organization, or enterprise
• Timing: before push, during pull request, after merge, or during periodic scanning
• Tooling: GitHub Actions, external CI, third-party scanner, or CodeQL
• Permissions: admin, security team, maintainer, developer, or auditor
• Disruption tolerance: blocking, warning, alerting, or reporting
• Customization: default setup versus advanced workflow or custom patterns

Step 4: Which option directly satisfies the desired state?

Prefer the answer that is:

• Directly connected to the feature being tested
• Enforceable at the right scope
• Compatible with the stated environment
• Least disruptive while still meeting the security requirement
• Based on least privilege
• Durable and repeatable, not manual and one-off unless the scenario asks for a one-time action

Step 5: Check whether the answer fixes the cause or only the symptom

For troubleshooting scenarios, avoid answers that merely hide the problem.

Examples:

• If code scanning is failing because the project needs a build, configure the workflow with the required build steps rather than disabling analysis.
• If alerts are not appearing from a third-party scanner, verify SARIF generation and upload rather than replacing the scanner without cause.
• If secret scanning detects a real credential, rotate or revoke the credential rather than only dismissing the alert.
• If dependency review is needed in pull requests, enabling a feature that only reports existing alerts may not satisfy the pull request requirement.

Interpret scenario wording precisely

Small wording differences can change the best answer.

“Prevent” versus “detect”

If the scenario says prevent, look for controls that stop or block risky changes.

• Prevent secret commits: push protection.
• Detect existing secrets: secret scanning alerts.
• Detect code vulnerabilities: code scanning.
• Prevent vulnerable dependencies from entering through pull requests: dependency review or a PR-focused control, depending on the scenario.

“Existing” versus “new”

Existing risks and newly introduced risks often use different workflows.

• Existing vulnerable dependency: Dependabot alert and remediation workflow.
• New vulnerable dependency in a pull request: dependency review.
• Existing exposed credential: rotate or revoke, then remediate repository exposure.
• New secret about to be pushed: push protection.

“Native GitHub visibility” versus “replace the tool”

If a scenario says the organization already uses another scanner and wants results visible in GitHub, do not assume it must abandon the existing scanner. For code scanning integrations, SARIF is commonly the relevant path for bringing compatible external results into GitHub.

“Custom” usually matters

Custom facts often rule out the simplest setup.

Examples:

• Custom build steps may require an advanced CodeQL workflow.
• Custom internal token formats may require custom secret scanning patterns.
• Custom query requirements may require a CodeQL query pack or tailored configuration.
• Custom CI pipelines may require explicit integration rather than a default GitHub Actions-only assumption.

“At scale” changes the answer

When a scenario describes dozens, hundreds, or all repositories, think about organization-level management.

Look for answers involving:

• Organization-level security settings or policies
• Security configurations where available
• Centralized views such as security overview
• Appropriate team or role assignment
• Standardized workflows or reusable patterns

Manual repository-by-repository work is less defensible when the scenario emphasizes scale and consistency.

Choose the least disruptive effective action

Security questions often include strong controls that sound safe but may be broader than needed. The best GH-500 answer should meet the requirement without unnecessary operational damage.

Use these comparisons:

• If developers only need to be warned or reviewed, do not choose an answer that blocks all work unless blocking is required.
• If one repository has a misconfigured workflow, do not change organization-wide policy unless the scenario asks for broad enforcement.
• If a team needs alert management, do not grant full administrative rights when a narrower role works.
• If a scanner integration is failing, troubleshoot logs, workflow configuration, and upload paths before replacing the tool.
• If a vulnerable dependency can be remediated with a targeted update, do not choose a broad rewrite or removal unless the scenario requires it.

“Least disruptive” does not mean “least secure.” It means the control is strong enough for the stated risk and no broader than necessary.

Apply least privilege to every permission scenario

When a question includes users, teams, or roles, pause before choosing.

Ask:

• What task must this person or team perform?
• Do they need read-only visibility, alert triage, configuration access, or repository administration?
• Is the access temporary or ongoing?
• Is the access for one repository or many?
• Does the scenario explicitly require repository admin rights?
• Is there a security-specific role or narrower permission that fits?

A strong answer gives enough access to perform the security function while avoiding unnecessary control over source code, repository settings, or organization administration.

Troubleshoot from the closest evidence

For operational scenarios, start with evidence nearest the failing system.

Code scanning troubleshooting

If code scanning does not produce expected results, consider:

• Is the feature enabled for the repository?
• Is the workflow running on the expected branch or event?
• Are the language and build process supported by the selected setup?
• Does the project require explicit build steps?
• Are CodeQL initialization and analysis steps configured correctly?
• Are workflow permissions sufficient for uploading results?
• If using another scanner, is a valid SARIF file being generated and uploaded?
• Are results associated with the correct repository, branch, or category?

Choose an answer that investigates or corrects the specific failure point described.

Secret scanning troubleshooting

If secret scanning is not behaving as expected, consider:

• Is secret scanning enabled at the required scope?
• Is push protection enabled if the scenario requires prevention?
• Is the secret format supported by default patterns?
• Is a custom pattern needed for an internal credential format?
• Was the secret already committed before protection was enabled?
• Was a bypass used, and does it require review?
• Has the exposed credential been revoked or rotated?

For secrets, do not treat alert cleanup as a substitute for credential remediation.

Dependency troubleshooting

If dependency alerts or updates are not appearing as expected, consider:

• Are dependency manifests recognized?
• Is dependency graph data available for the repository?
• Are Dependabot alerts enabled where required?
• Are security updates enabled if automated remediation PRs are expected?
• Is the issue about an existing vulnerability or a pull request introducing a dependency?
• Are version constraints preventing an automatic update?
• Is the repository configuration consistent with the desired update behavior?

The best answer usually matches the specific dependency workflow in the scenario.

Mini-scenarios: practice the reasoning

Scenario 1: Organization-wide secret prevention

An organization wants to stop developers from pushing internal API keys to any repository. The keys use a company-specific format.

Reasoning:

• Risk type: secrets.
• Timing: before the secret enters the repository.
• Scope: organization-wide.
• Special fact: internal custom format.

Most defensible direction: use secret scanning with a custom pattern for the internal key format and enable push protection at the appropriate scope, such as organization or repository settings depending on what the scenario allows.

Why: ordinary alerting is useful, but the scenario asks to stop pushes and includes a custom secret format.

Scenario 2: Existing SAST tool, GitHub alert visibility

A team already runs a third-party static analysis tool in external CI. Security leadership wants findings to appear in GitHub code scanning alerts without replacing the tool.

Reasoning:

• Risk type: code vulnerabilities.
• Existing tool: third-party scanner.
• Desired outcome: GitHub visibility.
• Constraint: do not replace the scanner.

Most defensible direction: generate compatible SARIF from the scanner and upload it to GitHub code scanning.

Why: the requirement is integration and visibility, not migration to a different scanner.

Scenario 3: CodeQL with a custom build

A repository uses a compiled language and requires several custom build commands before analysis. A simple setup does not produce useful results.

Reasoning:

• Risk type: code scanning.
• Tool: CodeQL.
• Constraint: custom build process.
• Problem: simple setup is insufficient.

Most defensible direction: use an advanced CodeQL workflow with the required build steps and analysis configuration.

Why: the scenario describes a build-dependent analysis need, not a reason to disable scanning.

Scenario 4: Pull request dependency risk

Developers want to know when a pull request introduces a dependency with a known vulnerability before the change is merged.

Reasoning:

• Risk type: dependency vulnerability.
• Timing: pull request review.
• Desired outcome: evaluate new dependency risk before merge.

Most defensible direction: use dependency review or a pull-request-oriented dependency control.

Why: Dependabot alerts help with existing vulnerable dependencies, but the scenario focuses on risk introduced by a pull request.

Scenario 5: Security team needs alert management

A security team needs to manage security alerts across repositories but should not receive broad repository administrator rights.

Reasoning:

• Risk type: permission delegation.
• Desired outcome: manage security alerts.
• Constraint: least privilege, avoid admin access.

Most defensible direction: assign an appropriate security-focused role or permission that allows alert management without full repository administration.

Why: the scenario is primarily about least-privilege access, not enabling another scanner.

Build a quick answer checklist

Before selecting an option, confirm:

• Did I identify the exact security domain: code, secret, dependency, permission, or visibility?
• Did I determine the scope: repository, organization, or enterprise?
• Did I distinguish detection, prevention, remediation, and reporting?
• Did I separate existing risk from new risk?
• Did I account for custom builds, custom patterns, external tools, or CI constraints?
• Did I choose the action that satisfies the requirement most directly?
• Did I avoid granting broader permissions than needed?
• Did I choose a durable configuration rather than a manual workaround when the scenario asks for scale?
• Did I prioritize credential rotation or revocation when a real secret is exposed?
• Did I verify that the answer addresses the stated goal, not just the general topic?

Practice with final-review habits

For GH-500 final review, practice reading scenarios slowly and reducing each one to:

1. Scope: Where does the control apply?
2. Risk: What security issue is being addressed?
3. Timing: Is the scenario before push, during PR, after merge, or during ongoing monitoring?
4. Constraint: What must the answer not violate?
5. Action: Which GitHub Advanced Security feature or configuration directly satisfies the requirement?

Then compare the answer choices against that summary. The best answer should feel specific, proportionate, and enforceable.

For your next study step, run focused scenario drills by domain: code scanning, secret scanning, dependency security, permissions, and organization-wide visibility. After that, take a timed GH-500 mock exam and review every missed question by writing the decision point you should have identified before choosing an answer.