Medium — GH-500 Practice Quiz

Question 1

Your security team wants to automatically dismiss Dependabot alerts for a category of vulnerabilities that leadership has formally accepted as low-risk in your environment. Regulators later require proof that each dismissal was intentional, attributable, and reviewable. Which combination of practices BEST satisfies both the operational goal and the auditability requirement?

Accepted Answer

Configure Dependabot auto-triage rules to dismiss the matching alerts, and rely on the rule definition plus the auto-generated audit log entries as the documented, attributable record of each dismissal.

Answer

Manually dismiss each alert one at a time with a free-text comment, because only human action produces a defensible audit trail.

Answer

Delete the affected dependencies from the dependency graph so the alerts no longer appear, eliminating the need for dismissal records.

Answer

Disable Dependabot alerts entirely for the repositories in scope so the low-risk category is never reported.

Question 2

A security manager at a fintech company is closing out a large backlog of Code Scanning alerts across 40 repositories. Several hundred alerts share the same CWE and originate from a deprecated internal library that is being fully removed next sprint. Leadership requires that any mass dismissal leave a clear, auditable record explaining the business justification, and that the alerts do NOT silently reappear if the deprecated code is temporarily reintroduced during the migration. Which approach best satisfies both the scale and the governance requirements?

Accepted Answer

Use bulk alert management to dismiss the matching alerts with the reason 'Won't fix' and include a documented dismissal comment describing the deprecation and migration plan.

Answer

Delete the affected repositories' CodeQL workflow files so the analysis stops running and the alerts disappear from Security Overview.

Answer

Add the deprecated library's file paths to a paths-ignore filter in each workflow so the alerts are excluded from future scans without any dismissal record.

Answer

Bulk dismiss the alerts with the reason 'False positive' since the code is scheduled for removal and therefore no longer represents a real risk.

Question 3

A security lead at a large organization wants to launch a security campaign to drive down the most impactful code scanning alerts across dozens of repositories. Leadership has directed the team to focus first on alerts that are both easiest to attribute to a responsible engineer and most likely to be actively dangerous in production. Which approach best aligns campaign scope with these priorities?

Accepted Answer

Create a campaign filtered to critical- and high-severity alerts that appear on the default branch and reside in code with recent commit activity, so ownership can be traced and exposure is real

Answer

Create a campaign that includes every open alert regardless of severity or branch, so no potential issue is missed during the remediation push

Answer

Create a campaign filtered only to alerts on feature branches, since those represent in-progress work that developers are already focused on

Answer

Create a campaign scoped to low- and medium-severity alerts first, because they are more numerous and clearing them shows faster backlog reduction

Question 4

A security manager at a large organization launches a security campaign targeting 340 high-severity SQL injection alerts spread across 60 repositories. She wants to hold each development team accountable by giving them a shared context, a due date, and direct visibility into which alerts they own, so progress can be tracked centrally in Security Overview. Which combination of campaign configuration steps best achieves this goal?

Accepted Answer

Create the campaign with a due date and a description providing remediation guidance, then assign alerts to specific team members or teams so ownership and progress are tracked in Security Overview.

Answer

Bulk-dismiss all 340 alerts with the reason 'won't fix' and open a tracking issue in each of the 60 repositories to coordinate the work manually.

Answer

Create a cross-repository ruleset that blocks all merges to default branches until every SQL injection alert is resolved, without setting a due date.

Answer

Export the alerts to a SARIF file, distribute it to team leads over email, and ask each team to self-report completion percentages weekly.

Question 5

You are configuring the default CodeQL workflow for a repository that receives frequent pull requests to the `main` branch. The security team wants alerts raised as early as possible on incoming changes, but they are also concerned about newly disclosed CodeQL query updates surfacing vulnerabilities in code that hasn't changed in weeks. The repository has a limited GitHub Actions minutes budget, so running a full analysis on every push to every feature branch is undesirable. Which combination of triggers in the CodeQL workflow best satisfies these requirements?

Accepted Answer

Trigger on `pull_request` targeting `main` plus a `schedule` (cron) that runs periodic full scans.

Answer

Trigger only on `push` to every branch so all commits are scanned immediately.

Answer

Trigger only on `workflow_dispatch` so the team runs scans manually when they judge it necessary.

