GH-500 domain - 18% of the exam

Configure and use supply chain security

Configure and use supply chain security is 18% of the GitHub Advanced Security (GH-500) (GH-500) exam. These are the objectives it covers, each with practice questions and worked explanations.

Objectives in this domain

Sample question from this domain

Free sampleConfigure and use supply chain securitymedium

A security engineer enables the dependency graph on a private repository and expects to see the project's npm packages listed. The repository checks in package.json but the team has chosen never to commit package-lock.json. They observe that the dependency graph shows the direct dependencies declared in the manifest but does not resolve the full set of transitive dependencies and pinned versions. Which explanation best accounts for what the dependency graph can and cannot show here?

  • AThe dependency graph only ever reads lock files and ignores manifests entirely, so a repository with no committed lock file produces an empty dependency graph regardless of any manifest present.
  • BThe dependency graph parses the manifest to list declared direct dependencies, but without a committed lock file it cannot determine the exact resolved versions of the transitive dependency tree. Correct
  • CThe dependency graph requires the repository to run a build so it can capture dependencies at compile time, and the missing tree is simply because no Actions build has executed yet.
  • DThe dependency graph is disabled for private repositories, so the partial listing must be coming from a cached public mirror rather than from the repository itself.
Recognise that the dependency graph parses manifests for direct dependencies but needs a committed lock file to resolve the full transitive tree and pinned versions. GitHub builds the dependency graph by statically parsing supported manifest and lock files in the repository. A manifest declares direct dependencies and version ranges, whereas the lock file records the fully resolved, pinned transitive tree. With no committed lock file the graph can still show declared direct dependencies but cannot enumerate the exact versions of the transitive dependencies that a lock file would have captured.

Why A is wrong: This overstates the limitation. The graph does parse supported manifests such as package.json, which is why the direct dependencies are visible at all, so the claim that the graph is empty without a lock file contradicts the observed result.

Why B is correct: The dependency graph reads supported manifest and lock files in the repository. A manifest such as package.json declares direct dependencies and version ranges, but the resolved transitive tree and pinned versions live in the lock file, so omitting package-lock.json leaves the graph unable to enumerate the full pinned dependency set.

Why C is wrong: The dependency graph is built by statically reading manifest and lock files in the repository, not by executing a build. Tying resolution to a compile-time capture confuses the graph with runtime instrumentation that it does not perform.

Why D is wrong: The dependency graph can be enabled on private repositories, and the engineer explicitly enabled it, so attributing the listing to a public mirror is wrong. The partial view is a lock-file question, not a private-repository restriction.

Other domains in this exam

See also the GH-500 cert hub, the study guide, and the cheat sheet.

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