GH-500 GitHub Advanced Security Exam Questions and Answers

Using the Custom setting allows you to subscribe to specific event types, such as Dependabot alerts or vulnerability notifications, without being overwhelmed by all repository activity. This is essential for repository maintainers who need fine-grained control over what kinds of events trigger notifications.

This setting is configurable per repository and allows users to stay aware of critical issues while minimizing notification noise.

GitHub identifies repository administrators as users who can enable Dependabot alerts for an individual repository. Organization owners can also enable the feature at organization scope, but they are not one of the options presented. Once enabled, Dependabot compares dependency information against vulnerability data from the GitHub Advisory Database and generates alerts when affected dependencies are found. Users with Maintain or Write access can view and work with alerts when permissions allow, but enabling or disabling repository security features requires repository administration privileges under the configuration model tested here. Outside collaborators do not automatically receive that level of administrative control, and “security analyst” is not a standard repository role granting feature-enablement authority. Therefore, repository administrator is the correct selection.

After generating an alert for a vulnerable dependency, Dependabot automatically attempts to create a pull request to upgrade that dependency to the minimum required secure version —if a fix is available and compatible with your project.

This automated PR helps teams fix vulnerabilities quickly with minimal manual intervention. You can also configure update behaviors using dependabot.yml, but in the default state, PR creation is automatic.

Dependency review runs as part of a pull request and shows which dependencies are being added, removed, or changed — and highlights vulnerabilities associated with any added packages.

It works in real-time and is specifically designed for use during pull request workflows.

The dependency graph is an overview, Dependabot alerts notify post-merge, and the Security tab shows the aggregated alert list.

Comprehensive and Detailed Explanation:

For code scanning to be triggered on a specific branch, the branch must contain the appropriate workflow file, typically located in the .github/workflows directory. This YAML file defines the code scanning configuration and specifies the events that trigger the scan (e.g., push, pull_request).​

Without the workflow file in the branch, GitHub Actions will not execute the code scanning process for that branch. The repository's visibility (private or public), the status of secret scanning, or the activity level of developers do not directly influence the triggering of code scanning.​

Under the GitHub Actions minute-multiplier model tested by this question, jobs executed on GitHub-hosted Windows runners consume included minutes at twice the rate of equivalent Linux-runner jobs. Linux has a multiplier of 1, while Windows has a multiplier of 2; historically macOS used a substantially higher multiplier. Because CodeQL advanced setup can execute as a GitHub Actions workflow, the operating system selected with runs-on affects Actions consumption in the same way as other GitHub-hosted workflows. GitHub's newer billing documentation increasingly expresses runner usage through operating-system-specific per-minute pricing rather than only multiplier terminology, but the exam question specifically tests the established Windows-versus-Linux minute multiplier. Therefore, the expected answer is 2x higher.

When integrating CodeQL outside of GitHub Actions (e.g., in Jenkins, CircleCI):

Install the CLI : Needed to run CodeQL commands.

Analyze code : Perform the CodeQL analysis on your project with the CLI.

Upload scan results : Export the results in SARIF format and use GitHub’s API to upload them to your repo’s security tab.

You don’t need to write custom queries unless extending functionality. “Processing alerts” happens after GitHub receives the results.

When using a SARIF-compatible tool within GitHub Actions, it's necessary to explicitly add a step in your workflow to upload the analysis results. This is typically done using the upload-sarif action, which takes the SARIF file generated by your tool and uploads it to GitHub for processing and display in the Security tab. Without this step, the results won't be available in GitHub's code scanning interface.​

Dependabot alerts can identify vulnerable direct dependencies declared in a manifest and vulnerable indirect or transitive dependencies when GitHub can determine their versions from a lockfile. GitHub's dependency graph extracts dependency information from supported manifest and lock files and compares identified package versions against security advisories in the GitHub Advisory Database. Direct dependencies explicitly declared in manifests therefore qualify for vulnerability detection. Transitive dependencies recorded with resolvable versions in lockfiles can also generate alerts. A “loose” dependency declaration may not provide GitHub with a sufficiently specific installed version to establish that the project actually uses a vulnerable release, while a particular time such as 08:00 UTC has nothing to do with whether a dependency qualifies for an alert. Thus, A and C are correct.

