Free GitHub Advanced Security (GH-500) Sample Questions

Correct answer: A — Dependabot identifies vulnerabilities in dependencies, while code scanning detects vulnerabilities in the codebase itself.

• A. Correct. Dependabot alerts focus on known vulnerabilities in project dependencies (e.g., outdated or insecure libraries declared in manifest or lock files). Code scanning alerts identify vulnerabilities directly in the repository's own code, typically using static analysis to detect security flaws, hardcoded secrets, or insecure patterns.
• B. Incorrect. Dependabot is not limited to JavaScript; it supports many ecosystems such as npm, pip, Maven, NuGet, and RubyGems. Code scanning also supports a wide range of languages, but this is not the primary difference.
• C. Incorrect. Both Dependabot alerts and code scanning are native GitHub features. Code scanning can be powered by GitHub-native tools like CodeQL, though third-party tools can also integrate; it does not require third-party integration.
• D. Incorrect. Dependabot alerts are automatically generated when GitHub detects vulnerable dependencies, and can also be triggered manually or on a schedule. Code scanning runs automatically on pushes and pull requests, but this is not the primary distinction.

Correct answer: B — Enforce a policy requiring manager approval and comments for dismissal.

• A. Incorrect. Disabling code scanning removes a critical security layer and does not address the root cause of improper dismissal. It reduces visibility into real vulnerabilities and weakens the security posture.
• B. Correct. Requiring manager approval and comments adds accountability and ensures alerts are reviewed before dismissal. This discourages careless use of 'false positive' as a default reason and improves triage quality through oversight and documentation.
• C. Incorrect. Automatically dismissing alerts after inactivity can hide potentially valid vulnerabilities and does not address the behavior of dismissing alerts without proper investigation.
• D. Incorrect. Warning emails may raise awareness but are a weak control that does not enforce accountability or ensure proper review. They are less effective than a policy-based approval and comment requirement.

Correct answer: B — Secret scanning

• A. Code scanning uses static analysis to find code vulnerabilities and insecure patterns, but does not detect exposed secrets like AWS access keys.
• B. Secret scanning scans repositories for accidentally committed secrets such as AWS access keys, tokens, and credentials, and immediately creates an alert when detected.
• C. Dependabot monitors dependencies for known vulnerabilities and creates pull requests to update them; it does not scan for hardcoded secrets.
• D. Security Overview is a dashboard that aggregates security alerts from features like code scanning, secret scanning, and Dependabot; it does not perform detection itself.

Correct answer: B — Organization-level Security Overview

• A. Incorrect. The audit log tracks administrative actions, configuration changes, and user events, not the status or count of code scanning alerts. It is not designed to summarize alert counts by repository.
• B. Correct. The Organization-level Security Overview provides a centralized view of security alerts, including code scanning alerts, across all repositories. It allows filtering by severity (e.g., critical) and repository, enabling easy identification of repositories with the highest number of critical alerts.
• C. Incorrect. Repository insights focus on a single repository’s activity metrics (e.g., traffic, commits, contributors) and do not aggregate or rank security alerts across repositories. They cannot provide an organization-wide view of critical code scanning alerts.
• D. Incorrect. A personal security log is user-specific and tracks individual activity and security-related events. It does not provide organization-wide or repository-level code scanning alert data.

Correct answer: B — Run scheduled secret scanning jobs that alert on secrets already in the default branch.

• A. Incorrect. Push protection is a preventive control that blocks secrets from being pushed, but it does not detect secrets that are already committed. This option addresses prevention, not detection of existing secrets.
• B. Correct. Running scheduled secret scanning on the default branch detects secrets that are already present in committed code, allowing for remediation of existing leaks.
• C. Incorrect. Secret scanning partner patterns detect known secret types from third-party services, not custom types. Custom patterns require GitHub Advanced Security and are configured separately.
• D. Incorrect. Enabling secret scanning alerts on private repositories is a best practice, but it does not specifically detect secrets already committed. The appropriate action for finding committed secrets is to run scanning on the default branch.

Correct answer: C — A policy that prevents developers from pushing code containing known secrets.

