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

Define, prioritize, and enforce severity and remediation rulesets, and run campaign-based remediation and bulk alert management.

Define and enforce security rulesets with severity thresholds to gate deployments on unresolved findings, and run security campaigns to track remediation progress across many repositories. Use bulk alert management and auto-dismiss rules to maintain a manageable and actionable alert backlog.

security rulesetsseveritysecurity campaignsbulk alert managementauto-dismiss

Practice question for this objective

Free sampleSecurity operations: best practices, prioritization, and remediationmedium

A security manager must guarantee that, across many repositories in an organisation, no pull request can be merged into the default branch while code scanning has an open alert above a chosen severity, and the rule must apply to repositories created in future without an administrator configuring each one. Which control enforces this consistently across the suite of repositories?

AA per-repository branch protection rule on the default branch that requires the code scanning status check to pass, configured by each repository administrator.
BAn enforced security configuration applied to the repositories, which enables code scanning and therefore blocks merges whenever an alert above the chosen severity is open.
CA required workflow that runs the code scanning analysis on every pull request, so the merge is blocked until the workflow reports no alerts above the threshold.
DAn organisation-level ruleset targeting the default branch that adds a code scanning merge protection rule with the required alert severity threshold, applied across the targeted repositories. Correct

Use an organisation-level ruleset with code scanning merge protection to enforce a severity-based merge gate across many repositories, including future ones. Organisation-level rulesets target branches across repositories by pattern and can carry a code scanning merge protection rule that blocks merges while alerts at or above a chosen severity remain open, and because they are defined centrally they cover newly created matching repositories automatically. Branch protection is per repository, security configurations govern feature enablement rather than merge gating, and a required workflow forces a scan to run without enforcing the open-alert severity threshold.

Why A is wrong: Branch protection can require a code scanning check, so this looks like the right gate, but it is configured per repository by administrators and does not apply automatically to future repositories, allowing drift and gaps. It cannot give the organisation-wide, automatically applied guarantee the security manager needs.

Why B is wrong: A security configuration is the right tool for enabling and locking code scanning across repositories, which makes it tempting here, but it governs feature enablement rather than merge gating and does not itself block pull requests on alert severity. The merge-blocking behaviour comes from a ruleset or branch protection, not from the configuration.

Why C is wrong: A required workflow can force an analysis to run, which is why this seems to gate merges, but completing the scan is not the same as blocking on open alert severity, and a passing workflow run can still coexist with open alerts. The severity-based merge gate is the code scanning merge protection rule, configured through a ruleset.

Why D is correct: Organisation-level rulesets can target the default branch across many repositories at once and include a code scanning merge protection rule with a configurable alert severity, blocking merges while qualifying alerts are open. Because the ruleset is defined once at the organisation and matches repositories by pattern, it covers repositories created later without per-repository setup.

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.

The alert's display level (error, warning, or note), because the merge protection threshold maps error-level alerts to high and warning-level alerts to medium for gating purposes.
Why it is wrong: The error, warning, and note level describes how prominently an alert is shown, not the security severity the gate evaluates, and there is no fixed mapping from level to a security-severity band. Conflating the two leads teams to assume any error-level alert blocks, which is not how the threshold reads severity.
Bulk-dismiss the targeted alerts with the reason "won't fix" and rely on the dismissal audit log to record which repositories still need attention before the deadline.
Why it is wrong: Dismissing alerts closes them rather than tracking remediation, so the work appears done when nothing has actually been fixed. It is tempting because bulk dismissal is a real scale action, but it removes the alerts from the active queue instead of giving developers a deadline-driven task list, which defeats the purpose.
Direct assignment automatically closes each alert once it is assigned, whereas a campaign keeps the alerts open, so only the campaign is suitable when the alerts must remain open until remediated.
Why it is wrong: Assigning an alert to an engineer does not close it; assignment is an ownership annotation, not a resolution. The claim that assignment auto-closes alerts is wrong, and it misrepresents the only meaningful difference between the two approaches.

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