GitHub enables the dependency graph by default for public repositories. The graph analyzes supported manifest and lock files and identifies dependencies declared in those files. When a dependency is added or changed in a supported manifest on the repository's default branch, GitHub updates the dependency graph automatically. Private repositories can also use the dependency graph, but the feature must be enabled unless an organization or enterprise configuration enables it automatically. Forking a repository does not itself constitute the dependency declaration that this question describes. Therefore, under default settings, adding a new dependency to a manifest in a public repository is the scenario that causes GitHub's dependency graph to identify and represent that dependency.

Before CodeQL can execute security queries, the source code must first be represented in a CodeQL database. Database creation extracts structured, relational information from the source code and, where applicable, observes or performs the build process required for the language being analyzed. Once the database exists, CodeQL can execute queries against it. The resulting query output is then interpreted using query metadata and can ultimately be converted to a format such as SARIF for presentation as code scanning alerts. Therefore, running queries, interpreting results, and converting results are later phases of analysis. GitHub's CodeQL documentation explicitly identifies creation of the CodeQL database as a prerequisite for analyzing source code with CodeQL queries, making preparation/database creation the correct first step.

Comprehensive and Detailed Explanation:

Before defining a custom pattern for secret scanning in a repository, you must enable secret scanning for that repository. Secret scanning must be active to utilize custom patterns, which allow you to define specific formats (using regular expressions) for secrets unique to your organization.​

Once secret scanning is enabled, you can add custom patterns to detect and prevent the exposure of sensitive information tailored to your needs.​

Comprehensive and Detailed Explanation:

To generate a dependency graph for a private repository, GitHub requires:​

Dependency graph enabled: The repository must have the dependency graph feature enabled. This can be configured at the organization level to apply to all new private repositories.​

Access to manifest and lock files: GitHub needs read-only access to the repository's dependency manifest and lock files (e.g., package.json, requirements.txt) to identify and map dependencies.​

When defining a custom pattern for secret scanning, two key fields are required:

Name of the pattern : A unique label to identify the pattern

Secret format : A regular expression that defines what the secret looks like (e.g., token format)

You can optionally specify additional match requirements (like required context keywords), but they’re not mandatory. Listing repositories is also not part of the required fields during pattern creation.

GitHub Actions supports path filters for events such as push and pull_request. The paths: key allows a workflow to run only when changed files match one or more specified path patterns. For example, a workflow could use paths: - 'src/**' so that a code scanning job runs when files under the src directory are changed. The related paths-ignore: key performs the opposite function by excluding matching paths. Characters such as ** are glob-pattern components placed beneath paths:; they are not replacements for the paths keyword itself. Therefore, because the workflow must conditionally run when files in a particular directory change, line 3 should contain paths: followed by the applicable directory pattern.

Comprehensive and Detailed Explanation:

In private repositories, users with write access can fix code scanning alerts. They can do this by committing changes that address the issues identified by the code scanning tools. This level of access ensures that only trusted contributors can modify the code to resolve potential security vulnerabilities.​

GitHub Docs

Users with read or triage roles do not have the necessary permissions to make code changes, and the security manager role is primarily focused on managing security settings rather than directly modifying code.​

A valid Dependabot configuration requires the top-level version and updates keys. The configuration currently uses version: 2, which identifies the Dependabot configuration syntax. The updates section contains one or more configuration entries describing package ecosystems that Dependabot should monitor. Within each update entry, additional required settings include package-ecosystem, directory or directories, and schedule.interval. The top-level registries key is optional and is used when Dependabot needs authentication information for private registries. assignees is also optional and controls which users are automatically assigned to Dependabot-created pull requests. Therefore, although several other properties may appear in a practical configuration file, only version and updates are mandatory top-level keys among the choices provided.

