GH-500 - Configure and use Code Security (14% of the exam) - Section 4.2

Enable code scanning using GitHub Actions or external CI, configure workflow templates, matrix builds, and scan frequency.

Enable code scanning via default setup for automatic configuration or advanced setup for full workflow control using the codeql-action. Configure matrix builds to scan multiple languages in parallel and set scan frequency to run on push, pull request, and scheduled triggers.

default setupadvanced setupcodeql-actionmatrix buildsscan frequency

Practice question for this objective

Free sampleConfigure and use Code Securityhard

An organisation has been running code scanning default setup on a repository for several months. A new requirement means they must run two internal CodeQL query packs and observe a custom build for one language, neither of which default setup supports. A platform engineer commits a CodeQL advanced setup workflow to the repository to gain that control. Before relying on it, they need to know how the existing default setup and the new committed workflow will interact. What is the correct expectation?

ABoth run concurrently, so the repository receives two independent CodeQL analyses per trigger and the engineer must reconcile duplicate alerts manually.
BEnabling advanced setup disables default setup for the repository, so the committed workflow becomes the active code scanning configuration and default setup stops running. Correct
CThe committed workflow is ignored until an administrator first deletes default setup in the repository security settings, otherwise the workflow file has no effect at all.
DDefault setup takes precedence and silently overrides the committed workflow, so the custom query packs never run until default setup is unsupported for the language.

Understand that code scanning default setup and advanced setup are mutually exclusive, and adopting advanced setup disables default setup for the repository. A repository uses either default setup or advanced setup for code scanning, not both; configuring advanced setup with a committed CodeQL workflow switches the repository off default setup so the workflow becomes the active configuration, which is why custom packs and custom builds then take effect.

Why A is wrong: Default setup and advanced setup are mutually exclusive for a repository, so they do not both run and produce duplicate alerts; this misconception leads teams to expect doubled scanning that never occurs.

Why B is correct: Default setup and advanced setup cannot both be active on the same repository; configuring advanced setup turns default setup off, so the committed workflow becomes the sole code scanning configuration and gives the engineer the custom packs and build control they need.

Why C is wrong: Committing and enabling an advanced setup workflow itself moves the repository to advanced setup and disables default setup; there is no separate mandatory delete-first step that renders the committed workflow inert until performed.

Why D is wrong: Default setup does not override a committed advanced setup workflow; the relationship is the reverse, since adopting advanced setup is what disables default setup, so the custom packs would in fact run.

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.

Set the analysis to run only on a weekly schedule rather than on pull requests, so documentation-only pull requests never trigger a run.
Why it is wrong: Moving to a schedule does stop per-pull-request runs, but it also removes pull-request scanning for code changes, leaving new vulnerabilities undetected until the next scheduled scan. It throws away the pre-merge feedback the team wants to keep.
Remove the schedule trigger and add workflow_dispatch so an administrator manually starts the weekly scan during quiet hours each week.
Why it is wrong: Replacing the schedule with manual dispatch removes automatic weekly scanning and relies on someone remembering to run it, which is fragile and contradicts the goal of keeping the scheduled scan running, just at a better time.
pull_request targeting main and push to main only, relying on the fact that CodeQL automatically performs an additional weekly scan for any repository that has advanced setup enabled.
Why it is wrong: CodeQL does not add a hidden weekly scan on top of advanced setup, so omitting a schedule means no scan happens in a week with no pull requests or pushes. The weekly catch-up requirement is left unmet because nothing triggers it.

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