GH-500 - Security operations: best practices, prioritization, and remediation (18% of the exam) - Section 5.5

Strengthen preventive security through push protection, dependency scanning, and pre-merge analysis to prevent vulnerabilities early.

Strengthen preventive security by combining push protection for secrets, Dependabot dependency scanning, and pre-merge code analysis to catch vulnerabilities before they enter the default branch. Apply a prevention-first, shift-left approach to reduce remediation cost compared to fixing issues discovered after deployment.

shift leftpush protectionpre-merge analysisprevention-first

Practice question for this objective

Free sampleSecurity operations: best practices, prioritization, and remediationmedium

A new team is standing up GitHub Advanced Security on a private repository and wants their preventive controls to work on day one. They enable push protection and add a Dependency Review workflow on pull requests, but the dependency review job fails with an error that a required feature is not enabled, while push protection works as expected. Applying the prevention-first principle, what is the prerequisite they have missed, and why does it matter for the pre-merge dependency gate specifically?

AThey have not granted the workflow contents: write permission, which Dependency Review needs in order to store the computed dependency diff back into the repository during the run.
BThey have not enabled CodeQL code scanning, whose SARIF output Dependency Review consumes to determine which introduced dependencies are vulnerable.
CThey have not enabled the dependency graph, which is on by default for public repositories but must be turned on for private ones, and Dependency Review needs it to diff the base and head dependencies. Correct
DThey have not committed a lockfile to the default branch, without which Dependency Review has no resolved dependency set to compare across the pull request.

Recognise that Dependency Review depends on the dependency graph, which must be enabled explicitly on private repositories before the pre-merge gate works. The pre-merge dependency gate works by diffing the dependency graph between a pull request's base and head, so the graph is its hard prerequisite. The dependency graph is on by default for public repositories but must be enabled deliberately for private ones, which is why a private repository with it disabled returns a feature-not-enabled error that is resolved by enabling the dependency graph rather than by changing permissions, code scanning, or lockfiles.

Why A is wrong: Dependency Review only requires read access to repository contents to compare manifests and does not write a diff back to the repository, so escalating to write permission does not fix a disabled feature. The permissions framing is plausible but targets the wrong prerequisite.

Why B is wrong: Dependency Review and code scanning are independent features; Dependency Review derives vulnerability information from advisories applied to the dependency graph, not from CodeQL SARIF. Enabling code scanning would leave the dependency graph still disabled and the same error in place.

Why C is correct: Dependency Review reads the dependency graph to compute the difference between the base and head of a pull request, and the dependency graph is enabled by default only for public repositories, so a private repository must have it switched on. With it disabled the action cannot read dependency data and reports a feature-not-enabled error, which is exactly the failure described.

Why D is wrong: A missing lockfile can reduce the precision of resolved versions but it does not raise a feature-not-enabled error, and Dependency Review can still operate on manifests. It explains a milder, different symptom than the explicit prerequisite failure in the scenario.

See more GH-500 practice questions, answers explained.

Exam traps in Security operations: best practices, prioritization, and remediation

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.

Increase the secret scanning alert notification frequency so maintainers are paged the moment a credential lands, allowing them to rewrite history before anyone clones the branch.
Why it is wrong: Faster notifications still react after the secret has already been written to history, so the credential has briefly existed in the repository and must be revoked and rewritten. It is tempting because it shortens the response window, but it remains a detection control rather than a preventive one.
Dependency Review acts earliest at the moment the dependency is added, while push protection and CodeQL both act later at the pull request review stage when the checks run.
Why it is wrong: This misorders the controls: Dependency Review runs as a pull request check rather than at the developer's keystroke, and push protection acts before any pull request exists, so placing Dependency Review earliest is wrong.
Change the cron expression so the scheduled scan runs every hour instead of nightly, shrinking the gap between a merge and the alert appearing.
Why it is wrong: Running the schedule more often still analyses only after code has merged to the default branch, so the alert continues to arrive post-merge, merely sooner. It reduces the delay but does not move analysis into the review window, which is the shift-left goal.

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