CodeQL security queries are associated with Common Weakness Enumeration (CWE) classifications. CWE provides standardized categories for classes of software weaknesses, such as improper input validation, path traversal, or SQL injection. GitHub CodeQL query metadata and alert tags can contain CWE identifiers, and GitHub allows code scanning alerts to be filtered by CWE tags. CVEs identify specific publicly disclosed vulnerabilities rather than general weakness categories in source-code analysis. A GHSA identifies a GitHub Security Advisory, while VEX communicates whether a product is affected by a known vulnerability. For CodeQL findings, CWE is therefore the relevant classification system used to describe the type of weakness represented by an alert. GitHub's code scanning API also exposes CodeQL rules containing external/cwe/... tags.

Code scanning merge requirements and severity thresholds are repository configuration controls and are therefore managed from the repository's Settings area. In GitHub's current interface, administrators can create a branch ruleset under Settings and configure Require code scanning results. They can then select the code scanning tool and specify alert thresholds, including which normal alerts or security-severity levels should prevent merging. The Security and quality tab is primarily where security findings are reviewed and triaged, while the Actions tab displays workflow execution information. The Pull Requests tab is used to review and merge proposed changes rather than configure repository-wide code scanning policy. Thus, although GitHub's implementation has evolved toward ruleset-based merge protection, the appropriate top-level location remains the repository's Settings tab.

To grant specific users access to view and manage secret scanning alerts , you do this via the Settings tab of the repository. From there, under the "Code security and analysis" section, you can add individuals or teams with roles such as security manager .

The Security tab only displays alerts; access control is handled in Settings.

For compiled languages, CodeQL performs extraction by monitoring the normal build process . This means it watches your usual build commands (like make, javac, or dotnet build) and extracts the relevant data from the actual build steps being executed. CodeQL uses this information to construct a semantic database of the application.

This approach ensures that CodeQL captures a precise, real-world representation of the code and its behavior as it is compiled, including platform-specific configurations or conditional logic used during build.

For the organization-owned private repository scenario tested by this question, C is the intended answer. GitHub Secret Protection supports secret scanning for private and internal repositories owned by organizations using an eligible GitHub Team or GitHub Enterprise plan with Secret Protection enabled. Licensing is managed at the organization or enterprise level; an individual license is not uploaded to a repository or attached directly to a user's account. Current GitHub documentation has expanded availability in some enterprise scenarios, including certain user-owned repositories under Enterprise Managed Users and GitHub Enterprise Server. However, for the standard GitHub Advanced Security organization model represented by the question, an organization-owned repository is the applicable prerequisite among the supplied choices.

Dependency review and secret scanning are capabilities associated with GitHub Advanced Security. In GitHub's current product structure, dependency review is included with GitHub Code Security, while secret scanning is a central capability of GitHub Secret Protection. Both products are components of the broader GitHub Advanced Security offering, and legacy GHAS licenses can include the combined capabilities. The dependency graph is an important supply-chain feature and provides the underlying dependency inventory, but it is broadly available beyond the licensed GHAS feature set and is enabled by default for public repositories. A repository security policy, normally provided through SECURITY.md, is also a general repository capability rather than one of the licensed Advanced Security features being tested. Therefore, dependency review and secret scanning are the correct selections.

Comprehensive and Detailed Explanation:

Push protection for secret scanning custom patterns is an opt-in feature. This means that for each custom pattern defined in a repository, maintainers can choose to enable or disable push protection individually. This provides flexibility, allowing teams to enforce push protection on sensitive patterns while leaving it disabled for others.​

Secret scanning for a private repository is enabled through the repository's security configuration/settings, currently located under Settings → Security and quality → Advanced Security. In current GitHub terminology, enabling Secret Protection enables secret scanning alerts for an eligible private or internal repository. Repository rulesets control policies such as branch protection, required checks, and merge conditions; they are not the primary mechanism for enabling secret scanning. GitHub also does not use a secret.yml file to activate the feature. Code scanning default setup configures CodeQL analysis and is separate from secret detection. Organization owners can additionally enable Secret Protection and secret-scanning capabilities at scale by applying security configurations to repositories. Consequently, the code security or Advanced Security settings area is the correct location, making A the correct answer.

