GH-500 · Domain 3: Configure and use supply chain security (formerly Dependabot/Dependency Review) · 18% of the exam
Task 3.3: Secure dependencies during development
Dependency review and its action before merge, license checks, and dependabot.yml rules for grouping, ignoring and pacing updates.
Study it
Dependency review, license checks and dependabot.yml update rules
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the GitHub documentation page that proves it.
Question 1 · choose 1
A team wants its dependency review workflow to accept only MIT, BSD-3-Clause and Apache-2.0 licenses, and also to explicitly block GPL-3.0. The workflow sets both allow-licenses and deny-licenses. What happens?
AThe action raises an error: the two options are mutually exclusive
BThe deny list wins, and every other license is allowed
CThe allow list wins silently, and the deny list is ignored without any warning in the log
DBoth lists apply, and GPL-3.0 is reported twice
Show the answer and why
AThe action raises an error: the two options are mutually exclusive
Correct
Only one of allow-licenses and deny-licenses can be set.
BThe deny list wins, and every other license is allowed
Incorrect
Both lists can't be combined at all.
CThe allow list wins silently, and the deny list is ignored without any warning in the log
Incorrect
The action errors instead of ignoring an option.
DBoth lists apply, and GPL-3.0 is reported twice
Incorrect
The action doesn't accept both lists.
allow-licenses fails pull requests that introduce dependencies whose licenses aren't in the list, and deny-licenses blocks the listed licenses. They are mutually exclusive, and the action raises an error if both are provided. An allow list of MIT, BSD-3-Clause and Apache-2.0 already blocks GPL-3.0, and the action's README now marks deny-licenses as deprecated.
A team wants its dependency review check to fail only for vulnerabilities rated high or critical, and only when they are in runtime dependencies, not in development tooling. Which two settings achieve this? (Choose TWO.)
Afail-on-severity: critical
Ballow-ghsas listing every development-only advisory
Cfail-on-severity: high
Ddeny-licenses: GPL-3.0
Efail-on-scopes: runtime
Show the answer and why
Afail-on-severity: critical
Incorrect
That would let high-severity vulnerabilities through.
Ballow-ghsas listing every development-only advisory
Incorrect
That skips advisories by ID; it isn't a scope filter and needs constant upkeep.
Cfail-on-severity: high
Correct
The action fails on the given severity or higher.
Ddeny-licenses: GPL-3.0
Incorrect
License lists don't filter vulnerabilities.
Efail-on-scopes: runtime
Correct
The action then fails only for vulnerabilities in runtime dependencies.
fail-on-severity defines a threshold: the action fails on pull requests that introduce vulnerabilities of that severity or higher (critical, high, moderate or low). fail-on-scopes lists the scopes (development, runtime, unknown) in which a vulnerability makes the action fail; runtime is also its default. allow-ghsas skips specific advisories by ID.
How do you enable Dependabot version updates for a repository?
ABy enabling Dependabot alerts for the repository
BBy checking in a dependabot.yml file
CBy enabling secret scanning
DBy exporting an SBOM
Show the answer and why
ABy enabling Dependabot alerts for the repository
Incorrect
Alerts don't turn on version updates.
BBy checking in a dependabot.yml file
Correct
Version updates are enabled by that file.
CBy enabling secret scanning
Incorrect
That is unrelated.
DBy exporting an SBOM
Incorrect
That is unrelated.
You enable Dependabot version updates by checking a dependabot.yml configuration file into your repository, which says which ecosystems and directories to monitor and how often.
Without extra configuration, when does the dependency review action fail its check?
AWhen it finds any vulnerable package
BOnly for critical vulnerabilities in runtime dependencies
CNever; it only comments
DOnly when licenses change
Show the answer and why
AWhen it finds any vulnerable package
Correct
That is the default behavior.
BOnly for critical vulnerabilities in runtime dependencies
Incorrect
By default any vulnerable package fails it.
CNever; it only comments
Incorrect
It fails by default on vulnerable packages.
DOnly when licenses change
Incorrect
Without an allow or deny list, license changes don't fail the check.
By default, the dependency review action check fails if it discovers any vulnerable packages. A failed check blocks merging when the check is required.
Which comment stops Dependabot opening pull requests for a dependency's current major version?
A@dependabot rebase
B@dependabot recreate
C@dependabot ignore this major version
D@dependabot unignore *
Show the answer and why
A@dependabot rebase
Incorrect
That rebases the pull request.
B@dependabot recreate
Incorrect
That recreates the pull request.
C@dependabot ignore this major version
Correct
That closes the pull request and ignores the major version.
D@dependabot unignore *
Incorrect
That clears ignore conditions in a group.
@dependabot ignore this major version closes the pull request and prevents Dependabot from creating more pull requests for this major version, unless you reopen the pull request or upgrade to it yourself.