Answer

Trigger on `push` to `main` only, with no scheduled runs, to conserve Actions minutes.

Question 6

A developer at Contoso commits a Python file that both (1) contains an active AWS access key hardcoded in a variable and (2) constructs a SQL query by concatenating unsanitized user input. The security team wants each issue surfaced by the GitHub Advanced Security capability that is purpose-built to detect it. Which pairing correctly maps each issue to the appropriate capability?

Accepted Answer

The AWS access key is caught by Secret Protection (secret scanning), and the SQL injection risk is caught by Code Security (CodeQL code scanning).

Answer

Both issues are caught by Secret Protection, since credentials and injection patterns are both treated as leaked secrets.

Answer

Both issues are caught by Code Security (CodeQL), since it performs full static analysis including credential detection.

Answer

The AWS access key is caught by Supply Chain Security (Dependabot), and the SQL injection risk is caught by Secret Protection.

Question 7

A security engineer is triaging CodeQL code scanning alerts in a repository. One alert flags a SQL injection risk, but after review the engineer confirms the flagged input is fully sanitized by an internal wrapper that CodeQL's model does not recognize, so the alert does not represent a real vulnerability. The engineer wants to dismiss the alert in a way that accurately reflects this determination and helps improve future triage reporting. Which dismissal reason should be selected?

Accepted Answer

Dismiss as "False positive" because the flagged code path is not actually exploitable

Answer

Dismiss as "Won't fix" because the team has accepted the risk of leaving it in place

Answer

Dismiss as "Used in tests" because the code is not part of the production runtime

Answer

Delete the alert entirely so it no longer appears in the security overview metrics

Question 8

A security engineer fixed a CodeQL SQL-injection alert three months ago; the alert moved to 'Fixed' after the default branch was rescanned. This week a developer reverted part of that refactor in a new commit, reintroducing the vulnerable data-flow pattern on the default branch. Assuming CodeQL analysis runs on pushes to the default branch, what happens to the alert tracking, and what is the recommended remediation practice?

Accepted Answer

CodeQL reopens the original alert (returning it to 'Open') when the vulnerable pattern reappears on the analyzed branch, so the team should treat the reopened alert as active work rather than filing a brand-new issue.

Answer

The alert stays permanently 'Fixed' once resolved; CodeQL only creates a separate new alert with no link to the prior one, so the engineer must manually cross-reference the history.

Answer

The alert can only be reopened manually by a security manager, because CodeQL never automatically transitions an alert out of the 'Fixed' state.

Answer

Because the code was previously fixed, CodeQL suppresses detection of the reintroduced pattern for 90 days and will not alert until the suppression window expires.

Question 9

A developer receives a CodeQL code scanning alert for a SQL injection vulnerability on the default branch. They create a feature branch, refactor the code to use parameterized queries, and open a pull request. After the PR's CodeQL analysis completes with no findings on the changed code, the developer wants to confirm the original alert will be properly closed. Which statement correctly describes what happens to the alert as it moves through the remediation workflow?

Accepted Answer

The alert on the default branch is automatically resolved as 'Fixed' only after the PR is merged and CodeQL runs on the default branch without detecting the vulnerability

Answer

The alert is automatically resolved as 'Fixed' the moment the PR's CodeQL analysis completes without findings, before the merge occurs

Answer

The developer must manually dismiss the alert with the reason 'Used in tests' once the PR is merged, since CodeQL cannot auto-close alerts

Answer

The alert remains open indefinitely until a security manager manually marks it as remediated in the security overview dashboard

Question 10

A security engineer at a fintech company is building a remediation runbook. She needs to document the correct end-to-end handling for two different alert types. For a Dependabot alert flagging a vulnerable transitive dependency (with a fix version available), the runbook must specify the primary remediation action that GitHub can automate. For a CodeQL alert flagging a SQL injection in first-party code, the runbook must specify who owns the fix. Which pairing correctly reflects how each remediation workflow operates?

Accepted Answer

The Dependabot alert is remediated by an auto-generated security update pull request bumping the dependency to the fixed version; the CodeQL alert requires a developer to change the application source code, as no dependency bump can resolve it.

Answer