When a person's access to a private repository is removed, GitHub deletes that person's private forks belonging to the repository's network. This prevents the GitHub-hosted fork from remaining available after the user loses authorization to the upstream private repository. GitHub cannot, however, automatically erase local clones that the person previously downloaded to their own computers; the documentation explicitly states that local clones are retained. Removing one individual's access also does not necessarily revoke an entire team's access, because team permissions are managed separately. Nor does GitHub automatically delete confidential information that may have been copied outside the repository. GitHub therefore advises organizations to ensure that former collaborators appropriately dispose of confidential or proprietary information. The direct platform behavior described in the question is deletion of the user's private forks.

Code scanning is a static analysis feature that examines your source code to identify security vulnerabilities and coding errors . It runs either on every push, pull request, or a scheduled time depending on the workflow configuration.

It does not automatically contact maintainers, scan full Git history, or block pushes unless explicitly configured to do so.

Under GitHub's current documented behavior, the minimum repository permission that can bypass ordinary repository push protection is Write, making B correct. GitHub states that, when delegated bypass is not enabled, a contributor with write access can bypass a push-protection block by providing an allowed reason. The bypass is recorded, and repository-level push protection can generate a corresponding alert and audit-log entry. The PDF marks Admin, which reflects older or more restrictive behavior and is no longer the best answer under current GitHub documentation. Organizations can also enable delegated bypass, which changes the model by requiring contributors without bypass privileges to request approval from designated reviewers. Organization owners, security managers, or specifically authorized roles can then manage those requests. For the default non-delegated model, Write is sufficient.

The best way to prioritize secret scanning alerts is to filter by active secrets — these are secrets GitHub has confirmed are still valid and could be exploited. This allows security teams to focus on high-risk exposures that require immediate attention.

Sorting by time or filtering by custom patterns won’t help with risk prioritization directly.

A GitHub personal access token (PAT) is a credential and is therefore a type of value that secret scanning is designed to detect. GitHub supports patterns for GitHub-issued tokens and can generate secret scanning alerts when supported PAT formats are committed to repositories. GitHub also performs validity checks for certain GitHub tokens and can distinguish active from inactive credentials. SQL injection, cross-site scripting, and server-side request forgery are application vulnerabilities rather than exposed credentials; those issues are detected through code scanning tools such as CodeQL. The distinction is important: secret scanning looks for credentials, API keys, passwords, tokens, and similar sensitive values, whereas code scanning analyzes source code for insecure programming patterns. Therefore, only the GitHub PAT belongs to secret scanning.

By default, users with Write, Maintain, or Admin permissions will receive notifications for new Dependabot alerts . However, Write permission is the minimum level needed to be automatically notified. Users with only Read access do not receive alerts unless added explicitly.

The Allow for all organizations policy permits repository administrators throughout organizations owned by the enterprise to enable applicable Advanced Security capabilities on their repositories. GitHub enterprise policy can determine whether repository administrators are allowed to enable GitHub Secret Protection, GitHub Code Security, or legacy GitHub Advanced Security features. Selecting an option limited to chosen organizations would restrict availability rather than permit it enterprise-wide. A prohibition such as Never allow would prevent repository administrators from enabling the feature, while No policy does not explicitly establish the enterprise-wide permission requested. GitHub's current documentation describes this policy as controlling availability across all organizations or specified organizations, with organization owners and security managers retaining broader security-management capabilities. Therefore, B matches the stated requirement to allow repository administrators throughout all enterprise organizations.

Comprehensive and Detailed Explanation:

When configuring Dependabot via the dependabot.yml file, the following fields are mandatory for each update configuration:

directory: Specifies the location of the package manifest within the repository. This tells Dependabot where to look for dependency files.​

package-ecosystem: Indicates the type of package manager (e.g., npm, pip, maven) used in the specified directory.​

schedule.interval: Defines how frequently Dependabot checks for updates (e.g., daily, weekly). This ensures regular scanning for outdated or vulnerable dependencies.​

The milestone field is optional and used for associating pull requests with milestones. The allow field is also optional and used to specify which dependencies to update.​

GitLab

All results from CodeQL analysis appear under the repository’s code scanning alerts tab. This section is part of the Security tab and provides a list of all current, fixed, and dismissed alerts found by CodeQL.

A CodeQL database is used internally during scanning but does not display results. Query packs contain rules, not results. Security advisories are for published vulnerabilities, not per-repo findings.