Try 10 focused GitHub Advanced Security GH-500 questions on Codeql Code Scanning, with explanations, then continue with IT Mastery.
Open the matching IT Mastery practice page for timed mocks, topic drills, progress tracking, explanations, and full practice.
Try GitHub Advanced Security GH-500 on Web View full GitHub Advanced Security GH-500 practice page
| Field | Detail |
|---|---|
| Exam route | GitHub Advanced Security GH-500 |
| Topic area | Configure and Use Code Scanning with Codeql |
| Blueprint weight | 25% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Configure and Use Code Scanning with Codeql for GitHub Advanced Security GH-500. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 25% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
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.
Topic: Configure and Use Code Scanning with Codeql
An organization uses a third-party static analysis tool in Jenkins for a private GitHub Enterprise Cloud repository. The AppSec team wants the tool’s findings to appear as GitHub code scanning alerts in the repository’s Security tab, but they do not want to replace the tool with CodeQL. What is the best security action?
Options:
A. Import the tool’s findings through Dependabot alerts so they appear with other security issues.
B. Export the tool’s findings as SARIF and upload them to GitHub code scanning.
C. Publish the tool’s findings as an SBOM so GitHub can convert them into code scanning alerts.
D. Save the tool’s native JSON report as a workflow artifact and let code scanning ingest it automatically.
Best answer: B
Explanation: GitHub code scanning accepts third-party static analysis results through SARIF. If the team wants to keep its existing analyzer, it should export or convert that analyzer’s output to SARIF and upload the results to code scanning.
The key concept is that GitHub code scanning uses SARIF as the interchange format for third-party static analysis results. When an organization already runs a non-CodeQL analyzer in another CI system, it does not need to replace the tool. Instead, it must generate or convert the scan output to SARIF and upload that file so GitHub can display the findings as code scanning alerts.
This lets teams centralize results in GitHub while keeping their existing scanner. If multiple external tools are uploaded, categories can help separate result sets, but the required upload format is still SARIF.
The closest distractor is storing the report as a build artifact, but arbitrary artifacts are not automatically turned into code scanning alerts.
Topic: Configure and Use Code Scanning with Codeql
A private repository uses GitHub Advanced Security with CodeQL enabled. A repository ruleset requires code scanning results before merging to main. A pull request is blocked after analysis completes. The developer wants to see findings affecting this pull request, and the AppSec team wants a repository-wide view they can filter and triage. What should they use?
Options:
A. Use the pull request’s code scanning check and annotations, and use repository code scanning alerts in the Security tab.
B. Use the pull request’s secret scanning alert, and use branch protection status.
C. Use the pull request’s Actions run logs, and use the repository ruleset page.
D. Use the pull request’s dependency review, and use Dependabot alerts in the Security tab.
Best answer: A
Explanation: Code scanning results are viewed in two main contexts: the pull request for findings tied to the proposed changes, and the repository Security tab for the full alert list and filtering. That matches the developer’s immediate merge issue and the AppSec team’s triage workflow.
GitHub code scanning surfaces results where each audience needs them. In a pull request, relevant findings appear through the code scanning check and, when applicable, inline annotations for changed lines, which helps the developer understand why the PR is blocked. For repository-wide review, the Security tab’s code scanning alerts page is the correct place to view, filter, and triage alerts across the repository.
This scenario is about viewing results, not troubleshooting workflow execution. Actions logs help diagnose analysis failures, but they are not the primary alert review surface. Likewise, Dependabot and secret scanning expose different alert types. The key takeaway is to use pull request context for PR-specific code scanning findings and repository security context for broader alert management.
Topic: Configure and Use Code Scanning with Codeql
A repository uploads two SARIF files for every commit from the same third-party analyzer: one scan covers src/ and the other covers infra/. The security team wants both result sets to appear in GitHub code scanning as distinct analyses so one upload does not replace the other. What is the best workflow adjustment?
Options:
A. Rename each SARIF file before upload.
B. Filter each SARIF file to different severities.
C. Add a unique SARIF category to each upload.
D. Upload each SARIF file to a different branch.
Best answer: C
Explanation: Use a distinct SARIF category when multiple analyses upload results for the same repository and commit. The category tells GitHub code scanning to track those uploads separately, preserving both sets of findings.
A SARIF category identifies the analysis context for an upload. When multiple SARIF results are uploaded for the same commit—especially from the same tool—GitHub needs a way to distinguish them so alerts are tracked separately instead of being conflated or replaced.
A unique category is the right control when scans represent different scopes, such as src/ versus infra/, or different environments or job types. It helps GitHub compare like-with-like over time and keeps governance clearer during triage.
Changing filenames, branches, or severity filters may alter artifacts or coverage, but those settings do not define separate analysis identities in code scanning.
Topic: Configure and Use Code Scanning with Codeql
A repository with GitHub Advanced Security enabled shows this code scanning result for an open pull request:
Rule: SQL injection
Severity: High
State: Open
Branch: feature/report-filter
Pull request: #128 -> main
Location: src/api/report.py:88
Documentation: User-controlled input reaches a SQL query. Use parameterized queries.
What is the best next action?
Options:
A. Inspect src/api/report.py:88 and remediate the query before merging.
B. Merge if tests pass and review the documentation link later.
C. Dismiss the alert because it exists only on feature/report-filter.
D. Wait for a Dependabot alert before taking action.
Best answer: A
Explanation: The alert details show a high-severity code issue in a specific file and line on a pull request targeting main. The best response is to investigate that location and apply the remediation guidance before the change is merged.
Code scanning triage depends on interpreting several alert fields together. Severity helps determine urgency, location tells you exactly where to inspect the risky code, branch and pull request context show whether the issue is about to reach the default branch, and the documentation link explains the finding and likely remediation.
Here, the alert is high severity, the location is a production source file, and the branch is an open PR targeting main. That means the finding should be investigated and fixed in the pull request before merge. Dismissing it just because it is on a feature branch, waiting for a dependency-related alert, or relying on passing tests would ignore what the code scanning alert already tells you.
main, so the issue is about to enter the main code line.Topic: Configure and Use Code Scanning with Codeql
A team uses a third-party SAST tool in GitHub Actions for a private GitHub Enterprise Cloud repository with GitHub Advanced Security enabled. The tool reports 12 findings for a pull request, but no new code scanning alerts appear in the repository.
permissions:
contents: read
steps:
- run: vendor-sast --output results.sarif
- uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: results.sarif
category: vendor-sast
Upload SARIF
HTTP 403: Resource not accessible by integration
What is the best next action?
Options:
A. Wait for Security Overview to sync the external findings automatically.
B. Add security-events: write and rerun the SARIF upload.
C. Rerun only vendor-sast; GitHub will ingest the job log output.
D. Change category to codeql and rerun the workflow.
Best answer: B
Explanation: Third-party findings become code scanning alerts only after GitHub successfully accepts the SARIF file. Here, the analyzer produced results, but the upload failed with a 403, so fixing the upload permission and rerunning it is the right remediation.
A third-party scanner running successfully is not enough by itself to create GitHub code scanning alerts. GitHub must receive and process a SARIF upload for those findings to appear in code scanning. In the scenario, results.sarif was generated, but the upload step failed with HTTP 403, which indicates the workflow token does not have the required permission to write security events.
The correct fix is to grant the workflow security-events: write and rerun the upload or the workflow. The category value only groups or distinguishes result sets; it does not resolve an authorization failure. Likewise, GitHub does not create alerts from job logs or from a later background sync when no SARIF upload succeeded.
The key takeaway is that failed SARIF upload blocks ingestion, so no third-party code scanning alerts can be created.
Topic: Configure and Use Code Scanning with Codeql
A private monorepo has GHAS enabled. CodeQL default setup is generating alerts normally. The team also uploads SARIF from two third-party scanners in the same workflow, and both upload steps succeed, but only the last third-party result set remains visible for each commit.
- uses: github/codeql-action/upload-sarif
with:
sarif_file: iac.sarif
- uses: github/codeql-action/upload-sarif
with:
sarif_file: containers.sarif
What is the best security action?
Options:
A. Add a CodeQL autobuild step before the uploads.
B. Add a distinct category to each SARIF upload.
C. Expand the CodeQL query suite for the repository.
D. Split CodeQL into separate language-specific jobs.
Best answer: B
Explanation: This is a SARIF upload categorization issue, not a CodeQL workflow issue. Because CodeQL is already producing alerts, the symptom of one third-party result set replacing another points to missing distinct category values on the SARIF uploads.
The core concept is that SARIF upload troubleshooting is different from CodeQL analysis troubleshooting. Here, CodeQL default setup is already working, so changing CodeQL queries, build steps, or job structure targets the wrong component. The problem is with multiple third-party SARIF uploads for the same commit in the same workflow.
category when you want GitHub to keep them as separate code scanning results.upload-sarif is for publishing third-party results; it does not mean the issue is with CodeQL analysis itself.The key takeaway is to troubleshoot missing third-party findings at the SARIF upload layer before modifying a healthy CodeQL workflow.
autobuild helps CodeQL prepare compiled code, not preserve separate third-party SARIF uploads.Topic: Configure and Use Code Scanning with Codeql
A private repository uses this CodeQL workflow:
on:
push:
branches: [main]
schedule:
- cron: '30 4 * * 1'
AppSec reviews code scanning alerts in the repository Security tab. Developers must also see new code scanning findings during pull request review before merge. Which workflow adjustment is best?
Options:
A. Increase the scheduled scan frequency for main.
B. Upload code scanning results only after merges to main.
C. Enable secret scanning push protection for the repository.
D. Add a pull_request trigger for pull requests targeting main.
Best answer: D
Explanation: To see code scanning findings in pull request context, the analysis must run for pull requests, not only after code reaches the default branch. Adding a pull_request trigger lets reviewers see relevant findings in the PR while AppSec continues to use the repository Security tab for full triage.
Code scanning results can be viewed from two useful contexts: the repository Security tab for the full set of alerts, and the pull request for findings relevant to proposed changes. In this scenario, the workflow runs only on push to main and on a schedule, so developers would not see new findings until after merge or the next scheduled run.
Adding a pull_request trigger causes analysis to run on the PR itself, which associates results with the pull request and surfaces them during review. That supports earlier remediation without changing who performs deeper triage in the Security tab. Scheduled scans are still helpful for ongoing coverage, but they do not replace PR-time visibility.
Topic: Configure and Use Code Scanning with Codeql
A repository uploads third-party SARIF results from two CI jobs for the same commit on main.
Upload 1: tool=Fabrikam SAST, scope=frontend, category not set
Upload 2: tool=Fabrikam SAST, scope=backend, category not set
Result: after Upload 2, only backend findings remain visible
What is the best remediation?
Options:
A. Reuse one SARIF category for both uploads.
B. Assign a distinct SARIF category to each upload.
C. Upload one analysis only from a different branch.
D. Dismiss the missing frontend alerts as duplicates.
Best answer: B
Explanation: When multiple SARIF uploads use the same tool for the same commit, GitHub needs a category to distinguish them. Giving each upload its own category keeps both analyses separate and prevents a later upload from replacing earlier results.
A SARIF category is used by GitHub code scanning to distinguish multiple result sets from the same tool on the same commit or ref. In this scenario, both jobs upload findings from the same analyzer with no category, so GitHub can treat the second upload as the current analysis and the first result set no longer appears. Assigning categories such as frontend and backend tells GitHub to store and display them as separate analyses.
Changing the branch or dismissing alerts does not solve the underlying upload-collision problem.
Topic: Configure and Use Code Scanning with Codeql
An organization uses GHAS code scanning on a monorepo. Application code is in /src and /services; documentation is in /docs. Security policy requires pull request code scanning for changes that affect application or build files before merge into main or release/*, but docs-only changes and pushes to short-lived feature branches do not need full analysis. The current workflow runs on every push and every pull_request. Which change best avoids unnecessary code scanning runs?
Options:
A. Reduce runtime by switching to a smaller CodeQL query suite.
B. Use dependency review as the required pull request check.
C. Scope scans by branch and path: push on main/release/*, PRs only for source or build changes.
D. Remove pull request scanning and rely on scheduled scans.
Best answer: C
Explanation: The issue is unnecessary workflow triggering, not just scan duration. Path filters fit when only certain files should trigger analysis, and branch scoping fits when push scans are only needed on long-lived branches.
To reduce unnecessary code scanning runs, scope the workflow to the changes and branches that actually need analysis. In this scenario, docs-only changes do not require source-code analysis, so paths filters are appropriate for pull requests. Push analysis is only needed on main and release/*, so branch scoping avoids duplicate runs on short-lived feature branches.
Changing query depth only makes each run shorter; it does not stop irrelevant runs. Replacing PR code scanning with scheduled scans or dependency review removes the source-code analysis the policy requires.
Topic: Configure and Use Code Scanning with Codeql
A team uses GitHub Advanced Security on a private repository with a protected main branch. Developers merge through pull requests, but CodeQL code scanning currently runs only after code reaches main and on a nightly schedule. Security findings often require follow-up fixes in later pull requests. The team wants to reduce remediation cost by catching issues before they are merged. Which change best meets this goal?
Options:
A. Run code scanning on pull requests and require its check before merge.
B. Enable secret scanning push protection and leave code scanning post-merge.
C. Keep post-merge scanning and triage alerts during a weekly review.
D. Require dependency review for pull requests and stop code scanning there.
Best answer: A
Explanation: To lower remediation cost, code scanning should analyze changes while they are still in the pull request. Requiring the scan to pass before merge keeps vulnerable code out of the protected branch and lets developers fix findings in the same workflow.
The key concept is running code scanning early enough to influence the merge decision. In GitHub Advanced Security, CodeQL or another code scanning workflow can run on pull request events so findings appear before code reaches main. When that scan is enforced with branch protection or a repository ruleset as a required check, developers must address relevant issues before merging.
This reduces rework because fixes happen in the same pull request, before downstream testing, release preparation, or hotfix work is needed. Scheduled and post-merge scans are still useful for ongoing coverage, but they detect problems only after the vulnerable code has already entered the default branch. Features like dependency review and secret scanning are valuable, but they address different risk types and do not replace pre-merge code scanning for this goal.
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
Read the GitHub Advanced Security GH-500 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.