GH-500 - Configure and use Code Security - Section 4.4

Apply advanced configuration and customization, and troubleshoot scan failures and performance issues.

Apply advanced CodeQL configuration options including query suite selection and build mode to optimise scan performance for large codebases. Troubleshoot scan failures by interpreting workflow logs, understanding extraction errors, and resolving build-mode conflicts.

CodeQL query suitesscan performancetroubleshootingbuild mode

Practice question for this objective

Free sampleConfigure and use Code Securityhard

A team adds CodeQL code scanning to a Java service that is built with a non-standard Gradle wrapper and several custom tasks. With the autobuild approach, database creation fails because CodeQL cannot infer the correct build sequence, and the workflow logs show it invoking the wrong Gradle task. The team wants CodeQL to observe their exact build so that all compiled classes are traced into the database. Which configuration change best resolves the failing database creation?

  • ASet build-mode to none for java, so CodeQL builds the database directly from the source and no longer depends on the Gradle build succeeding.
  • BKeep autobuild but add a second init step that re-runs autobuild with increased verbosity, so the correct Gradle task is detected on the retry.
  • CMove the analysis to the default setup in the repository security settings, because default setup automatically handles custom Gradle builds without any workflow file.
  • DReplace autobuild with manual build-mode and add explicit build steps that invoke the project's own Gradle wrapper and tasks between the init and analyze steps. Correct
Use manual build mode with explicit build steps when CodeQL autobuild cannot infer a non-standard compiled-language build, so the real compilation is traced. For compiled languages CodeQL must observe compilation to populate the database. Autobuild applies heuristics that work for conventional projects but fail when the build uses custom tasks, so the supported remedy is manual build mode: the team places their own build commands between the init and analyze steps, letting CodeQL trace the exact compilation and capture every class. Build-mode none, retrying autobuild, or switching to default setup either lower fidelity or repeat the same failed inference.

Why A is wrong: Build-mode none avoids invoking the build, which removes the immediate failure, but for a project with custom Gradle tasks it can miss generated or conditionally compiled sources and changes analysis fidelity. It sidesteps the build rather than letting CodeQL observe the team's exact compilation.

Why B is wrong: Re-running autobuild does not teach it the project's custom task graph, so it will keep selecting the wrong task; verbosity only changes logging, not detection. Repeating a heuristic that has already guessed wrong will not make it guess right.

Why C is wrong: Default setup relies on the same automatic build inference and is less configurable than an advanced workflow, so it would not reliably accommodate a non-standard Gradle build with custom tasks. It removes the very control the team needs to specify their build.

Why D is correct: Manual build mode lets the team run their exact build commands between init and analyze so CodeQL traces the real compilation, which is the supported fix when autobuild cannot infer a non-standard build. Tracing the genuine build ensures every compiled class enters the database.

See more GH-500 practice questions, answers explained.

More in this domain

Back to all Configure and use Code Security objectives, or the GH-500 cert hub.

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