• A. Incorrect. This describes a security posture dashboard that provides visibility into security debt, but it is not a preventive control that blocks secrets from being pushed.
• B. Incorrect. This describes a scheduled vulnerability scan (e.g., Dependabot), which is reactive and does not prevent pushes containing secrets.
• C. Correct. This describes GitHub's push protection, a feature of secret scanning that blocks pushes containing known secrets, enforcing secure SDLC practices.
• D. Incorrect. This describes a repository security overview report, which provides visibility but does not enforce any prevention.

Correct answer: B — Automatically open pull requests to update vulnerable dependencies.

• A. Incorrect. While Dependabot can send alerts via email or on GitHub about vulnerable dependencies, this option focuses on awareness rather than remediation. Dependabot's primary function is to automate dependency updates by opening pull requests, not just to send notifications about outdated dependencies.
• B. Correct. Dependabot automatically opens pull requests to update dependencies, including versions that address known vulnerabilities. This is a core supply chain security capability in GitHub, enabling automated remediation of vulnerable dependencies.
• C. Incorrect. Scanning code for vulnerabilities using CodeQL is part of code scanning, not Dependabot. CodeQL performs static analysis on source code to find security issues and coding errors, while Dependabot focuses specifically on dependency management and updates.
• D. Incorrect. Dependabot does not directly block merging of pull requests. Blocking merges for vulnerable dependencies is typically enforced through branch protection rules, required status checks, or policy enforcement. Dependabot primarily identifies vulnerabilities and proposes fixes via pull requests.

Correct answer: B — A GitHub Advanced Security license must be available.

• A. Incorrect. GitHub Advanced Security features can be enabled on private repositories as well. Making a repository public is not a requirement.
• B. Correct. GitHub Advanced Security features require a valid GitHub Advanced Security license to be available for the organization or repository. Without an available license seat, these features cannot be enabled.
• C. Incorrect. While GitHub Advanced Security is available for GitHub Enterprise accounts, it is not strictly required. It can also be enabled for organizations on GitHub Team or GitHub Free with a trial or paid license.
• D. Incorrect. Organization owners do not need to manually approve each feature. Once the license is available, features can be enabled at the organization or repository level without manual approval per feature.

Correct answer: C — Both repository and organization levels

• A. Incorrect. Secret Protection can be enabled at more than just the repository level; it is also available at the organization level.
• B. Incorrect. Organization level is one supported scope, but it is not the only one; Secret Protection can also be enabled at the repository level.
• C. Correct. GitHub Secret Protection can be enabled at both the repository and organization levels, allowing admins to manage scanning and alerting centrally or per repository.
• D. Incorrect. While enterprise-level management exists for some security features, Secret Protection itself is enabled at the repository and organization levels, not only at the enterprise level.

Correct answer: B — Define custom secret scanning patterns

• A. Incorrect. Partner pattern scanning is designed to detect secrets from known third-party providers (e.g., AWS, GitHub tokens) and cannot be used for custom internal formats like an organization's own API keys.
• B. Correct. Defining custom secret scanning patterns allows the organization to specify regex-based rules to detect proprietary or internal secret formats, such as their internal API key format.
• C. Incorrect. Push protection helps prevent secrets from being committed to repositories, but it relies on existing secret detection rules and does not define new patterns for custom formats.
• D. Incorrect. Custom code scanning queries are used to find code vulnerabilities (e.g., SQL injection), not for detecting secrets in source code.

Correct answer: B — Dismiss the alert with a reason of 'Used in tests'

• A. Incorrect. Closing as false positive is reserved for cases where the detected string is not actually a secret. Here, the token is a real GitHub token, even if only used for testing. Therefore, false positive is not appropriate.
• B. Correct. Since the token was a test credential and has already been revoked, the alert can be dismissed with the reason 'Used in tests'. This records the investigation outcome without misclassifying it as a false positive or requiring further remediation. GitHub's secret scanning allows dismissing alerts when the secret is not a security concern, which applies here.
• C. Incorrect. While purging the token from history is a valid remediation step, it is not strictly necessary when the token has already been revoked and the repository is private. The immediate step to resolve the alert after revocation is to dismiss it, not to purge history. Additionally, rewriting history may be disruptive and is not the simplest next step.
• D. Incorrect. Generating a new token is unnecessary because the old token was a test credential and has already been revoked. Updating the alert status is not the correct action; the alert should be dismissed or closed appropriately.

