Try 10 focused GitHub Advanced Security GH-500 questions on Dependabot Review, 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 Dependabot and Dependency Review |
| Blueprint weight | 35% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Configure and Use Dependabot and Dependency Review 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: 35% 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 Dependabot and Dependency Review
Your team manages a private GitHub Enterprise Cloud monorepo with GitHub Advanced Security enabled. The current dependabot.yml is:
version: 2
updates:
- package-ecosystem: npm
directory: "/web"
schedule:
interval: daily
- package-ecosystem: pip
directory: "/api"
schedule:
interval: daily
Dependabot now opens many separate minor and patch update pull requests each week. Reviewers want less noise, but the security lead says updates must remain automated and should not be delayed. What is the best security action?
Options:
A. Change the Dependabot schedule from daily to monthly.
B. Add Dependabot groups rules for related minor and patch updates.
C. Disable Dependabot version updates and keep only alerts.
D. Enable dependency review for all pull requests.
Best answer: B
Explanation: Use Dependabot grouping rules to combine related version updates into fewer pull requests. That directly reduces review and notification noise while keeping automated updates, testing, and review in place.
This scenario is about reducing Dependabot review noise without weakening the remediation workflow. The correct fit is to add Dependabot groups rules in dependabot.yml, which let you combine related version updates into fewer pull requests based on criteria such as ecosystem, dependency name patterns, dependency type, or update type. That keeps updates automated and reviewable, but makes the incoming change volume easier to manage.
Changing the schedule to monthly would delay updates, which the stem explicitly forbids. Dependency review is useful for evaluating dependency changes in pull requests, but it does not consolidate Dependabot PRs. Disabling version updates removes an important automated remediation mechanism and leaves teams reacting after alerts instead of receiving fix PRs.
Topic: Configure and Use Dependabot and Dependency Review
A repository administrator reviews this pull request evidence for main:
Dependency review summary
- Added: contoso-parser 3.4.0 -> 1 High vulnerability
- Removed: fabrikam-xml 1.9.1 -> 1 Moderate vulnerability
- Existing on base branch: adatum-core 2.2.0 -> 1 High vulnerability
The team wants pull requests to main blocked only when they introduce new vulnerable dependencies at High or Critical severity. Existing vulnerable packages already on the base branch should not block unrelated pull requests. Which GitHub Advanced Security configuration best meets this requirement?
Options:
A. Require Dependabot security updates before any pull request can merge.
B. Require CodeQL pull request scanning for dependency vulnerabilities.
C. Require a dependency review check on pull requests to main with fail-on-severity: high.
D. Require SBOM export and dependency graph review after merges to main.
Best answer: C
Explanation: Use dependency review as a required pull request check. It evaluates the dependency changes in the PR, so an added High-vulnerability package blocks merge while a removed vulnerable package or an existing vulnerable base-branch package does not.
Dependency review is the GHAS control designed for dependency changes in pull requests. It compares added, removed, and updated dependencies in the PR against advisory data, which lets it identify whether the PR is introducing a vulnerable package rather than just exposing a vulnerability that already exists on the base branch.
Requiring the dependency review result on pull requests to main with a High severity threshold enforces the stated policy before merge. Inventory and remediation features are useful, but they do not provide the same PR-specific introduced-dependency gate.
Topic: Configure and Use Dependabot and Dependency Review
A private GitHub Enterprise Cloud repository already uses Dependabot alerts, Dependabot security updates, and a dependabot.yml file that groups npm updates weekly. AppSec now wants every pull request that changes dependencies to be evaluated before merge and blocked if it introduces known vulnerable packages. What is the best security action?
Options:
A. Run dependency review on pull requests and require its check with a repository ruleset.
B. Change dependabot.yml to group all dependency updates into fewer pull requests.
C. Change dependabot.yml to check for dependency updates every day.
D. Increase the Dependabot pull request limit for version updates.
Best answer: A
Explanation: The requirement is to evaluate dependency changes in each pull request and block merge when policy is violated. That is dependency review enforcement, not Dependabot update configuration.
Dependabot configuration in dependabot.yml controls how automated update pull requests are created, such as schedule, grouping, and pull request limits. Those settings help manage remediation workflow, but they do not enforce a merge gate on all pull requests.
Dependency review is the control designed to inspect dependency changes between the base and head of a pull request. When combined with a required status check through a repository ruleset or branch protection, it can stop a pull request from merging until risky dependency changes are reviewed or corrected.
The key distinction is that update configuration manages how fixes arrive, while dependency review policy enforcement governs whether risky dependency changes can enter the default branch.
Topic: Configure and Use Dependabot and Dependency Review
Your organization uses GitHub Advanced Security on private repositories in GitHub Enterprise Cloud. The AppSec team wants GitHub to raise vulnerable dependency alerts when a repository’s committed manifests or lockfiles reference a package version listed as vulnerable in the GitHub Advisory Database. They want continuous repository alerting, but not automated remediation pull requests. Which configuration best meets this requirement?
Options:
A. Schedule SBOM export from the repository
B. Require dependency review on pull requests
C. Enable CodeQL default code scanning
D. Enable dependency graph and Dependabot alerts
Best answer: D
Explanation: Vulnerable dependency alerts are created by matching the repository’s dependency graph against advisories in the GitHub Advisory Database. Enabling Dependabot alerts provides ongoing alerting for affected package versions without turning on automated update pull requests.
The GitHub Advisory Database is the advisory source that lists known vulnerable package versions and related remediation information. To turn that data into repository alerts, GitHub also needs the repository’s dependency inventory, which comes from the dependency graph built from manifests and lockfiles. When Dependabot alerts is enabled, GitHub compares the dependency graph to advisory data and opens vulnerable dependency alerts for matches.
Dependency review and SBOM generation are useful for change analysis and inventory, but they do not replace the advisory-to-dependency matching used for ongoing vulnerable dependency alerts.
Topic: Configure and Use Dependabot and Dependency Review
A security manager reviews the organization’s Security Overview and sees this for a private repository. GHAS is already available for the organization.
| Repository | Visibility | Dependency graph | Dependabot alerts |
|---|---|---|---|
payments-api | Private | Disabled | None |
The team knows payments-api includes a vulnerable direct dependency and wants GitHub to generate vulnerability alerts for this repository and future private repositories in the organization. What is the best action?
Options:
A. Require dependency review on pull requests.
B. Add a dependabot.yml file to schedule update pull requests.
C. Enable CodeQL code scanning for the repository.
D. Enable dependency graph and Dependabot alerts for the organization’s private repositories.
Best answer: D
Explanation: Dependabot alerts for vulnerable packages depend on the dependency graph and the Dependabot alerts feature being enabled. Because the goal includes this repository and future private repositories, organization-level enablement is the best fit.
Dependabot alerts surface known vulnerable dependencies by comparing a repository’s dependency graph to advisories in the GitHub Advisory Database. If the dependency graph is disabled, GitHub cannot inventory the repository’s packages, so alerts will not appear. In this scenario, the correct remediation is to enable dependency graph and Dependabot alerts at the organization level for private repositories so the current repo is covered and future private repos can also inherit that protection.
A dependabot.yml file is mainly for configuring update behavior, and dependency review helps evaluate dependency changes in pull requests. Code scanning with CodeQL is a different GHAS feature that finds code issues rather than dependency vulnerabilities.
The key takeaway is that vulnerable dependency alerting starts with dependency graph plus Dependabot alerts, not with PR workflows or code scanning.
dependabot.yml only configures update behavior, but it does not by itself enable baseline Dependabot alerts for private repositories.Topic: Configure and Use Dependabot and Dependency Review
An organization-owned private repository already has the dependency graph enabled, but Dependabot alerts are disabled. A team lead with the Maintain role must enable Dependabot alerts for only this repository. Security wants the smallest permission increase possible and does not want to grant organization-wide rights.
Which permission change should be made?
Options:
A. Grant the Organization owner role
B. Grant Write access on the repository
C. Keep the Maintain role on the repository
D. Grant Admin access on the repository
Best answer: D
Explanation: Dependabot alerts are enabled through repository security settings, which require repository admin permissions. Because the change is needed for only one repository, granting Admin on that repository meets the need with less privilege than an organization-wide owner role.
The key concept is matching the permission scope to the setting being changed. Enabling Dependabot alerts is a repository-level administrative action, so a user needs Admin access on that repository to turn the feature on.
In this scenario, the team lead already has Maintain, but that role is not sufficient for enabling Dependabot alerts. Write is even more limited. An Organization owner could enable the setting, but that would exceed the stated least-privilege requirement because it grants broad organization-wide control instead of access scoped to one repository.
When the goal is to enable Dependabot alerts for a single repository, repository Admin is the best fit.
Maintain access fails because that role does not provide the repository administrative control needed to enable Dependabot alerts.Write access fails because it is more limited than Maintain and still cannot change this security setting.Organization owner role would work functionally, but it violates the least-privilege requirement by expanding authority beyond one repository.Topic: Configure and Use Dependabot and Dependency Review
A private Node.js repository shows this GHAS alert:
Dependabot alert
Package: acme-json 1.8.0
Manifest: package-lock.json
Linked advisory: yes
The team cannot find acme-json in package.json and wants to know whether it is transitive and what version should be targeted for remediation. What is the best next action?
Options:
A. Use the dependency graph to trace the package path, then review the linked advisory for fixed versions.
B. Generate an SBOM and use it as the only source for remediation guidance.
C. Dismiss the alert because packages absent from package.json are not used by the application.
D. Run code scanning to find imports of acme-json, then use that result to decide the fix version.
Best answer: A
Explanation: Dependabot alerts come from dependency relationship data plus advisory data. Here, the package appearing in package-lock.json but not package.json suggests a transitive dependency, so the right move is to trace it in the dependency graph and use the linked advisory to confirm the patched version range.
The key concept is that GitHub maps vulnerable package findings by combining the repository’s dependency graph with advisory information. If a package is not listed directly in package.json but appears in the lockfile, it is commonly a transitive dependency. The dependency graph helps you identify which direct dependency brings that package into the project. The linked advisory then tells you the vulnerable range, severity, and the version or range that contains the fix.
That combination supports the next remediation step:
The closest distractor is the SBOM choice: an SBOM is useful for inventory, but it does not replace dependency graph relationship tracing or advisory-based fix guidance.
Topic: Configure and Use Dependabot and Dependency Review
A private repository uses a ruleset that requires the dependency-review job to pass before any pull request can merge into main. The security policy says:
The current workflow contains:
jobs:
dependency-review:
runs-on: ubuntu-latest
steps:
- uses: actions/dependency-review-action@v4
Which change best enforces this policy?
Options:
A. Add with: fail-on-severity: high to the dependency review step.
B. Enable Dependabot security updates and stop requiring the dependency-review job.
C. Replace the job with a CodeQL scan that fails on high-severity code scanning alerts.
D. Leave the workflow unchanged and rely on reviewers to judge dependency severity manually.
Best answer: A
Explanation: Dependency Review is the pull request control for vulnerable dependency changes. Setting fail-on-severity: high aligns the required check with the stated merge-risk policy by blocking only high and critical vulnerabilities.
To customize merge risk in a Dependency Review workflow, set the severity threshold on actions/dependency-review-action. Because the repository ruleset already requires the dependency-review job to pass, that threshold becomes the enforcement point for pull requests.
- uses: actions/dependency-review-action@v4
with:
fail-on-severity: high
This configuration keeps low and moderate findings visible in the PR experience without failing the check, while high and critical vulnerable dependency changes block merge. Code scanning and CodeQL are for analyzing code issues, not dependency-introduced package risk in PRs. Dependabot security updates help remediate vulnerable dependencies, but they do not replace a severity-based PR gate.
Topic: Configure and Use Dependabot and Dependency Review
A pull request is under security review because an external scanner reports that the build now uses vulnerable package oldlib@1.2.3. GitHub shows no new dependency in the dependency graph and no dependency review findings.
build.sh
+ npm install oldlib@1.2.3
package.json and package-lock.json are unchanged. What is the best action to make GitHub track this dependency in the dependency graph?
Options:
A. Re-run CodeQL analysis for the pull request.
B. Enable secret scanning for the repository.
C. Add oldlib to package.json and commit the updated lock file.
D. Upload the CI log as a SARIF report.
Best answer: C
Explanation: GitHub’s dependency graph is based on dependencies it detects from supported manifest and lock files. Because the package is introduced only through a script line and not declared in package.json or package-lock.json, GitHub does not add it to the graph.
The dependency graph is GitHub’s view of a repository’s dependencies as detected from supported manifest and lock files. In this scenario, oldlib@1.2.3 is introduced only through npm install inside a shell script. Since package.json and package-lock.json do not change, GitHub has no manifest-based dependency record to add to the dependency graph, so dependency review also has nothing new to compare.
If the package is truly part of the project, it should be declared in package.json and the lock file should be updated and committed. That gives GitHub the source data it uses for dependency tracking. CodeQL and SARIF are for code scanning, and secret scanning is for exposed credentials, so they do not solve this dependency graph gap.
Topic: Configure and Use Dependabot and Dependency Review
A private GitHub Enterprise Cloud repository uses pull requests to merge into main. The security team wants every PR that changes manifest or lock files to be evaluated before merge so reviewers can see newly introduced vulnerable dependencies and the merge can be blocked when policy fails. Dependabot alerts are already enabled.
What is the best security action?
Options:
A. Add a Dependency Review workflow on pull_request and require its check for main.
B. Upload SARIF results from a third-party scanner for each pull request.
C. Enable Dependabot security updates to automatically remediate vulnerable packages.
D. Enable secret scanning push protection for the repository.
Best answer: A
Explanation: The requirement is to inspect dependency changes during the pull request process and stop merges when dependency risk violates policy. A Dependency Review workflow triggered on pull_request, combined with a required status check or ruleset, is the GHAS control built for that pre-merge dependency gate.
Dependency Review is the GitHub feature that compares dependency changes in a pull request and surfaces newly introduced vulnerable dependencies before code is merged. In this scenario, the key need is pre-merge enforcement, not just post-merge alerting or automated remediation. The best design is a workflow that runs on pull_request for manifest or lockfile changes and then make that check required on main through branch protection or a repository ruleset.
This gives the team two controls:
Dependabot alerts help identify vulnerable dependencies already present, and Dependabot security updates help propose fixes, but neither is the primary pre-merge review control for dependency changes in a PR.
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.