GH-500 - Configure and use supply chain security (18% of the exam) - Section 3.3

Configure Dependency Review for pre-merge checks, including license and compliance validation and the dependency review action.

Configure Dependency Review to block pull requests that introduce vulnerable or licence-incompatible dependencies before they are merged. Use the dependency-review-action in GitHub Actions workflows to enforce pre-merge checks and define which licences are permitted or denied.

Dependency Reviewdependency-review-actionpre-merge checkslicense compliance

Practice question for this objective

Free sampleConfigure and use supply chain securitymedium

An organisation must enforce licence compliance on incoming dependencies. Their counsel has approved permissive licences but forbids any code under the GNU General Public License. The team configures the "dependency-review-action" and asks how to make a pull request that introduces a GPL-licensed dependency fail the pre-merge check while continuing to permit MIT and Apache-2.0 dependencies. Which configuration meets this requirement most directly?

- uses: actions/dependency-review-action@v4
  with:
    # licence policy goes here

ASet "deny-licenses" to the GPL SPDX identifiers, because the action then fails the check when an introduced dependency declares a licence on that deny list while permitting others. Correct
BSet "fail-on-severity: low" so that the action treats a disallowed licence as a low-severity vulnerability and fails the check accordingly.
CAdd "allow-dependencies-licenses" listing only the SPDX identifiers your security team has audited, leaving GPL absent so it is implicitly skipped without failing the run.
DEnable both "deny-licenses" with the GPL identifiers and "allow-licenses" with MIT and Apache-2.0, because the action requires both lists to be present for licence enforcement to activate.

Use the "deny-licenses" input of the dependency review action to block specific SPDX licences while leaving approved licences permitted. Dependency Review can enforce licence policy by either allowing a closed set of licences with "allow-licenses" or blocking specific ones with "deny-licenses", and these two inputs are mutually exclusive. Listing the GPL SPDX identifiers under "deny-licenses" causes the pre-merge check to fail only when an introduced dependency declares one of those licences, leaving permissive licences such as MIT and Apache-2.0 unaffected.

Why A is correct: The "deny-licenses" input takes a list of SPDX licence identifiers, and the action fails the pull request check when an introduced dependency declares any listed licence. Listing the GPL identifiers blocks GPL dependencies while MIT and Apache-2.0 are unaffected, which matches the policy exactly. An "allow-licenses" input is the inverse approach for an allowlist.

Why B is wrong: The "fail-on-severity" input governs vulnerability advisories, not licences, so lowering it does not make a GPL dependency fail on licence grounds. Licence findings are handled by separate allow or deny inputs rather than by the severity threshold.

Why C is wrong: The "allow-dependencies-licenses" input names individual dependencies to exempt from scanning, not an allowed-licence list, so it does not express a licence allowlist. The wording is tempting because it contains "allow" and "licenses", but it solves a different problem and would not fail the GPL dependency.

Why D is wrong: The "allow-licenses" and "deny-licenses" inputs are mutually exclusive and you configure one or the other, not both; supplying both is an invalid configuration. The claim that both are mandatory for enforcement is incorrect, which makes this option fail rather than satisfy the requirement.

See more GH-500 practice questions, answers explained.

Exam traps in Configure and use supply chain security

Answers that look right on this material and are not. Each one is a distractor from a different question in the GH-500 bank for this domain.

Enable Dependabot version updates with a weekly schedule, because the resulting update pull requests will summarise which dependencies changed and whether any are vulnerable.
Why it is wrong: Dependabot version updates open their own pull requests to bump dependencies on a schedule; they do not analyse the dependency changes a developer introduces in an arbitrary pull request. They are tempting because they also concern dependencies, but they do not provide a pre-merge review of someone else's pull request.
Add the unknown-licence dependency to an allow-dependencies-licenses entry so its licence check is skipped while the allow-licenses list still governs every other dependency.
Why it is wrong: Tempting because allow-dependencies-licenses does grant per-dependency licence exceptions, but it requires naming each specific package and does not solve the general problem of any future dependency whose licence cannot be detected being blocked by the allowlist.
Add "comment-summary-in-pr: always" to the action so that the failing result is posted as a pull request comment, which prevents merging until the comment is resolved.
Why it is wrong: The "comment-summary-in-pr" input only controls whether the action posts a summary comment on the pull request; a comment is informational and does not impose any merge restriction. It is tempting because it increases visibility, but visibility alone does not block a merge.

Examworthy is not affiliated with or endorsed by GitHub. Original, blueprint-aligned practice material only.