Correct answer: B — Revoke the AWS access key and then remove it from the repository's history

• A. Incorrect. Deleting the repository does not invalidate the exposed AWS key or remove it from existing clones or GitHub's cache. The secret remains active and can still be exploited. The immediate priority is to revoke the credential, not delete the repo.
• B. Correct. The first and most critical action is to revoke or rotate the exposed AWS access key immediately to prevent unauthorized use. After revoking, the key should be removed from the repository's history (e.g., using git filter-branch or BFG Repo-Cleaner) to eliminate the exposure from Git history. This aligns with security best practices for high-confidence secret scanning alerts.
• C. Incorrect. While team discussion is important, it should not delay the immediate containment step. High-confidence alerts indicate the secret is active and at risk of misuse. The first action must be to revoke the credential; a review can follow afterward.
• D. Incorrect. Adding the key to .gitignore only prevents future commits from tracking that file, but it does nothing for the secret already committed in previous commits. The key remains exposed in the repository history and still active. Revocation and history removal are required.

Correct answer: A — The dependency scopes that cause the action to fail.

• A. Correct. The `fail-on-scopes` input specifies a list of dependency scopes (e.g., `development`, `runtime`) that, if matched by a changed dependency, cause the dependency review action to fail. This enforces security policies based on dependency type.
• B. Incorrect. Vulnerability severity levels are controlled by a separate input, such as `fail-on-severity`, not by `fail-on-scopes`. The `fail-on-scopes` input is specifically about dependency scopes, not severities.
• C. Incorrect. License allow/deny behavior is managed by separate inputs or tools (e.g., `allowed-licenses`), not by `fail-on-scopes`. This input does not evaluate licenses.
• D. Incorrect. The update strategy for dependency versions is configured in Dependabot or other version management tools, and is unrelated to `fail-on-scopes`, which only determines which scopes can cause the action to fail.

Correct answers: A, C — Enable Dependabot alerts in repository security settings.; Enable Dependabot security updates to open automated pull requests.

• A. Correct. Dependabot alerts must be enabled for the repository so GitHub can detect and report vulnerabilities. Without this, there are no alerts to dismiss automatically.
• B. Incorrect. GitHub does not provide a setting for auto-dismiss in the dependency graph section. The auto-dismiss behavior is tied to Dependabot security updates, not a manual toggle there.
• C. Correct. Enabling Dependabot security updates is essential because it automatically creates pull requests to fix vulnerabilities. When the fix is merged, the corresponding alert is dismissed automatically.
• D. Incorrect. A custom GitHub Actions workflow is not the standard method for automatically dismissing Dependabot alerts. The built-in Dependabot security updates handle auto-dismissal natively.
• E. Incorrect. The dependabot.yml file does not support an 'auto-dismiss' parameter; it is used to configure dependency update schedules and package ecosystems, not alert dismissal.

Correct answers: A, B — CycloneDX; SPDX

• A. Correct. GitHub natively supports exporting the dependency graph in CycloneDX format, which is a widely adopted SBOM standard.
• B. Correct. GitHub also natively supports the SPDX format for SBOM exports, another industry-standard SBOM format.
• C. Incorrect. SWID (Software Identification) tags are an SBOM-related identifier standard, but they are not natively supported by GitHub for dependency graph exports.
• D. Incorrect. OWASP Dependency-Check is a separate vulnerability scanning tool and its format is not a native GitHub dependency graph export option.
• E. Incorrect. While GitHub uses a JSON-based dependency graph internally, it does not natively export SBOMs in a GitHub-specific JSON format.

Correct answer: B — Use the 'Dependency review' feature on the pull request to see added dependencies and their vulnerability status.

