Try 10 focused GitHub Advanced Security GH-500 questions on GHAS Results, 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 | Describe GHAS Best Practices, Results, and Corrective Measures |
| Blueprint weight | 10% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Describe GHAS Best Practices, Results, and Corrective Measures 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: 10% 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: Describe GHAS Best Practices, Results, and Corrective Measures
An enterprise repository uses a ruleset that requires CodeQL code scanning results on pull requests targeting main. A C++ application can be built only in an isolated on-premises CI environment with a proprietary toolchain, so the normal CodeQL workflow cannot run in GitHub Actions. The team still wants CodeQL findings to appear in GitHub for triage and merge enforcement. What should they implement?
Options:
A. Run CodeQL in GitHub Actions and upload only compiled binaries from external CI for analysis.
B. Run secret scanning after merge and use those alerts instead of CodeQL results.
C. Run dependency review in the pull request and treat it as the equivalent of CodeQL code scanning.
D. Run CodeQL CLI in the external CI, create a database during the build, analyze it there, and upload SARIF to GitHub.
Best answer: D
Explanation: When CodeQL cannot run in GitHub Actions, the supported alternative is CodeQL CLI in the external build environment. The CLI creates the CodeQL database from the real build, performs analysis there, and uploads SARIF so GitHub still receives code scanning results for pull request governance.
CodeQL analysis in GitHub Actions and CodeQL CLI provide the same scanning capability, but they run in different execution environments. An Actions-based workflow performs initialization, build or extraction, analysis, and result upload inside GitHub Actions runners. In this scenario, the required compiler exists only in an isolated external CI system, so the analysis must run there instead.
The correct pattern is:
This preserves GitHub code scanning alerts, triage, and pull request enforcement even though execution happens outside GitHub Actions. Uploading binaries alone is not enough, and dependency review or secret scanning do not replace CodeQL analysis.
Topic: Describe GHAS Best Practices, Results, and Corrective Measures
Your organization uses GitHub Advanced Security with default CodeQL analysis on a private Java repository. A pull request creates this code scanning alert:
Alert: java/sql-injection
Source: HttpServletRequest.getParameter("id")
Sink: Statement.executeQuery(query)
Show paths: request parameter -> string concatenation -> executeQuery
The developers ask whether they must first write a custom CodeQL query because no one on the team writes QL. What is the best security action?
Options:
A. Upload a SARIF report for the same finding to obtain remediation details.
B. Use the alert path to fix the unsafe query construction and rerun CodeQL on the pull request.
C. Write a custom CodeQL query to validate the alert before changing the code.
D. Disable the default CodeQL query suite until the team can write QL.
Best answer: B
Explanation: CodeQL alert interpretation is different from CodeQL query authoring. When a built-in alert already shows the source, sink, and data-flow path, the right next step is to remediate the vulnerable code and confirm the fix by rerunning analysis.
In GitHub code scanning, a standard CodeQL alert is designed to be actionable even if the team does not write custom QL. The alert details already identify the untrusted input, the dangerous sink, and the path showing how data flows between them. In this scenario, that is enough to triage the finding, update the code to a safer pattern such as parameterized database access, and rerun the existing CodeQL analysis on the pull request.
Writing custom CodeQL logic is a separate activity used when you need to create new detections, tune coverage, or model framework-specific behavior. It is not a prerequisite for understanding or fixing a built-in alert. The key takeaway is to use the alert evidence first; write custom queries only when detection needs change.
Topic: Describe GHAS Best Practices, Results, and Corrective Measures
A pull request in a private Java/Kotlin monorepo is blocked by the required check CodeQL / Analyze (java-kotlin). The repository uses a custom Gradle wrapper under services/payments and generates source files before compilation. The default CodeQL workflow template was added without modification.
Exhibit: workflow log
Initialize CodeQL: completed
Autobuild: failed
Message: No build command succeeded
No CodeQL database was finalized
What is the best action?
Options:
A. Scan only the default branch to avoid PR build failures.
B. Rerun the unchanged default CodeQL workflow.
C. Replace autobuild with explicit Gradle and source-generation steps.
D. Remove the required CodeQL check and rely on Dependabot.
Best answer: C
Explanation: The default CodeQL template works only when its automatic build fits the repository. Here, the failed autobuild step plus the custom Gradle and source-generation process show that the workflow must be customized with explicit build commands.
The default CodeQL workflow template is a starting point, not a guarantee that every repository can be built automatically. For compiled languages such as Java and Kotlin, CodeQL must complete a successful build to create the analysis database. In this scenario, autobuild failed because the repository depends on a custom build path and generated sources, so the workflow needs repository-specific build steps.
autobuild with the exact commands that generate sources and run the Gradle build in services/payments.Changing triggers or bypassing the check only hides the problem; it does not produce a usable scan.
autobuild cannot reproduce this repository’s custom build.Topic: Describe GHAS Best Practices, Results, and Corrective Measures
A team uses Jenkins instead of GitHub Actions for a private monorepo. For each pull request, Jenkins runs the following CodeQL CLI steps:
codeql database create
codeql database analyze
output: results.sarif
A repository ruleset blocks merges when GitHub code scanning finds alerts on the pull request. Which action should the team add next?
Options:
A. Enable dependency review for the pull request.
B. Upload the CodeQL database to GitHub code scanning.
C. Upload results.sarif to GitHub code scanning.
D. Commit results.sarif to the pull request branch.
Best answer: C
Explanation: codeql database create prepares data for analysis, but it does not send findings to GitHub. After codeql database analyze produces a SARIF file, that SARIF must be uploaded for GitHub code scanning to show alerts on the pull request.
In a CodeQL CLI workflow, database creation and result upload are different stages. codeql database create builds the CodeQL database from the source and build output so analysis can run. codeql database analyze then reads that database and generates findings, typically as a SARIF file.
GitHub code scanning does not consume the CodeQL database directly. It ingests SARIF results. In this scenario, Jenkins already completed the analysis step, so the missing action is to upload results.sarif to GitHub. That is what makes the findings visible in the pull request and usable by the repository’s secure review workflow.
The key distinction is that database creation prepares analysis, while SARIF upload publishes analysis results.
Topic: Describe GHAS Best Practices, Results, and Corrective Measures
A private GitHub Enterprise Cloud monorepo uses GitHub Advanced Security. The repository now includes a Java API, a TypeScript web app, and Python automation scripts. CodeQL is enabled, and the Java build step already succeeds in the workflow. Security Overview shows code scanning results only for the web app.
strategy:
matrix:
language: [ 'javascript-typescript' ]
The team wants CodeQL coverage for the repository’s application languages without adding unrelated scans. What is the best security action?
Options:
A. Keep the current matrix and rely on Dependabot and secret scanning for the other code
B. Expand matrix.language to include YAML and Markdown used in the repo
C. Update matrix.language to ['java', 'typescript', 'python']
D. Update matrix.language to ['java-kotlin', 'javascript-typescript', 'python']
Best answer: D
Explanation: The CodeQL language matrix should include the supported programming languages actually used in the repository, using CodeQL’s language identifiers. Here, that means adding Java, TypeScript, and Python coverage through java-kotlin, javascript-typescript, and python.
In a mixed-language repository, CodeQL only analyzes the languages listed in strategy.matrix.language. The matrix should map to the repository’s supported source-code languages, not to every file type in the repo.
For this scenario, the needed language entries are:
java-kotlin for the Java APIjavascript-typescript for the TypeScript web apppython for the Python scriptsBecause the Java build already succeeds, the missing code scanning coverage is a matrix configuration issue rather than a build problem. Adding unrelated file types does not improve CodeQL analysis, and other GHAS features like Dependabot or secret scanning do not replace code scanning for source-code vulnerabilities. The key is to align the matrix with the actual application languages present.
java and typescript fails because CodeQL expects its defined language identifiers.Topic: Describe GHAS Best Practices, Results, and Corrective Measures
Several repositories suddenly show different CodeQL alerts on the same commit after the shared security repo changed. The current workflow contains:
- uses: github/codeql-action/init@v4
with:
languages: java
config-file: sec-org/codeql-standards/.github/codeql/java.yml@main
The AppSec team requires one centrally managed configuration, reproducible scan results for audits, and adoption of config changes only after explicit approval. Which remediation is the safest reference pattern?
Options:
A. Pin the external config-file to an approved commit SHA.
B. Keep @main and rely on branch protection in the config repo.
C. Copy the config into each repository and manage it locally.
D. Replace config-file with queries: security-extended.
Best answer: A
Explanation: Use a centrally managed CodeQL configuration, but reference it with an immutable commit SHA. That satisfies governance and auditability because scan behavior stays reproducible until a reviewed workflow change updates the pinned reference.
For CodeQL query or configuration references, the safest pattern for strict governance is a centrally managed file or pack pinned to an immutable version. In this scenario, a commit SHA is the strongest choice because it preserves a single approved source of truth while ensuring scans do not change silently when the shared repository moves forward.
A branch reference such as @main is mutable, so identical application commits can produce different results over time. Copying the file into each repository breaks central governance and increases drift. Swapping to a built-in query suite also changes what is being applied and may omit approved custom settings in the shared configuration.
If the team wants to adopt a newer standard, they should update the pinned SHA through a reviewed pull request.
@main is still a moving reference, so results can change without updating the application repo.security-extended does not preserve the full approved shared configuration and governance model.Topic: Describe GHAS Best Practices, Results, and Corrective Measures
A private monorepo contains /web written in TypeScript and /api written in Python. A repository ruleset blocks merges unless required code scanning checks pass on each pull request. The team wants to keep one CodeQL workflow file.
on:
pull_request:
push:
branches: [main]
jobs:
analyze:
strategy:
matrix:
language: [javascript-typescript]
Which change should the repository administrator make?
Options:
A. Add python as a second CodeQL language entry.
B. Replace CodeQL with dependency review on pull requests.
C. Add a scheduled Python scan on main only.
D. Keep this workflow and require two pull request approvals.
Best answer: A
Explanation: CodeQL analyzes only the languages configured in the workflow. Because this monorepo has both TypeScript and Python and pull requests are gated by code scanning checks, the workflow must include both languages to scan both codebases before merge.
The key concept is the CodeQL language matrix. In a monorepo or other multi-language repository, CodeQL must be configured for each supported language that you want analyzed. Here, the workflow includes only javascript-typescript, so pull request scanning covers the frontend but not the Python API.
To keep a single workflow file and satisfy a ruleset that blocks merges until code scanning checks pass, add python as another language entry in the matrix. That causes CodeQL analysis to run for both codebases during pull request validation. Process controls such as reviews, or adjacent features such as dependency review, are useful but do not expand CodeQL coverage to an unlisted language.
Topic: Describe GHAS Best Practices, Results, and Corrective Measures
A private GitHub Enterprise Cloud monorepo uses GHAS with a CodeQL workflow for a Java service and Python utility scripts. The current workflow initializes CodeQL for both languages but has no build step. The team wants accurate code scanning results with the least extra workflow maintenance, and the Java project supports autobuild. Which workflow adjustment is best?
Options:
A. Use third-party SARIF for Java and keep CodeQL only for Python.
B. Add manual build steps for both Java and Python.
C. Keep a single no-build analysis for both Java and Python.
D. Run Java analysis with autobuild, and analyze Python without a build step.
Best answer: D
Explanation: Compiled languages such as Java usually need a build step for CodeQL to produce accurate analysis, while interpreted languages such as Python usually do not. Because autobuild works for this repo, using it only for Java meets the accuracy goal with minimal maintenance.
The key distinction is that CodeQL often needs build information for compiled languages, but it can usually analyze interpreted languages directly from source files. In this scenario, Java is the compiled language, so leaving the workflow without a build step risks incomplete or inaccurate extraction. Python does not usually require that extra step, so adding one there would not improve coverage and would increase workflow complexity.
autobuild when it works, because it reduces maintenance compared with custom build commands.The closest distractor is building both languages, but that over-configures the workflow beyond what the stated need requires.
Topic: Describe GHAS Best Practices, Results, and Corrective Measures
A private repository already has GitHub Advanced Security and code scanning enabled. A team scans a Java repository in Jenkins because governance requires all builds and CodeQL analysis to stay outside GitHub Actions.
Their current Jenkins job is:
1. Checkout repository
2. Build the application
3. Create a CodeQL database
They want the findings to appear as GitHub code scanning alerts without moving analysis into GitHub. Which workflow adjustment is best?
Options:
A. Compress and upload the CodeQL database directory directly to GitHub code scanning
B. Replace the Jenkins job with CodeQL default setup in GitHub Actions
C. Remove database creation and upload the build artifacts so GitHub can generate alerts
D. Analyze the CodeQL database in Jenkins and upload the generated SARIF results to GitHub
Best answer: D
Explanation: The correct setup keeps database creation and analysis in Jenkins, then sends only the SARIF output to GitHub. A CodeQL database is an intermediate artifact for analysis, while SARIF is the results format GitHub code scanning ingests to create alerts.
In a CodeQL CLI workflow, database create and SARIF upload serve different purposes. Database creation collects the source and build information CodeQL needs to analyze the code, especially for compiled languages such as Java. That database is not itself a code scanning result.
A compliant external workflow is:
This meets the governance requirement because the build and analysis stay in Jenkins, while GitHub receives only the final scan results. Uploading the database itself would not create code scanning alerts.
Topic: Describe GHAS Best Practices, Results, and Corrective Measures
An organization uses GitHub Advanced Security on a private Java repository. The repository has this CodeQL configuration:
queries:
- uses: security-extended
- uses: acme-sec/java-security-pack@v3
A new code scanning alert appears with Tool: CodeQL and Rule ID: java/acme-log-injection. AppSec confirms that this rule is too noisy for this repository, but they want to keep all other results from both security-extended and the custom pack. What is the best action?
Options:
A. Replace CodeQL analysis with third-party SARIF upload.
B. Remove acme-sec/java-security-pack@v3 from the CodeQL configuration.
C. Dismiss the alert and leave the CodeQL configuration unchanged.
D. Exclude java/acme-log-injection by using CodeQL query-filters.
Best answer: D
Explanation: CodeQL results come from individual queries, even when those queries are included through a suite or a pack. Because the alert already identifies the specific rule ID, the most targeted fix is to exclude that query with query-filters and keep the rest of the analysis coverage.
In CodeQL, a code scanning alert is the output of a specific query. A query suite such as security-extended and a query pack such as acme-sec/java-security-pack@v3 are both collections of queries, so removing either one would disable more checks than the scenario allows. Since the noisy result is identified by the rule ID java/acme-log-injection, the precise action is to tune the CodeQL configuration to exclude that query ID.
Dismissing the current alert changes the alert state for that finding, but it does not stop the same query from producing future alerts.
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.