Both alerts can be resolved automatically by Dependabot security update pull requests, since Dependabot patches both dependency and source-code vulnerabilities.

Answer

The Dependabot alert must be fixed by manually editing source code, while the CodeQL alert is remediated by an auto-generated pull request that upgrades the affected package.

Answer

Both alerts must be dismissed with a documented reason because GitHub does not provide any automated remediation for either alert type.

Question 11

A large platform team shares a monorepo across three feature squads. A CodeQL scan surfaces a high-severity SQL injection alert in a module that all three squads modify. The security manager wants a single accountable owner to drive remediation while still allowing other engineers to comment, share findings, and track the discussion directly on the alert. Which approach best supports this collaboration model using native GitHub code scanning capabilities?

Accepted Answer

Assign the alert to a specific engineer and use the alert's comment thread so collaborators can discuss the finding while ownership stays clear.

Answer

Dismiss the alert as "used in tests" so it stops appearing, then coordinate the fix over email until the module is patched.

Answer

Create three separate issues, one per squad, and delete the code scanning alert to avoid duplicate tracking.

Answer

Convert the alert into a security advisory draft so the squads can collaborate privately before any fix is written.

Question 12

A security team runs a remediation campaign and wants accurate metrics on how many code scanning alerts were genuinely resolved through code changes versus those that were triaged away without a fix. During the campaign, engineers merge PRs that remove the vulnerable code paths, and reviewers also dismiss several alerts they judge to be false positives. When the security lead reviews the code scanning results after the next default-branch scan, how will these two categories of alerts be distinguished in the alert list?

Accepted Answer

Alerts whose underlying code was remediated automatically transition to a 'Fixed' state after a scan no longer detects them, while manually triaged alerts appear in a 'Closed' state with a 'Dismissed' reason.

Answer

Both remediated and dismissed alerts appear identically as 'Closed', so the team must rely on PR links to tell them apart.

Answer

Remediated alerts must be manually marked as 'Fixed' by a reviewer, since GitHub cannot detect that vulnerable code was removed.

Answer

Dismissed alerts are permanently deleted from the alert list, so only 'Fixed' alerts remain visible for reporting.

Question 13

Your security team has enabled push protection and pre-merge CodeQL analysis on a critical microservice repository. A developer opens a pull request from a feature branch, and CodeQL flags a new SQL injection alert in the PR check. The developer argues the alert should not block the merge because 'the code isn't on the default branch yet, so it's not a real exposure.' As the security lead defining the org's shift-left enforcement strategy, which response best reflects correct preventive security practice?

Accepted Answer

The pre-merge PR analysis is intentionally designed to catch vulnerabilities before they reach the default branch; the alert should be remediated on the feature branch before merge to prevent the flaw from ever entering protected code.

Answer

Since the code is not yet on the default branch, the alert can be safely dismissed as 'won't fix' and revisited only if it later appears in a default-branch scan.

Answer

Push protection already inspects source code for injection patterns, so the CodeQL PR alert is redundant and can be ignored.

Answer

PR-based CodeQL alerts are informational only and cannot be configured to block a merge, so remediation must wait until after the merge completes.

Question 14

A developer opens a pull request that introduces a SQL injection vulnerability. CodeQL code scanning flags the alert on the PR and displays a suggested code change generated by CodeQL autofix. The developer wants to apply the fix as efficiently and safely as possible. What is the recommended way to handle the autofix suggestion?

Accepted Answer

Review the suggested fix for correctness, commit it to the PR branch (editing if needed), and let code scanning re-run to confirm the alert is resolved

Answer

Dismiss the alert as 'Used in tests' since autofix suggestions are automatically validated by CodeQL before being shown

Answer

Merge the PR immediately because the presence of an autofix suggestion means the vulnerability is already remediated in the analyzed code

Answer

Disable CodeQL autofix at the repository level, then manually rewrite the query so the alert no longer triggers

Question 15

A security engineer is reviewing a CodeQL alert flagged as 'SQL query built from user-controlled sources'. The alert view shows a series of connected steps from an HTTP request parameter through several variable assignments and finally into a database execution call. A developer argues the alert is a false positive because the input is validated. Which aspect of the CodeQL alert should the engineer examine to determine whether the reported vulnerability path is actually exploitable?

Accepted Answer