• A. Merging the pull request first is unnecessary and risky. Dependabot alerts are generated only after the dependency is added to the default branch, making this a reactive measure rather than a proactive review step.
• B. Correct. The Dependency review feature shows all dependency changes in a pull request, including known vulnerabilities from the GitHub Advisory Database, enabling proactive assessment before merging.
• C. Waiting for a scheduled Dependabot scan is inefficient because scans only run on the default branch, not open PRs. Vulnerabilities would not be detected until after the change is already merged.
• D. While `npm audit` can identify local vulnerabilities, it does not automatically integrate with the GitHub Advisory Database, making it a manual, time-consuming process compared to the built-in Dependency review.

Correct answer: B — Manually resolve the merge conflicts and then merge the pull request.

• A. Incorrect. Closing the pull request and waiting for the next campaign run delays remediation and does not address the immediate security vulnerability. Dependabot will not automatically retry the same PR if conflicts persist, so the security update may be missed.
• B. Correct. The recommended approach is to manually resolve the merge conflicts so the security update can be applied cleanly, then merge the pull request. This preserves the remediation while incorporating the latest changes from the main branch. This is the standard workflow for Dependabot PRs with conflicts.
• C. Incorrect. Rebasing the main branch onto the campaign branch is not the correct approach. The campaign branch should be updated to match the main branch, not the other way around. In general, the branch with the security update is updated against the main branch.
• D. Incorrect. Downgrading the dependency to avoid conflicts would undermine the purpose of the security campaign, which is to move to a safer version. Introducing a security risk by reverting to a potentially vulnerable version is not recommended.

Correct answer: B — The alert is automatically reopened because the vulnerability is still present.

• A. Incorrect. Dependabot reevaluates the alert when the dependency version changes. If the vulnerability still exists in the new version, the alert is reopened, not left dismissed.
• B. Correct. Dependabot automatically reopens a previously dismissed alert if the same vulnerability is still present in the updated dependency, regardless of the dismissal reason.
• C. Incorrect. Dependabot does not create a new alert for the same CVE in the same dependency; instead, it reopens the existing dismissed alert.
• D. Incorrect. Dependabot does not merely add a comment; it reopens the alert when the vulnerability remains in the updated dependency.

Correct answer: A — Specify `languages: [javascript]` in the workflow

• A. Correct. Explicitly specifying `languages: [javascript]` in the workflow file overrides the default autodetection and ensures CodeQL analyzes JavaScript code. This is the standard method to enforce language analysis when detection fails.
• B. Incorrect. CodeQL determines language based on file content and configuration, not file extensions. Converting `.js` to `.jsx` does not affect detection or analysis.
• C. Incorrect. Enabling GitHub Advanced Security provides access to code security features but does not configure CodeQL to detect or analyze specific languages. Language detection must be configured separately.
• D. Incorrect. A `codeql-config.yml` file is used for customizing analysis (e.g., query filters or paths), but it does not by itself specify the languages to analyze. The primary method to set languages is in the workflow file.

Correct answers: A, C — Creating a `codeql-config.yml` file for custom analysis; Using a custom query suite to run specific queries

• A. Correct. A `codeql-config.yml` file allows you to customize CodeQL analysis by specifying paths to analyze, query suites, packs, and other configuration options beyond defaults.
• B. Incorrect. `.github/dependabot.yml` is used to configure Dependabot for automated dependency updates, not to customize CodeQL analysis.
• C. Correct. Using a custom query suite enables you to run a specific set of CodeQL queries tailored to your project's needs, extending beyond the default query suite.
• D. Incorrect. Modifying `.gitignore` affects which files Git tracks but does not influence CodeQL analysis configuration.
• E. Incorrect. Adding a `README.md` file provides project documentation and has no effect on CodeQL analysis settings or behavior.

Correct answer: A — The HTTP request parameter.

