GH-500 - Configure and use Code Security (14% of the exam) - 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.

Exam traps in Configure and use Code Security

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.

Change build-mode to none in the init step and add your own dotnet restore and build commands as a step before the analyse step, since none tells CodeQL to watch whichever build you provide.
Why it is wrong: The none build mode means CodeQL analyses without observing any build at all, which is intended for languages that do not need compilation and would ignore the commands you run. For C# that needs a real build, none produces an incomplete or empty database rather than tracing your compilation.
Add a paths-ignore filter in the workflow's pull_request trigger listing src/generated so the action skips runs that touch generated files.
Why it is wrong: Tempting because paths-ignore does reduce noise, but at the trigger level it only skips whole workflow runs based on which files changed; it does not scope what CodeQL extracts, so a run on app code still analyses generated files.
Switch the queries input from security-extended to security-and-quality, because that suite is tuned to run faster than security-extended while preserving the security findings.
Why it is wrong: The security-and-quality suite is a superset of security-extended that also adds maintainability and reliability queries, so it runs more queries and is slower, not faster. The name suggests a leaner option but it actually broadens the analysis.

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