Prepare for GitHub Advanced Security (GH-500) with free sample questions, a full-length diagnostic, topic drills, timed practice, secret scanning, dependency risk, code scanning, CodeQL, workflow security, GHAS governance, and detailed explanations in IT Mastery.
GitHub Advanced Security validates code-security knowledge across vulnerability identification, workflow security, secure implementation, and GitHub Advanced Security tooling in enterprise software development.
IT Mastery practice for GitHub Advanced Security (GH-500) is live now. Use this page to start the web simulator, review the exam snapshot, work through 24 public sample questions, and continue into full IT Mastery practice with the same IT Mastery account on web, iOS, iPadOS, macOS, or Android.
Start a practice session for GitHub Advanced Security (GH-500) below, or open the full app in a new tab. For the best experience, open the full app in a new tab and navigate with swipes/gestures or the mouse wheel—just like on your phone or tablet.
Open Full App in a New TabA small set of questions is available for free preview. Subscribers can unlock full access by signing in with the same app-family account they use on web and mobile.
Prefer to practice on your phone or tablet? Download the IT Mastery – AWS, Azure, GCP & CompTIA exam prep app for iOS or IT Mastery app on Google Play (Android) and use the same IT Mastery account across web and mobile.
Free diagnostic: Try the GitHub Advanced Security GH-500 full-length practice exam before subscribing. Use it as one GHAS baseline, then return to IT Mastery for timed mocks, topic drills, explanations, and the full GH-500 question bank.
| Domain | Weight |
|---|---|
| Describe the GHAS security features and functionality | 10% |
| Configure and use secret scanning | 10% |
| Configure and use dependency management | 15% |
| Configure and use code scanning | 15% |
| Use code scanning with CodeQL | 20% |
| Describe GitHub Advanced Security best practices | 20% |
| Configure GitHub Advanced Security tools in GitHub Enterprise | 10% |
Use this flow to keep the GHAS tools straight. Most questions ask whether the problem is about exposed secrets, vulnerable dependencies, code patterns, or enterprise rollout governance.
flowchart LR
Code["Repository code"] --> Secret["Secret scanning"]
Code --> CodeQL["Code scanning / CodeQL"]
Manifest["Dependency manifests"] --> Dependabot["Dependabot alerts"]
PullRequest["Pull request"] --> Review["Dependency review"]
Secret --> Triage["Alert triage"]
CodeQL --> Triage
Dependabot --> Triage
Review --> Gate["Merge decision"]
Triage --> Fix["Fix, revoke, upgrade, dismiss, or document"]
Enterprise["Enterprise policy"] --> Secret
Enterprise --> CodeQL
Enterprise --> Dependabot
GitHub Advanced Security questions often turn on a small exhibit: an alert summary, a workflow permissions block, a CodeQL setup snippet, a dependency diff, or an enterprise policy note. First identify which GHAS feature is involved, then choose the response that reduces risk without bypassing normal review.
| Exhibit type | What to decide |
|---|---|
| Secret scanning alert | whether to rotate, revoke, investigate exposure, remediate code, or document closure |
| Dependency review output | whether a newly added dependency introduces known vulnerability or license risk before merge |
| CodeQL workflow snippet | whether languages, build mode, query packs, and upload permissions match the repository |
| SARIF upload step | whether a third-party scanner can surface findings in GitHub code scanning |
| Branch protection or ruleset | whether security checks block merges at the right severity and scope |
| Enterprise rollout note | whether ownership, triage, reporting, and exception handling are defined |
Example secret-scanning exhibit:
Alert: AWS_ACCESS_KEY_ID detected in app/config/prod.env
Location: default branch
Status: open
Last seen: latest commit
Best first response: treat the credential as exposed. Revoke or rotate it, check for use, remove it from code and history where appropriate, then close the alert with evidence.
Example CodeQL workflow exhibit:
permissions:
contents: read
security-events: write
steps:
- uses: github/codeql-action/init@v3
with:
languages: javascript-typescript, python
- uses: github/codeql-action/analyze@v3
Best reading: the workflow has the minimum upload permission and initializes analysis for two language families. If analysis fails, check build mode, dependency setup, generated code, and whether the selected language needs a build step.
Example dependency-review exhibit:
| Pull request change | Risk cue |
|---|---|
package-lock.json adds a new transitive package | check whether the dependency review flags a known vulnerable version |
| Runtime dependency added for production code | assess severity, exploitability, and whether an upgrade or alternative exists |
| License changes on a new library | route to the organization’s license policy before merge |
Use these filters when several security actions look plausible:
| Day | Practice focus |
|---|---|
| 7 | Take the free full-length diagnostic and tag misses by GHAS feature and response type. |
| 6 | Drill secret scanning, push protection, rotation, validity checks, and alert closure reasoning. |
| 5 | Drill Dependabot alerts, dependency review, version upgrades, transitive risk, and merge gating. |
| 4 | Drill code scanning, CodeQL setup, SARIF, workflow permissions, query packs, and build modes. |
| 3 | Drill GHAS best practices, triage, remediation, false positives, governance, and enterprise rollout. |
| 2 | Complete a timed mixed set and explain which security signal drove every miss. |
| 1 | Review weak alert workflows and CodeQL setup patterns; avoid cramming rare configuration details. |
If several unseen mixed attempts are above roughly 75% and you can explain the alert type, triage action, and governance boundary behind your answers, you are likely ready. More practice should improve security response judgment, not turn alerts into memorized examples.
Use these child pages when you want focused IT Mastery practice before returning to mixed sets and timed mocks.
Need concept review first? Read the GitHub Advanced Security GH-500 Cheat Sheet on Tech Exam Lexicon, then return here for timed mocks, topic drills, and full IT Mastery practice.
These are original IT Mastery practice questions aligned to the live GitHub Advanced Security (GH-500) route and the main blueprint areas shown above. Use them to test GHAS feature selection, triage, CodeQL, secret scanning, dependency risk, and rollout judgment here, then continue in IT Mastery with mixed sets, topic drills, and timed mocks.
Topic: Describe the GHAS Security Features and Functionality
Your AppSec team has access to Security Overview for an organization that uses GitHub Advanced Security across 240 private repositories. You have time to focus on only a small set of repositories this sprint and want the most risk-based starting point.
Exhibit:
Security Overview summary
- Repositories with open alerts: 38
- Repositories with code scanning disabled: 27
- Repositories with secret scanning disabled: 19
- Repositories with open alerts and at least one disabled feature: 11
What is the best security action?
Best answer: A
Explanation: Security Overview is the right tool for comparing repositories by both unresolved alerts and feature coverage. The best first step is to target repositories that have known findings and missing protections, because they represent immediate risk plus weak visibility. Security Overview gives organization-level visibility into both security findings and GHAS feature adoption, so it is the best place to prioritize work across many repositories. In this scenario, the most important set is the overlap between repositories with open alerts and repositories missing code scanning or secret scanning. Those repositories already have unresolved risk and also lack full security coverage, which makes them the highest-value starting point.
A sound prioritization approach is:
Manual per-repository review is slower and less consistent, while activity data or a single broad enablement action does not directly target the repositories with the clearest combined risk signal.
Topic: Configure GitHub Advanced Security Tools in GitHub Enterprise
A GitHub Enterprise Cloud organization has 280 private repositories. A security policy requires pull requests to main to use a repository ruleset that blocks merges unless dependency review and code scanning pass. The AppSec team needs a nightly report, including repositories with no open pull requests, that identifies repos missing this protection and lists open code scanning alerts. They want to avoid manual repository-by-repository review. Which approach best fits this requirement?
Best answer: C
Explanation: This is a bulk governance and reporting problem, so the best fit is API-based automation. GitHub REST API endpoints let the team audit repository protections and collect code scanning alerts across all repositories on a schedule, including inactive repositories. For enterprise-scale GHAS governance, the right pattern is to automate against GitHub APIs instead of checking each repository in the UI. In this scenario, the team must do two things across hundreds of repositories: verify that the required pull request protections are configured, and collect open code scanning alerts for remediation. Scheduled automation can enumerate repositories, query ruleset or related settings programmatically, and retrieve code scanning alert data into one central report or workflow.
That approach is stronger because it is repeatable, covers repositories with no current pull requests, and supports centralized remediation tracking. Human attestations, templates, or waiting for pull request failures are all reactive or manual. The key takeaway is to map cross-repository GHAS administration and review cadence needs to API automation.
Topic: Configure and Use Secret Scanning
A company uses GitHub Enterprise Cloud with GitHub Advanced Security enabled for its private repositories. In one repository, developers have twice pushed supported cloud credential types to feature branches, and secret scanning created alerts only after the commits reached GitHub. The security team wants the best control to stop the same type of exposure earlier.
What is the best security action?
Best answer: A
Explanation: The team wants prevention before the secret reaches GitHub, not detection afterward. Push protection is the GHAS control designed to block supported secrets at push time, which directly addresses that requirement. Push protection is part of secret scanning and is used when the goal is to prevent supported secrets from entering the repository in the first place. In this scenario, secret scanning alerts already occur after developers push commits, so detection alone is too late. Enabling push protection at the repository or organization level adds a pre-commit-to-remote control that can stop the push when a supported secret is detected.
Validity checks can help prioritize alerts, but they do not replace prevention and should not be used as a reason to ignore exposed credentials. Other GHAS features such as Dependabot and SARIF-based code scanning address different risks, not leaked secrets during push. The key distinction is prevention before the push versus alerting after the secret is already in Git history.
Topic: Describe GitHub Advanced Security Best Practices
A private repository named payments-api uses GitHub Advanced Security. The team’s written security policy says that main must block direct pushes, require a pull request with CODEOWNERS approval, and require passing code scanning and dependency review checks before merge.
An audit finds that main still allows direct pushes by maintainers and does not require any status checks.
What is the best security action?
main protection to block direct pushes and require CODEOWNERS-reviewed PRs and security checks.Best answer: C
Explanation: The policy defines how changes are allowed onto main, so the right control is branch protection. Strengthening branch protection enforces pull requests, CODEOWNERS review, and required GHAS checks before a merge can happen. Branch protection is the preventive control that converts a written merge policy into enforced repository behavior. Here, the problem is not visibility; it is that main still accepts changes that violate the policy. The best action is to configure main so changes must come through a pull request, require CODEOWNERS approval, and require the specified security checks to pass before merge. That directly aligns the branch with the policy’s stated requirements.
Secret scanning push protection targets leaked secrets, Dependabot security updates address some vulnerable dependencies, and Security Overview helps with monitoring and governance. Those are useful GHAS features, but they do not replace merge-time enforcement on the protected branch. When the policy says changes must be reviewed and pass checks, the repository should block noncompliant merges rather than detect them afterward.
Topic: Configure and Use Code Scanning
A private repository uses a ruleset that blocks merges to main when a pull request introduces a new high-severity code scanning alert. In PR #84, CodeQL reports:
Rule: java/path-injection
Severity: High
File: src/main/java/com/acme/ReportController.java
Source: request.getParameter("name")
Sink: Files.readString(Path.of("/reports", name))
Show paths: user input -> name -> Path.of -> Files.readString
Context: production endpoint, not test code
PR diff: no allowlist, canonicalization, or other validation of name
Security policy: dismiss only for false positives, test-only code, or documented accepted risk
Which action should the reviewer take?
/reports.Best answer: D
Explanation: This alert should stay open because the evidence supports a real production risk, not a dismissal reason. The CodeQL path shows user-controlled input reaching file access without validation, and the repository policy says such alerts must be remediated unless there is documented evidence for dismissal. Code scanning triage depends on whether the evidence supports remediation or a valid dismissal reason. Here, the show paths result maps untrusted request data directly to a file read in production code, and the stem explicitly says there is no allowlist, canonicalization, or other validation. That makes the alert consistent with a true positive, so the correct response is to keep it open and require a code change before merge.
A code scanning dismissal is appropriate only when the evidence matches the dismissal reason, such as test-only code, a true false positive, or a documented accepted risk. None of those conditions are present here, and the ruleset is intended to stop new high-severity issues from entering main. A fixed parent directory alone does not prove the flow is safe.
Topic: Use Code Scanning with CodeQL
A company analyzes a private monorepo in an isolated Jenkins environment because its Java and C# builds cannot run in GitHub Actions. GHAS is enabled on the repository. The external pipeline already runs:
codeql database create app-db ...
codeql database analyze app-db --format=sarifv2.1.0 --output=results.sarif
Security wants these findings to appear as GitHub code scanning alerts in the repository. What is the best security action?
app-db to the default branch.results.sarif to GitHub code scanning.Best answer: B
Explanation: When CodeQL runs outside GitHub, the repository does not receive alerts automatically from the database files alone. The results must be exported as SARIF and uploaded to GitHub code scanning so developers can view and triage them in GitHub. The key concept is the external CodeQL result flow. codeql database create and codeql database analyze produce analysis output, but GitHub code scanning displays externally generated findings only after they are uploaded in SARIF format. In this scenario, the pipeline already creates results.sarif, so the next required step is to upload that SARIF file to the repository’s code scanning results.
A raw CodeQL database is an intermediate analysis artifact, not the format GitHub uses to create code scanning alerts. Dependabot security updates handle vulnerable dependencies, and default setup in GitHub Actions would change the execution model instead of publishing the findings that were already generated externally.
If CodeQL runs outside GitHub, think: analyze, produce SARIF, then upload SARIF.
Topic: Configure and Use Dependency Management
A compliance team needs a machine-readable inventory of the third-party software components used by a private GitHub repository so they can share it with an external auditor. They do not need vulnerability alerts, automated fixes, or pull request blocking for this task. Which GitHub choice best meets this requirement?
Best answer: A
Explanation: The best choice is to use an SBOM because it provides a machine-readable inventory of the software components in the repository. In GitHub, this is based on dependency data and is meant for transparency and supply-chain reporting, not just vulnerability detection or remediation. A Software Bill of Materials (SBOM) is an inventory of the software components that make up an application, such as packages and their versions. In GitHub dependency management, the dependency graph provides the component data, and exporting an SBOM turns that data into a shareable artifact for auditing, supplier disclosure, and incident response.
This fits the scenario because the requirement is to describe what is in the software, not to detect vulnerable packages, block dependency changes in pull requests, or automatically open remediation PRs. Those other features support risk management and remediation, but they do not represent the software component inventory itself.
The key distinction is that an SBOM answers “what components are included,” while Dependabot and dependency review answer different security questions.
Topic: Describe the GHAS Security Features and Functionality
Your company uses GitHub Enterprise Cloud with GHAS enabled for a private monorepo. The security lead wants one GitHub-native setup that will:
Which GHAS configuration best meets all requirements?
Best answer: D
Explanation: The scenario covers three different security problems, so one GHAS feature is not enough. The best setup combines secret scanning with push protection, dependency review with Dependabot capabilities, and CodeQL code scanning to address prevention, pull request risk review, and code analysis together. This scenario requires recognizing that GHAS features cover different parts of the software security workflow. Secret scanning with push protection is used to stop supported secrets before they enter the repository. Dependency review helps reviewers see risky dependency changes in pull requests, while Dependabot alerts and security updates help identify and remediate known vulnerable packages. Code scanning with CodeQL analyzes the source code itself for insecure patterns and vulnerabilities.
A good GHAS design often uses multiple features together:
Security Overview is useful for visibility, but it does not replace the underlying detection and prevention features.
Topic: Configure GitHub Advanced Security Tools in GitHub Enterprise
Your company uses GitHub Enterprise Cloud with GitHub Advanced Security enabled. A central AppSec team holds the organization security manager role for the finance organization. A repository administrator for invoice-api sees repeated secret scanning alerts for the placeholder string PLACEHOLDER_TOKEN, and other repositories in the organization report the same false positive. The repository admin does not have organization-level security permissions and wants a durable fix across the organization. What should they do?
invoice-api alert and let each repo handle its own false positives.invoice-api until the placeholder string is no longer used.Best answer: B
Explanation: This issue affects multiple repositories, so the best fix is an organization-wide secret scanning configuration change. A repository administrator can triage alerts in one repository, but an organization security manager is responsible for shared GHAS security settings across the organization. The key distinction is scope. Repository administrators work within an individual repository: they can investigate, remediate, and sometimes dismiss alerts for that repo. Organization security managers handle centralized GHAS governance for the organization, including shared security settings that should apply across many repositories.
Because the same false positive appears in multiple repositories, the durable response is to have the organization security manager review and tune the organization-level secret scanning configuration, such as a custom pattern or exclusion. Dismissing the alert in one repository would not stop the same noise elsewhere. Disabling secret scanning would reduce protection, and code scanning controls do not apply to secret scanning alerts.
When the problem is organization-wide, the responsibility moves from repository administration to organization security management.
Topic: Configure and Use Secret Scanning
Your company uses GitHub Enterprise Cloud with GitHub Advanced Security. The security team must enable secret scanning for every current and future private repository in the payments organization. Other organizations in the enterprise will keep their own security settings, and repository admins should not have to enable it one repository at a time. What is the best security action?
payments organization and have new repositories inherit it.payments organization to detect exposed credentials.Best answer: B
Explanation: The requirement applies to all current and future repositories in a single organization, so the correct scope is organization-level secret scanning enablement. That meets the coverage goal without forcing manual repository-by-repository setup or affecting unrelated organizations. Secret scanning scope should match the policy boundary. Because the requirement is for all private repositories in one organization, the best fit is to enable secret scanning at the organization level for that organization and ensure new repositories get the same setting. This centralizes coverage and removes the need for each repository admin to opt in manually.
The closest distractor is enterprise-wide enablement, but that is broader than the stated requirement.
Topic: Describe GitHub Advanced Security Best Practices
An organization uses GitHub Advanced Security on a private payment-service repository. A critical code scanning alert for SQL injection is open on the default branch, but the team cannot deploy a fix until a two-week release freeze ends. The repository has no formal way to assign or track unresolved security findings. What is the best action for the security lead?
won't fix and revisit it after the freezeBest answer: C
Explanation: The main risk is not just the delayed fix; it is leaving a critical finding without accountable follow-up. A tracked remediation ticket with ownership, timing, and documented interim handling prevents the alert from becoming unmanaged risk during the freeze. GHAS helps identify and prioritize serious findings, but visibility alone is not a remediation process. In this scenario, the team already knows the code scanning alert is critical and valid, and they cannot fix it immediately because of the release freeze. The best practice is to keep the issue under explicit management so it is not lost, deprioritized indefinitely, or silently treated as accepted risk.
An unowned open alert or an informal reminder is weaker than formal tracking, and dismissing a valid critical alert without evidence is inappropriate.
Topic: Configure and Use Code Scanning
A private repository uses GitHub Advanced Security code scanning with CodeQL. A SQL injection alert appears on main minutes after a pull request is merged. Review shows the vulnerable code was already present in the pull request, but no code scanning results were shown during review.
on:
push:
branches: [main]
schedule:
- cron: '15 3 * * 1'
The team wants future findings to appear before merge. Which action best addresses the root cause?
pull_request trigger for pull requests into mainmainBest answer: B
Explanation: The problem is workflow timing, not alert triage. The workflow only runs on pushes to main and on a schedule, so the pull request was never analyzed before merge; adding a pull_request trigger fixes that gap. This scenario is about code scanning workflow trigger design. Because the workflow runs only on push to main and on a scheduled job, CodeQL does not analyze the pull request itself, so reviewers see no code scanning results before merging.
To surface findings during review, the workflow must run on pull_request for the relevant target branch. That is the change that moves detection into the PR phase. Remediating the current code, dismissing the alert, or scanning main more often are separate alert-handling choices, but none of them changes when PRs are scanned.
The key distinction is that trigger configuration controls pre-merge visibility, while dismissal or remediation decisions deal with findings after they exist.
Topic: Use Code Scanning with CodeQL
A private repository uses a repository ruleset that requires successful code scanning checks before merging to main. A pull request updates a Java service in a monorepo.
CodeQL run summary
- javascript-typescript: Analysis completed, SARIF uploaded
- java: Autobuild failed
- Log: Could not find compiled classes. No results were generated for java.
- Security tab for this PR: No new code scanning alerts
Which statement is most accurate?
Best answer: D
Explanation: For compiled languages such as Java, CodeQL needs a successful build to generate analysis results. Here, the Java autobuild failed and GitHub reported that no results were generated, so the blocked pull request reflects a build configuration problem rather than a vulnerability finding. CodeQL treats compiled and interpreted languages differently. For Java, CodeQL must observe a successful build so it can create the analysis data for that language. If autobuild fails, GitHub cannot produce Java code scanning results, so there is no Java alert to triage or dismiss.
In this scenario, the repository ruleset requires successful code scanning checks on pull requests. The JavaScript analysis completed, but the Java analysis did not because the build failed. That leaves the required check unsuccessful and blocks the merge. The correct response is to fix the Java build configuration or provide explicit build steps, then rerun CodeQL.
A failed build prevents findings from being created; it is not itself a vulnerability finding.
Topic: Configure and Use Dependency Management
A private monorepo uses repository rulesets to require pull requests and dependency review before merge. The security policy allows automatic dismissal of Dependabot alerts only when the alert is low severity and the vulnerable package is a development-scoped dependency under /test-tools/, which is never deployed.
Which configuration best meets this requirement?
/test-tools/./test-tools/./test-tools/.Best answer: D
Explanation: The correct choice is the narrow Dependabot auto-triage rule that combines low severity with the explicit safe condition: development-scoped dependencies in /test-tools/. That reduces noise without hiding alerts that could affect deployed code. Dependabot alert dismissal should be scoped as tightly as the policy allows. Here, the approved exception is not simply “low severity” or “test-tools” by itself; it is the combination of low severity, development scope, and a non-deployed path. A Dependabot auto-triage rule is the correct mechanism because it can automatically dismiss only alerts that match those conditions.
Repository rulesets and dependency review still help protect pull requests, but they do not replace Dependabot alert triage. Broad dismissal rules are risky because they can hide production-relevant alerts or higher-severity issues that still need review. Code scanning is also the wrong feature because it manages code analysis findings, not vulnerable dependency alerts.
The key is to make the auto-dismiss rule as specific as the safe condition in the policy.
Topic: Describe the GHAS Security Features and Functionality
Your GitHub Enterprise Cloud organization has GHAS enabled for a private payments monorepo. During one sprint, security found three different problems:
The team wants GitHub to catch these issues as early as possible in the developer workflow instead of relying on one manual review after merge. What is the best security action?
Best answer: D
Explanation: The scenario includes three different problem types: exposed secrets, vulnerable dependency changes, and insecure code paths. No single GHAS feature covers all of them, so the best response is a layered workflow that uses the right control for each risk. GHAS features have different scopes. Push protection addresses secret exposure before a secret is committed to the repository history. Dependency review helps evaluate dependency changes in pull requests so a vulnerable package version can be identified before merge. Code scanning with CodeQL analyzes source code for insecure patterns such as injection or unsafe data flows.
Because the repository is facing all three risks, treating this as one generic security review leaves gaps. A single-feature choice would only cover one part of the problem. The strongest approach is to combine the GHAS capabilities that match each risk and surface them during normal pull request and push workflows.
Topic: Configure GitHub Advanced Security Tools in GitHub Enterprise
Your GitHub Enterprise Cloud organization plans to use an organization ruleset to block merges unless required code scanning checks pass and dependency review shows no high or critical findings. Audit policy requires each repository to have a documented alert owner, dismissal criteria, and an exception path before merge-blocking is enforced, but many teams have not yet been notified. Which configuration choice is best?
Best answer: A
Explanation: Strict GHAS merge gates should follow governance readiness, not create it. Applying blocking rules only where ownership, documentation, and communication already exist prevents unmanaged PR blocks and supports an accountable rollout. The key concept is rollout governance before enforcement. GHAS gates such as required code scanning checks and dependency review can stop merges, so teams need to know who owns alerts, how dismissals are documented, and how exceptions are requested before those gates become mandatory. A sound enterprise rollout enables visibility broadly, assigns responsibility, publishes the handling process, communicates expectations, and then enforces blocking rules on the repositories that are operationally ready. That approach reduces confusion, avoids stalled pull requests, and makes audit evidence clear. Simply turning on strict gates first may surface problems faster, but it shifts governance failures onto delivery teams and creates unowned blocking events.
Topic: Configure and Use Secret Scanning
A repository uses GitHub Advanced Security secret scanning with push protection. The testdata/ folder contains a few generated fixture files that repeatedly trigger false positives, but the security team is concerned that developers sometimes store temporary credentials in nearby test files before cleanup. Which configuration is the best way to reduce noise without hiding real secrets?
testdata/** path from secret scanning.json and .yaml files from secret scanningBest answer: D
Explanation: The safest choice is the most specific exclusion that solves the false-positive problem. Broad path or file-type exclusions can suppress alerts for real secrets in places where developers may still accidentally commit credentials. This scenario is about avoiding overly broad secret scanning exclusions. When only a small set of known generated fixtures is noisy, the best GitHub Advanced Security configuration is to exclude just those files or patterns as narrowly as possible. That keeps secret scanning and push protection active for the rest of the repository, including nearby test artifacts where real secrets might still appear.
Broad exclusions such as an entire folder or common file types reduce visibility too much and can hide genuine exposures. Disabling push protection is even riskier because it removes prevention before secrets enter the repository. The goal is to reduce alert noise without weakening coverage beyond the minimum necessary.
The key takeaway is to scope exclusions as tightly as possible and avoid convenience exclusions that create blind spots.
Topic: Describe GitHub Advanced Security Best Practices
A private GitHub Enterprise Cloud repository for a payment API has GitHub Advanced Security enabled. A code scanning alert on a pull request is marked high severity for SQL injection, and the security team classifies it as a material finding because the service is internet-facing and processes cardholder data. Developers say security should “handle the alert” because GHAS raised it.
Which action is the best next step?
Best answer: A
Explanation: The best action is to use a shared remediation workflow. Security teams provide risk context and prioritization, while developers own the code change, testing, and safe deployment needed to resolve a material finding. For material GHAS findings, remediation should not be owned by only one team. Security teams are best positioned to assess severity, exploitability, exposure, and business impact, while developers are best positioned to understand the code, implement the fix, run tests, and ship safely.
A shared workflow keeps both responsibilities connected:
This reduces delays, prevents unsupported dismissals, and creates a clear audit trail. Having security “own” the alert alone is the closest distractor, but it breaks down because security usually should not be the sole team writing and validating application fixes.
Topic: Configure and Use Code Scanning
A repository ruleset requires code scanning results before pull requests can merge. The repository uses a third-party analyzer, not CodeQL. After the workflow was split into frontend and backend jobs, both jobs generate SARIF and both upload steps succeed, but each pull request shows only one analysis result for the commit.
Exhibit:
- name: Upload frontend SARIF
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: frontend.sarif
category: sast
- name: Upload backend SARIF
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: backend.sarif
category: sast
Which action should the team take first?
init and analyze steps before upload-sarif.category for each upload.Best answer: C
Explanation: This is a SARIF upload troubleshooting issue, not a CodeQL workflow issue. The third-party tool is already producing SARIF, and both uploads succeed; the problem is that both uploads use the same category, so GitHub cannot treat them as separate analyses for the same commit. When a repository uploads multiple SARIF results for the same commit, the category helps GitHub distinguish separate analyses. In this scenario, the repository is not using CodeQL to generate findings, so CodeQL-specific troubleshooting such as init, analyze, database creation, or autobuild is not the right first step. The analyzer already ran successfully and produced SARIF.
Because both uploads use category: sast, the frontend and backend uploads are identified the same way. That can cause one uploaded analysis to replace the other for the commit, which is why only one result appears in the pull request. The first fix is to give each upload a unique category and confirm each job uploads the intended SARIF file. The key takeaway is to troubleshoot SARIF upload settings when the issue is result ingestion or separation, and troubleshoot CodeQL only when CodeQL is the analysis engine.
Topic: Use Code Scanning with CodeQL
A team uses third-party CI with the CodeQL CLI for a private repository. A repository ruleset requires code scanning results before pull requests can merge to main.
A pull request is blocked, and the CI log shows:
codeql database create ./db ... completed
codeql database analyze ./db --format=sarif-latest --output=results.sarif ... completed
Uploading SARIF to GitHub code scanning...
POST /repos/fabrikam/payments/code-scanning/sarifs
HTTP 403: Resource not accessible by integration
Which stage is most likely failing?
Best answer: A
Explanation: The log shows that codeql database create and codeql database analyze both finished successfully and produced a SARIF file. The failure occurs when the job tries to send that SARIF file to GitHub, so the broken stage is the code scanning upload step. In a CodeQL CLI pipeline, the usual flow is: create a database, analyze it with queries, generate a SARIF file, and then upload that SARIF file so GitHub code scanning can ingest the results. Here, the first two stages already succeeded, which means source extraction and query execution are not the problem.
The decisive clue is the API call to /code-scanning/sarifs returning HTTP 403. That points to the SARIF upload stage failing, commonly because of token scope, permissions, or execution context. In a pull request workflow with a ruleset or branch protection requiring code scanning results, GitHub cannot mark the required security result as available until the SARIF upload succeeds. The closest distractor is query analysis, but that would fail before a completed SARIF file and upload attempt appear.
Topic: Configure and Use Dependency Management
A private GitHub Enterprise Cloud repository has this Dependabot alert for a production service:
Package: `templater-js`
Manifest: `package-lock.json`
Severity: High
Summary: Remote template loading can allow code execution
Patched version: None
Dependabot security update: Unavailable
Vendor workaround: Set `allowRemoteTemplates=false`
The application does not require remote templates in production, and the team cannot replace the package this sprint. What is the best next action?
Best answer: C
Explanation: The alert explicitly says there is no patched version and no Dependabot security update available. In that situation, the right action is to use a supported workaround or compensating control, document the temporary risk, and continue tracking the alert until a fix is released. A Dependabot alert can identify a real vulnerable dependency even when GitHub cannot offer an upgrade path. When the alert shows Patched version: None, you should not dismiss it or wait passively for automation. Instead, confirm impact, apply any safe vendor-recommended workaround or compensating control, and document a temporary risk decision while the package maintainer works on a fix.
The closest wrong idea is waiting for Dependabot, because the alert already states that an automated security update cannot be created.
Topic: Describe the GHAS Security Features and Functionality
A GitHub Enterprise Cloud repository for an internet-facing checkout API has this code scanning alert on main:
Tool: CodeQL
Rule: SQL injection
Severity: High
Location: api/orders/search.py
Path: request parameter -> query builder -> database call
The service handles payment transactions, so the potential business impact is material. Which response is best?
Best answer: B
Explanation: When a GHAS alert could materially affect a production service, development and security both need to be involved. Developers confirm the code path and implement a safe fix, while security assesses exploitability, exposure, urgency, and any containment or incident actions. For material-risk GHAS alerts, response should be shared rather than owned by only one side. Developers understand whether the reported path is reachable in the real application, what fix is technically correct, and how to deploy it safely without breaking the service. Security brings the broader risk view: potential exposure, likelihood of abuse, business impact, temporary controls, and whether the situation needs escalation or incident handling.
Sending the alert to only one group increases the chance of either underestimating risk or applying an incomplete fix.
Topic: Configure GitHub Advanced Security Tools in GitHub Enterprise
A GitHub Enterprise Cloud admin enabled a new custom secret pattern with push protection for every organization at once. On day one, hundreds of pushes are blocked in legacy automation repositories because placeholder test strings match the pattern, while Security Overview shows real secret scanning alerts concentrated in payment and identity-service repos. Leadership wants less disruption while improving GHAS coverage. What is the best next action?
Best answer: C
Explanation: A phased rollout is best when a preventive control is causing broad disruption but the enterprise still needs better coverage. In this case, secret scanning alerts should remain broad, while push protection is tuned and introduced first where the risk is highest. Push protection is a preventive control, so rolling it out everywhere at once can disrupt development if a custom pattern is not yet well tuned. Here, the blocked pushes show rollout friction, but Security Overview also shows that some repository groups already have real secret exposure risk.
A better enterprise rollout is to:
This approach improves coverage immediately through alerts, protects the most exposed assets sooner, and avoids forcing every team through unnecessary bypasses. Disabling scanning loses visibility, and treating widespread blocks as acceptable simply shifts the disruption onto developers.
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?
**/*.json and review JSON changes manuallytests/fixtures/** only**/*.jsonBest answer: B
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.
| Need | GHAS feature or pattern |
|---|---|
| Detect committed secrets | Secret scanning |
| Prevent supported secrets before push | Push protection |
| Review vulnerable dependency changes in a pull request | Dependency review |
| Track known vulnerable dependencies already present | Dependabot alerts |
| Analyze source-code patterns | Code scanning with CodeQL or SARIF upload |
| Add organization-specific analysis | Custom CodeQL queries or query packs |
| Govern merges | Branch protection, rulesets, and required checks |
| Reduce workflow token risk | Explicit permissions and least privilege |
| Roll out across many repositories | Policies, ownership, reporting, and exception handling |