• A. Correct. In CodeQL dataflow analysis, the 'source' is the origin of untrusted data. The user-controlled HTTP request parameter is the starting point of tainted data, which CodeQL tracks as the source of the vulnerability.
• B. Incorrect. The SQL query execution is the 'sink' in the dataflow path, where untrusted data is used in a dangerous operation. It is the destination, not the source.
• C. Incorrect. A function that sanitizes input is a 'sanitizer' or 'barrier' in CodeQL terminology. It processes data to reduce taint, rather than introducing it, so it is not the source.
• D. Incorrect. A variable assignment may be an intermediate step in the dataflow path, but it does not represent the origin of untrusted data. The source is the initial point where user-controlled input enters the program.

Correct answer: B — Open, Fixed, and Dismissed

• A. Incorrect. GitHub code scanning alerts use more specific states than just Open and Closed. Alerts can be opened and then resolved as Fixed or Dismissed.
• B. Correct. GitHub code scanning alerts can be in one of three states: Open (active alert), Fixed (issue no longer detected), or Dismissed (intentionally closed with a reason).
• C. Incorrect. 'In Progress' and 'Resolved' are not standard lifecycle states for GitHub code scanning alerts. The correct states are Open, Fixed, and Dismissed.
• D. Incorrect. 'Under Review' and 'Closed' are not the lifecycle states used for GitHub code scanning alerts. The product uses Open, Fixed, and Dismissed to reflect the alert's status.

Correct answer: D — CodeQL treats code as data for deep, variant analysis.

• A. Incorrect. While CodeQL supports many popular languages, it does not necessarily support more than every third-party tool. Language coverage varies across tools, so this is not a reliable primary advantage.
• B. Incorrect. CodeQL is free for public repositories and has limited free usage for private repositories depending on the GitHub plan. It is not universally 'completely free' for private repositories in all contexts, so this is not its primary advantage.
• C. Incorrect. CodeQL often requires a build or compile step for accurate analysis, especially for compiled languages. While some analyses can run without a full build in specific cases, that is not the primary advantage over third-party tools.
• D. Correct. CodeQL treats code as data, enabling semantic, deep analysis and variant analysis across a codebase. This approach allows it to find patterns and vulnerabilities that simple pattern-based tools may miss, making it a powerful and customizable security scanning tool.

Correct answer: A — Upload SARIF file using github/codeql-action/upload-sarif@v2 with sarif_file input set to results.sarif

• A. The `github/codeql-action/upload-sarif` action is the official GitHub Action for uploading SARIF files to the Security tab. It ingests the SARIF file specified in the `sarif_file` input and displays the findings under Code Scanning alerts. This is the standard step to integrate third-party static analysis results into GitHub's Security tab.
• B. This uses the GitHub API directly via `gh api` to upload SARIF, but this is not the recommended approach within GitHub Actions. The `github/codeql-action/upload-sarif` action is the proper way. While the API endpoint exists, the `gh api` command as shown is not the typical step for uploading SARIF results to the Security tab; the dedicated action handles authentication and formatting correctly.
• C. Checking out the code is necessary to access source files but does not upload or process SARIF results. It must be included before the analysis tool runs, but the step that makes results appear in the Security tab is the SARIF upload action, not checkout.
• D. Echoing a URL to the Security tab does not upload SARIF data; it merely outputs a link. The Security tab requires the SARIF file to be uploaded via the proper action or API call for the results to appear.

Correct answer: B — Organization owner

• A. Incorrect. A security manager may influence governance and security practices, but they do not have the highest administrative authority in a GitHub organization. Repository-level or team-level roles do not supersede organization-wide ownership for governance tasks.
• B. Correct. The organization owner possesses the highest level of administrative control in a GitHub organization and can enforce governance settings across the entire organization. This role is required for managing organization-wide security and policy configurations.
• C. Incorrect. A repository administrator has control over a specific repository, not the entire organization. Their permissions are limited to repository-level governance and do not extend to organization-wide enforcement.
• D. Incorrect. A team maintainer manages team membership and settings for a specific team, but lacks organization-level authority. This role cannot enforce governance across the whole organization.

Correct answer: C — Create a custom repository role with bypass permissions