The dataflow path trace, verifying whether any step between the source and sink applies effective sanitization that CodeQL did not recognize as a barrier

Answer

The CVSS base score attached to the alert, which determines whether the flow reaches the sink

Answer

The Dependabot advisory linked to the alert, since it confirms the transitive dependency introducing the flaw

Answer

The commit timeline in the alert's history, which shows whether the source and sink were introduced in the same pull request

Question 16

A security engineer enabled CodeQL default setup on a repository to get scanning running quickly. Later, the team needs to add a custom CodeQL query pack maintained by their organization and adjust which build steps run before analysis. The engineer opens the repository's code scanning configuration but cannot find a way to specify custom queries or build commands. What is the correct action to enable these customizations?

Accepted Answer

Switch from default setup to advanced setup, which generates an editable codeql.yml workflow file where custom query packs and build steps can be defined

Answer

Edit the default setup configuration in the repository Security settings to paste the custom query pack reference into a queries field

Answer

Upload the custom query results as a SARIF file using the code scanning API, since default setup cannot run any CodeQL analysis

Answer

Disable code scanning entirely and re-enable default setup with the extended query suite, which automatically includes organization query packs

Question 17

Your organization runs CodeQL analysis on a self-hosted Jenkins pipeline instead of GitHub Actions because your build toolchain is highly customized. After the CodeQL CLI produces a `results.sarif` file, the team needs those results to appear as code scanning alerts in the repository's Security tab on GitHub.com. Which approach correctly delivers the SARIF results into GitHub code scanning?

Accepted Answer

Upload the SARIF file using the CodeQL CLI's `github upload-results` command (or the code scanning SARIF upload API endpoint) with a token that has the `security_events` write scope.

Answer

Commit the `results.sarif` file to the repository's default branch so GitHub automatically parses it into alerts.

Answer

Open a support ticket with GitHub to manually import the SARIF file, since external CI results cannot be ingested programmatically.

Answer

Convert the SARIF file to the Dependabot alert format and submit it via the Dependency Submission API.

Question 18

A DevOps engineer maintains a monorepo containing services written in Go, JavaScript, and Java. They want to enable CodeQL code scanning via GitHub Actions so that each language is analyzed independently and failures in one language's analysis do not block the others. Which approach best achieves this within a single workflow file?

Accepted Answer

Define a matrix strategy with fail-fast: false and a 'language' variable listing go, javascript, and java, so a separate job runs the init/analyze steps per language

Answer

Create one job that passes all three languages as a comma-separated string to the 'languages' input of the github/codeql-action/init step

Answer

Set the workflow to run on a nightly schedule only, since CodeQL cannot analyze more than one compiled language per push event

Answer

Add three separate workflow files, one per language, because a single workflow cannot invoke the CodeQL action more than once

Question 19

A security engineer wants their CodeQL code scanning workflow to run additional queries beyond the defaults, including lower-severity and lower-precision rules, to surface more potential issues during an internal audit. They are editing the CodeQL Action step in the workflow. Which configuration should they use to accomplish this?

Accepted Answer

Set the `queries` input to `security-extended` in the `github/codeql-action/init` step

Answer

Set `category: audit` on the `github/codeql-action/analyze` step

Answer

Add `paths-ignore` entries so more files are included in analysis

Answer

Change the workflow `on:` trigger to include a nightly `schedule` block

Question 20

Your security team ingests SARIF files produced by an external SAST tool into GitHub code scanning using the SARIF upload API. Some large SARIF uploads are being rejected or silently truncated, and developers complain that certain alerts never appear in the Security tab. Which characteristic of GitHub's SARIF ingestion should the team account for to ensure their results are reliably processed?

Accepted Answer

GitHub enforces limits on the SARIF file (such as maximum size and a cap on the number of results and runs per file), so uploads exceeding these thresholds are rejected or have results dropped.

Answer

SARIF files are only accepted if they were generated by CodeQL; third-party SARIF must first be converted to the CodeQL database format before upload.

Answer

GitHub only processes the first SARIF file uploaded per repository per day, so additional uploads within 24 hours are ignored entirely.

Answer

SARIF uploads require the file to be committed into the repository's default branch before the API will index any of its results.

Question 21

