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

Customize CodeQL query suites and language-specific analysis, tailoring security detection to organizational risk profiles.

Customise CodeQL analysis by selecting from built-in query suites or authoring custom queries packaged as QL packs, targeting language-specific vulnerability patterns. Tailor detection to an organisation's risk profile by enabling or disabling individual queries to reduce false-positive rates.

CodeQL query suitescustom queriesQL packsorganizational risk

Practice question for this objective

Free sampleSecurity operations: best practices, prioritization, and remediationhard

A security team at a fintech wants their organisation's standard CodeQL analysis to run the default security queries for each language plus three of their own internally written queries, while permanently suppressing one noisy built-in query that fires on a framework they have hardened away. They want this defined once and reused across every repository's code scanning workflow. Which artefact should they author and reference to express exactly this set of queries?

# org-standard.qls
- description: Org standard security suite
- import: codeql-suites/javascript-code-scanning.qls
  from: codeql/javascript-queries
- queries: '.'
  from: acme/javascript-custom
- exclude:
    id: js/noisy-framework-rule

AA custom query suite definition in a .qls file that imports the language's code-scanning suite, adds the custom pack's queries, and uses an exclude filter on the unwanted query's id, then reference that .qls through the workflow's queries input. Correct
BA single CodeQL query file that wraps the three custom queries with an import of the built-in suite and a where clause that filters out the noisy rule by its id at evaluation time.
CA repository ruleset that lists the three custom queries as required status checks and adds a rule marking the noisy built-in query as a dismissable alert that is auto-closed across the organisation.
DA code scanning configuration file that lists the three custom queries under a queries key and adds the noisy query's id under a paths-ignore key so that query is filtered out and never analysed.

Author a reusable CodeQL query suite (.qls) that imports built-in suites, adds custom queries, and excludes queries by metadata, then reference it via the queries input. A CodeQL query suite is a declarative instruction file that selects which queries run by importing other suites, adding packs or directories, and applying include or exclude filters against query metadata such as id, precision, or severity. Because it composes existing suites with custom queries and can remove a named built-in query, a .qls captures the team's exact requirement in one reusable artefact that the workflow's queries input points at across all repositories. A single .ql file, a ruleset, or a path filter each operate at the wrong layer and cannot express this query-set composition.

Why A is correct: A .qls suite definition is exactly the reusable instruction set that composes existing suites with custom queries and applies include or exclude filters by metadata such as id, so importing the built-in suite, adding the custom queries, and excluding one id by metadata produces precisely the requested set. Pointing the queries input at the published .qls reuses it across every repository.

Why B is wrong: A .ql query file evaluates one query and cannot import a suite or aggregate other queries, and a where clause filters result rows within that one query rather than selecting which queries run. It confuses authoring a single query with composing a suite of many.

Why C is wrong: Rulesets govern branch and push protections and required status checks, not which CodeQL queries execute during analysis, so they cannot add custom queries or remove a built-in one from the run. It reaches for a governance control that does not shape the analysis query set.

Why D is wrong: The code scanning config file's queries key can add query packs but its paths-ignore key filters source files by path, not queries by id, so it cannot suppress one specific built-in rule. It misuses a path filter to try to drop a query.

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.

Switch the queries input from the default suite to the security-and-quality suite, because the quality queries in that suite add command-line arguments and environment variables as taint sources for the injection queries.
Why it is wrong: Security-and-quality adds maintainability and reliability queries, not new taint sources, so the injection queries still apply the same default threat model and keep ignoring local inputs. It conflates running more queries with changing which inputs those queries treat as untrusted.
Move the curated pack from the packs key to the queries key, because the queries key replaces the default suite while the packs key only ever adds to it.
Why it is wrong: Neither the packs nor the queries key suppresses the default suite on its own; additional packs and queries run alongside the default code-scanning queries unless those defaults are explicitly disabled. It misattributes a disabling effect to the queries key that it does not have.
Add the custom queries to a paths input so CodeQL includes the acme/python-security directory in the database and evaluates its queries during analysis.
Why it is wrong: The paths input narrows which source files are added to the database, not which queries run, so it cannot pull in or execute a published query pack. It confuses controlling analysed source with selecting queries.

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