• A. Incorrect. A ruleset with a bypass list allows selected users to skip push protection, but it creates rule exceptions rather than enforcing role-based governance. It is more about exemptions than formal roles.
• B. Incorrect. The Security manager role grants permissions to configure security settings across the organization, but it does not directly allow bypassing branch protection rules. It is not the most targeted method for this need.
• C. Correct. Creating a custom repository role with bypass permissions explicitly grants the ability to bypass branch protection rules to specific users. This enforces governance by ensuring only assigned roles have that capability, aligning with role-based access control.
• D. Incorrect. Deployment environments with required approvers control deployment workflows, not branch protection bypass. They address release governance, not security policy exceptions.

Correct answers: A, C — Place the .ql file in the .github/codeql/custom-queries directory of the repository.; Add the .ql file path to the 'queries' attribute in the code scanning config.

• A. Correct. Placing the .ql file in the .github/codeql/custom-queries directory is a standard way to add custom queries. When using default setup, GitHub automatically detects and runs these queries during code scanning.
• B. Incorrect. Repository secrets are used for sensitive data like tokens or credentials, not for CodeQL query files. This method does not add a custom query to code scanning.
• C. Correct. Adding the path of the .ql file to the 'queries' attribute in the code scanning configuration file (e.g., codeql-config.yml) explicitly includes the custom query in the analysis. This is a common alternative to the default directory.
• D. Incorrect. A CodeQL database contains analyzed source code and relational data; the query is run against the database, not built into it. The query must be supplied via configuration, not embedded in the database build.

Correct answer: B — Use the 'packs' key in codeql-config.yml to assign language-specific query packs.

• A. Incorrect. Creating separate workflow files duplicates logic and makes maintenance harder. It is not the most efficient or scalable approach for language-specific configurations.
• B. Correct. The 'packs' key in codeql-config.yml allows you to specify language-specific query packs, enabling targeted analysis for each language in a single configuration file, without fragmenting the workflow.
• C. Incorrect. Running the CodeQL CLI locally and manually uploading results bypasses GitHub Actions automation and is not a best practice for CI/CD pipelines. It also does not leverage GitHub's built-in integration.
• D. Incorrect. While a matrix strategy can vary workflow inputs across jobs, it is not the primary mechanism for assigning language-specific CodeQL query packs or configuration. Customization is typically done through the CodeQL configuration file (codeql-config.yml) rather than matrix parameters alone.

Correct answer: B — Dependabot alerts

• A. Push protection blocks pushes containing secrets or other sensitive data, but it does not detect vulnerable dependencies.
• B. Dependabot alerts notify repository maintainers when GitHub detects known vulnerabilities in dependencies, allowing proactive remediation. This is the primary feature for dependency vulnerability detection.
• C. Dependency review shows the impact of dependency changes in pull requests, but it is not the primary feature for ongoing alerts about vulnerable dependencies.
• D. Code scanning finds vulnerabilities in custom code using static analysis, not specifically in dependencies.

Correct answer: B — It maintains the CVE list and oversees the overall CVE Program.

• A. Incorrect. MITRE does not assign CVSS scores; that role is typically performed by the National Vulnerability Database (NVD) or other organizations. MITRE's role is focused on CVE management, not scoring.
• B. Correct. MITRE operates the CVE Program and maintains the CVE list, acting as the central coordination point for publicly known vulnerabilities. It oversees CVE identifiers and the overall program structure, rather than scoring or patching vulnerabilities.
• C. Incorrect. MITRE is not primarily a funding body for vulnerability research or disclosure. Its role in the CVE ecosystem is administrative and coordination-focused, not financial.
• D. Incorrect. MITRE does not develop software patches for vulnerabilities. Patch development is the responsibility of the affected software vendors or maintainers after a vulnerability is disclosed.

Correct answer: B — To provide a curated set of security advisories for open source software.

• A. Incorrect. While the GitHub Advisory Database includes CVSS scores as part of advisories, its primary purpose is not solely to store and distribute them. It serves a broader role in curating and publishing security advisories.
• B. Correct. The GitHub Advisory Database is designed to provide a curated set of security advisories for open source software. It aggregates and maintains advisories that help developers and security teams identify and address vulnerabilities in their dependencies.
• C. Incorrect. The database does not automatically create or apply patches to repositories. It is an informational and advisory resource, not an automated remediation engine. Patching is a manual or tool-assisted process.
• D. Incorrect. While exploit availability can be relevant to vulnerability assessment, real-time monitoring and reporting of exploits for CVEs is not the primary purpose. The main role is to curate and publish security advisories.