A platform engineering team runs GitHub Enterprise Server 3.11 on-premises and is planning to enable code scanning with the default CodeQL setup across all repositories in an organization. During planning, a security manager notes that on GitHub Enterprise Cloud the same default setup 'just works' after clicking enable, but on their Server instance the team must complete an additional infrastructure step before default setup will function. Which prerequisite is unique to enabling CodeQL default setup on GitHub Enterprise Server (as opposed to Enterprise Cloud)?

Accepted Answer

GitHub Actions must be enabled and configured with available self-hosted runners on the Server instance before default setup can run scans.

Answer

A GitHub Advanced Security license must be purchased separately, which is not required on Enterprise Cloud.

Answer

The dependency graph must be manually enabled per repository, whereas Enterprise Cloud enables it automatically for default setup.

Answer

Push protection for secret scanning must be enabled first because CodeQL default setup depends on it.

Question 22

You maintain a large Java monorepo where the default CodeQL analysis workflow runs on GitHub-hosted runners. Recently the 'Perform CodeQL Analysis' step began failing intermittently with the runner terminating during the database build, and the logs show the process was killed after consuming all available memory. The team must keep using GitHub Actions for scanning. What is the most appropriate first step to resolve the failures while preserving analysis quality?

Accepted Answer

Switch the workflow to a larger GitHub-hosted or self-hosted runner with more memory to accommodate the CodeQL database build

Answer

Reduce the query suite to 'code-scanning' minimal queries so the analysis consumes less memory during the build phase

Answer

Disable the autobuild step and skip database creation, relying on SARIF upload from a prior successful run

Answer

Lower the scan frequency by triggering the workflow only on a monthly schedule to avoid resource contention

Question 23

You are a security manager for an organization with 40 repositories. Leadership wants a consistent, enforced policy: any pull request that introduces a new code scanning alert of 'critical' or 'high' security severity must be blocked from merging across all repositories, without requiring each repository admin to configure branch protection individually. You also want the enforcement to apply automatically to newly created repositories. Which approach best satisfies these requirements?

Accepted Answer

Create an organization-level code scanning merge protection ruleset that blocks merges on critical and high severity alerts, and target it to all repositories including future ones

Answer

Ask each repository admin to add a required status check for CodeQL in their branch protection rules and set the failure threshold manually

Answer

Configure a custom CodeQL query suite that only emits critical and high alerts, then rely on the default setup to fail the workflow

Answer

Enable Dependabot security updates at the organization level so that high and critical findings are auto-remediated before merge

Question 24

A platform team maintains a large repository with services written in Go, TypeScript, and a legacy COBOL component. They currently use CodeQL for the Go and TypeScript code but need static analysis for COBOL, which CodeQL does not support. Leadership wants all findings consolidated in the repository's Security tab alongside the existing CodeQL alerts. What is the most appropriate approach?

Accepted Answer

Run a third-party COBOL analyzer in CI, have it emit SARIF, and upload that SARIF to GitHub using the code scanning upload action or API so results appear in the Security tab.

Answer

Wait for CodeQL to add COBOL support and disable code scanning for the other languages until then to avoid inconsistent tooling.

Answer

Add COBOL to the CodeQL matrix build language list so the CodeQL engine analyzes it alongside Go and TypeScript.

Answer

Configure the third-party analyzer to post COBOL findings only as pull request comments, since only CodeQL results can appear in the Security tab.

Question 25

A platform team notices their CodeQL analysis workflow is frequently triggered multiple times in quick succession when developers push several commits to the same feature branch within minutes. This causes a backlog of queued CodeQL jobs, consuming Actions runner minutes and delaying results for the latest commit. The team wants to ensure that when a newer run starts for a branch, any in-progress or queued CodeQL runs for that same branch are automatically cancelled. Which change to the CodeQL workflow best achieves this?

Accepted Answer

Add a `concurrency` group keyed to the workflow and branch ref with `cancel-in-progress: true` at the workflow level.

Answer

Change the workflow trigger to `schedule` with a cron expression so only one scan runs per interval.

Answer

Set `strategy.max-parallel: 1` in the matrix so only one CodeQL job runs at a time.

Answer

Enable default setup instead of advanced setup so GitHub automatically deduplicates scan runs.