Correct answer: C — Repositories inherit the configuration, but settings can be overridden unless enforced.

• A. Incorrect. Organization-level security configurations are inherited by repositories, but they are not universally immutable. Repositories can override settings if the configuration is not enforced by the organization.
• B. Incorrect. Repositories cannot opt out of the configuration entirely. They inherit the configuration and can override individual settings only if not enforced. Opting out is not a standard capability for security configurations.
• C. Correct. Organization-level security configurations are inherited by repositories. However, individual settings can be overridden at the repository level unless the organization has enforced the configuration, making the settings immutable.
• D. Incorrect. Repositories do inherit the security configuration from the organization by default. They do not need to be manually configured from scratch, though overrides are possible.

Correct answer: B — The push is blocked and the developer receives a warning about the secret.

• A. Incorrect. With push protection enabled, GitHub blocks pushes containing detected secrets like Slack webhook URLs. The commit is not pushed successfully; instead, the push is blocked before the secret is accepted.
• B. Correct. Push protection prevents the push from completing when a supported secret pattern is detected. The developer receives a warning explaining that a secret was detected and why the push was blocked, allowing them to remove the secret before retrying.
• C. Incorrect. While push protection blocks the push, it also provides a notification to the developer about the detected secret. The push is not silent; the developer is informed immediately.
• D. Incorrect. GitHub does not push the commit and then revert it. When push protection is enabled, the push is blocked before the secret is added to the remote repository, so no commit is made.

Correct answer: C — Define a CodeQL configuration file with `paths-ignore` for test directories and call it from the workflow. This tells CodeQL to avoid analyzing files in the listed paths during code scanning.

• A. Incorrect. Adding `paths-ignore` to the workflow trigger events only prevents the workflow from running when changes are made to the ignored paths. It does not exclude the test directory from CodeQL analysis if the workflow runs due to other file changes. CodeQL will still analyze the entire repository according to its configuration.
• B. Incorrect. This option also relies on `paths-ignore` in the workflow's `on` events, which controls when the workflow triggers, not which files CodeQL analyzes. The test directory would still be scanned if the workflow executes for any other reason. Excluding directories from analysis requires CodeQL-specific configuration, not event filtering.
• C. Correct. Define a CodeQL configuration file (e.g., `.github/codeql/codeql-config.yml`) with a `paths-ignore` property listing the directories to exclude, such as `test/`. Then reference this configuration file in the `init` step of the CodeQL workflow. This tells CodeQL to skip the specified paths during analysis, effectively excluding them from code scanning while analyzing the rest of the codebase.
• D. Incorrect. Custom query packs determine which queries are executed during analysis, not which source files are included or excluded. Excluding files from analysis is done via CodeQL configuration (e.g., `paths-ignore` in the config file), not by creating a query pack. A query pack cannot prevent CodeQL from analyzing files in the test directory.

Correct answer: B — It defines which queries to run and which paths to exclude.

• A. Incorrect. The CodeQL configuration file does not specify the version of CodeQL to use. Version selection is handled by the CodeQL CLI, the GitHub Actions workflow, or the default tooling behavior, not by the config file itself.
• B. Correct. The codeql-config.yml file is used to customize CodeQL analysis, including defining which queries to run, customizing query suites, and specifying paths to include or exclude from analysis.
• C. Incorrect. The GitHub Actions runner environment is configured in the workflow YAML file (e.g., .github/workflows/codeql.yml), not in the CodeQL configuration file. The codeql-config.yml is specific to analysis settings.
• D. Incorrect. The CodeQL configuration file does not handle integrations with third-party tools. Its purpose is to control CodeQL analysis settings like queries, packs, and exclusions within GitHub code scanning. Integrations are managed separately via GitHub Actions or other CI/CD configurations.