Free Microsoft GH-500 Exam Questions – 2025 Updated

B. github/codeql is the repository containing the standard CodeQL queries, not a configuration key for adding custom ones.

C. Scope is not a recognized key in the CodeQL configuration file for specifying additional queries.

1. GitHub Docs. (n.d.). Customizing your advanced setup for code scanning. Retrieved from https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning

For option D (Queries): In the section "Specifying queries to run," the documentation states, "You can use queries to specify which queries to run in your configuration file." It provides examples of using the uses keyword to point to a .ql file, a directory containing queries, or a query suite definition file.

For option A (Packs): In the section "Running additional query packs," the documentation explains, "To add one or more CodeQL query packs, add a packs entry to your configuration file." It shows how to list packs to be used in the analysis.

B. The GitHub Actions runner only executes the jobs defined in a workflow; it does not have default behaviors like automatically uploading specific file types.

C. This is only true for the native CodeQL action's analyze step. The question refers to any "SARIF-compatible tool," which includes third-party tools that require a separate upload step.

D. While the GitHub CLI (gh) can upload SARIF files, the idiomatic and recommended method within a GitHub Actions workflow is to use the dedicated upload-sarif action.

1. GitHub Docs, "Uploading a SARIF file to GitHub." This document explicitly states, "You can use the github/codeql-action/upload-sarif action to upload a SARIF file... This is useful when you use a static analysis tool other than CodeQL." It provides a clear YAML example with a final step dedicated to the upload:

yaml

- name: Upload analysis results to GitHub

uses: github/codeql-action/upload-sarif@v3

with:

sariffile: results.sarif

Source: GitHub Enterprise Cloud Documentation, "Code security," "Code scanning," "Integrating with code scanning," "Uploading a SARIF file to GitHub."

2. GitHub Docs, "About SARIF file uploads for code scanning." This page clarifies the general requirement: "You need to run your SARIF-compatible analysis tool in a GitHub Actions workflow... and include a step that uploads the results.sarif file."

Source: GitHub Enterprise Cloud Documentation, "Code security," "Code scanning," "Integrating with code scanning," "About SARIF file uploads for code scanning."

B. Security: This is the top-level tab in a repository's navigation where you access all security-related features, not a specific action taken within an alert.

C. Code scanning alerts: This is the link under the "Security" tab that takes you to the list of all alerts, not the control used to get more context on a single, specific alert.

1. GitHub Docs, "Managing code scanning alerts for your repository." Under the section "Viewing the details of an alert," the documentation states: "For alerts that highlight a data-flow problem, you can also view the path from the data source to the sink. To view the data flow path, click Show paths." This directly confirms the function of the "Show paths" link for data flow analysis.

2. GitHub Docs, "About code scanning alerts." In the section "About data flow analysis," it explains: "Data flow analysis finds potential security issues in code by tracking the flow of data from a source... to a sink... Code scanning shows you how the data travels from the source to the sink in the alert details." This establishes the concept that viewing the path is the primary way to get context.

A. Secret scanning is a GitHub feature that scans repository content, not the continuous integration system's infrastructure or configuration itself.

B. The feature is specific to repositories hosted on GitHub. It does not scan any arbitrary Git repository hosted on other platforms like GitLab or a private server.

D. Secret scanning finds credentials for external services that are located within a repository; it does not scan the external services themselves.

1. GitHub Docs, "About secret scanning." This document explicitly states, "Secret scanning scans your entire Git history on all branches present in your GitHub repository for secrets." This confirms the feature's scope is the GitHub repository.

Source: https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning, Section: "About secret scanning."

2. Microsoft Learn, "Configure secret scanning," GH-500 Learning Path. The official training material for the exam describes the feature's function: "GitHub scans repositories for known types of secrets to prevent fraudulent use of secrets that were committed by accident." The context is always a repository on GitHub.

Source: https://learn.microsoft.com/en-us/training/modules/configure-secret-scanning-in-your-repo/2-what-is-secret-scanning, Paragraph 1.

3. GitHub Docs, "Managing security and analysis settings for your repository." The configuration process for secret scanning is performed within the settings of a specific GitHub repository, reinforcing that its operational boundary is the repository.

Source: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-security-and-analysis-settings-for-your-repository, Section: "Allowing or disallowing features for your private repository."

B. Exploit Prediction Scoring System (EPSS): This is a scoring system that estimates the probability of a vulnerability being exploited. It provides a metric for prioritization, not a format for describing the vulnerability itself.

D. Vulnerability Exploitability eXchange (VEX): VEX is a format used to communicate the status of a vulnerability within a specific product (e.g., "not affected"), rather than describing the initial vulnerability alert.

1. GitHub Docs, "About the GitHub Advisory Database": This document explicitly states, "Each security advisory includes information about the vulnerability, which may include... a CVE (Common Vulnerabilities and Exposures) identifier... and one or more Common Weakness Enumeration (CWE) identifiers." This directly confirms the use of both CVE and CWE.

Source: GitHub, Inc. (2024). About the GitHub Advisory Database. GitHub Docs. Retrieved from https://docs.github.com/en/code-security/security-advisories/global-security-advisories/about-the-github-advisory-database (See the section "About security advisories").

2. GitHub Docs, "About Dependabot alerts": This page clarifies that Dependabot alerts are based on vulnerabilities from the GitHub Advisory Database, which uses CVE identifiers.

Source: GitHub, Inc. (2024). About Dependabot alerts. GitHub Docs. Retrieved from https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts (See the section "Detection of insecure dependencies").

A. Maintain: Users with Maintain permissions can manage many repository settings but lack the authority to create security advisories or request CVEs.

C. Triage: The Triage role is limited to managing issues and pull requests and does not include permissions for security management features.

D. Write: The Write role allows users to contribute code and manage pull requests but does not grant access to repository security settings like advisories.

1. GitHub Docs, "Creating a repository security advisory." Under the "Prerequisites" section, it explicitly states: "You must have admin permissions for the repository." This prerequisite applies to the entire advisory creation process, which includes requesting a CVE.

Source: GitHub Official Documentation. Retrieved from https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/creating-a-repository-security-advisory#prerequisites

2. GitHub Docs, "About GitHub Security Advisories for repositories." This document clarifies the roles involved, stating, "Repository owners and security managers have admin permissions for security advisories in a repository." This reinforces that administrative-level access is the foundation for managing advisories.

Source: GitHub Official Documentation. Retrieved from https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/about-github-security-advisories-for-repositories

3. GitHub Docs, "Permission levels for a personal account repository." The repository roles and permissions table confirms that actions related to "Manage security advisories" are exclusively available to the Admin role.

Source: GitHub Official Documentation. Retrieved from https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-access-to-your-personal-repositories/permission-levels-for-a-personal-account-repository

A. Triaging an alert involves manually reviewing and dismissing it (e.g., as a false positive or acceptable risk), which is a different action from fixing the code to resolve it.

B. Data-flow analysis is a technique used by CodeQL to find potential security issues; it is part of the detection process, not the resolution or closure process.

C. Clicking an alert within a pull request is a navigational action for viewing its details; it does not alter the code or the status of the alert.

1. GitHub Docs, "Managing code scanning alerts for your repository." Under the section "Fixing an alert," the documentation states, "GitHub automatically closes an alert if you fix the code in a pull request... GitHub closes an alert when code scanning determines that the code with the potential vulnerability is no longer present in the latest analysis for a branch."

2. Microsoft Learn, "Manage code scanning alerts in GitHub." In the "Fix code scanning alerts" unit, it is specified that "GitHub closes an alert automatically when you fix the code that triggered it. To fix an alert, you need to commit your changes to the branch where the alert was found."

3. GitHub Docs, "About code scanning alerts." In the section "About the status and details of alerts," it clarifies the lifecycle: "An alert is usually closed when a user fixes the code that triggered the alert and pushes their changes to the branch that is being scanned."

C. A list of repositories to scan

Specifying repositories is part of enabling or configuring a scan, not defining the pattern itself.

D. Additional match requirements for the secret format

These are optional settings, such as "surrounding content," used to refine the main pattern and reduce false positives, not a mandatory creation detail.

1. GitHub Docs, "Defining custom patterns for secret scanning." This official documentation outlines the steps for creating a custom pattern. In the section "Creating a custom pattern," it explicitly lists "Name" and "Secret format (regex)" as required fields. It also describes "Additional match requirements" as an optional step to refine results. The process described does not include selecting repositories during pattern creation.

Reference Location: Navigate to the "Creating a custom pattern" section. The input fields in the UI steps clearly distinguish between required and optional information.

2. GitHub Docs, "About secret scanning." This document provides an overview of the feature and distinguishes between defining patterns and enabling them for repositories. It clarifies that patterns are defined at the organization/enterprise level before being applied to specific repositories or all repositories.

Reference Location: See the section on "Defining custom patterns for secret scanning."

A. Enable all in existing repositories: This option is too generic. It does not specify which security feature (e.g., Dependabot alerts, Secret scanning, Code scanning) should be enabled.

B. Enable by default for new public repositories: This setting only applies to newly created public repositories and would not activate alerts for any existing or private repositories.

D. Enable all for Dependency graph: Enabling the Dependency graph is a necessary prerequisite, as it identifies the project's dependencies. However, it does not generate vulnerability alerts on its own; that is the specific function of Dependabot alerts.

---

1. GitHub Docs, "Managing security and analysis settings for your user account."

Location: Section "Enabling or disabling features for existing repositories."

Content: This document explicitly outlines the steps to manage security features. It states, "Under 'Code security and analysis', find the feature you want to manage... To the right of the feature, click Disable all or Enable all." It lists "Dependabot alerts" as a distinct feature that can be enabled, which is the direct action required to receive vulnerability alerts.

2. GitHub Docs, "About Dependabot alerts."

Location: Introduction section.

Content: This page clarifies the relationship between the dependency graph and alerts: "Dependabot alerts are generated when GitHub detects that a repository uses a dependency with a known vulnerability... The dependency graph is a prerequisite for Dependabot alerts." This confirms that enabling the graph (Option D) is insufficient and that enabling "Dependabot alerts" (Option C) is the correct, specific action.

B. This describes private vulnerability reporting, a feature that allows security researchers to disclose vulnerabilities to repository maintainers confidentially, which is separate from the listed GHAS tools.

C. This describes Dependabot alerts, which notify you about existing dependencies with known vulnerabilities in your repository, but it doesn't cover code scanning or secret scanning.

D. This describes Dependabot security and version updates, which automatically create pull requests to update dependencies, a different function from the three features mentioned in the question.

1. GitHub Docs, "About GitHub Advanced Security." This document provides an overview, stating, "GitHub Advanced Security features are available for enterprise accounts on GitHub Enterprise Cloud and GitHub Enterprise Server... [It] provides additional features... such as code scanning, secret scanning, and dependency review."

Source: https://docs.github.com/en/get-started/learning-about-github/about-github-advanced-security

2. GitHub Docs, "About code scanning." Section: "About code scanning." It states, "Code scanning is a feature that you use to analyze the code in a GitHub repository to find security vulnerabilities and coding errors."

Source: https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning

3. GitHub Docs, "About secret scanning." Section: "About secret scanning." It explains, "Secret scanning helps protect you by searching repositories for known types of secrets... GitHub scans the content for secrets."

Source: https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning

4. GitHub Docs, "About dependency review." Section: "What is dependency review?" It details, "Dependency review helps you understand dependency changes and the security impact of these changes at every pull request... You can clearly see what's changed in a pull request."

Source: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review

B. All new repositories within your organization: This requires enabling GitHub Advanced Security at the organization level, which contradicts the scenario's premise that no features are configured.

C. User-owned private repositories: Secret scanning for user-owned private repositories is a feature of GitHub Advanced Security, which is not enabled by default and requires a specific plan.

D. Private repositories: This functionality is part of the paid GitHub Advanced Security license and is not enabled by default without explicit configuration.

---

1. GitHub Docs, "About secret scanning." This official documentation explicitly states the availability of the feature.

Reference Section: "Availability of secret scanning"

Content: "Secret scanning is available on all public repositories on GitHub.com. Organizations that use GitHub Enterprise Cloud with a license for GitHub Advanced Security can also enable secret scanning on their private and internal repositories." This directly confirms that the feature is on by default only for public repositories.

2. GitHub Docs, "Configuring secret scanning for your repositories." This document details the steps required to enable the feature for private repositories, reinforcing that it is not on by default.

Reference Section: "Enabling GitHub Advanced Security"

Content: "You must enable GitHub Advanced Security for your repository before you can configure secret scanning... Secret scanning is automatically enabled on all public repositories." This shows that an explicit action is needed for private repositories, unlike public ones.

B. It displays a public alert in the Security tab of the repository.

Secret scanning alerts are confidential and only visible to users with administrative permissions on the repository, not to the public.

C. It scans the contents of the commits for additional secrets.

This describes the ongoing process of secret scanning itself, not the specific action taken after a secret has been detected.

D. It sends a notification to repository members.

GitHub notifies repository administrators and the committer, not all repository members. More importantly, for public repositories, notifying the provider for revocation is the most crucial first step.

1. GitHub Docs, "About secret scanning."

Under the section "About secret scanning for public repositories," it states: "When secret scanning detects a secret in a public repository, we notify the service provider who issued the secret. The service provider validates the credential and then decides whether they should revoke the secret, issue a new secret, or reach out to you directly..." This directly supports the correct answer (A).

2. GitHub Docs, "Secret scanning partner program."

This document outlines the program's purpose: "We partner with service providers to protect our mutual users by scanning for their token formats... When a match is found in a public repository, we send the payload to the relevant partner." This confirms that notifying the service provider is the defined process.

3. GitHub Docs, "Managing alerts from secret scanning."

Under the section "Viewing alerts from secret scanning," it clarifies who can see alerts: "You can see all alerts for a repository in the repository's Security tab." It also details notification recipients, confirming alerts are not public and are sent to specific roles like administrators, which refutes options B and D.

A. rebase-strategy is an optional setting that specifies how Dependabot should handle conflicts when updating pull requests.

B. commit-message is an optional setting used to customize the prefix and content of commit messages for Dependabot updates.

C. assignees is an optional setting that allows you to automatically assign specific users or teams to the pull requests created by Dependabot.

1. GitHub Docs. "Configuration options for the dependabot.yml file." GitHub Docs, Accessed May 22, 2024. In the section "package-ecosystem," the documentation explicitly states, "Required. The package manager to use." It also lists rebase-strategy, commit-message, and assignees as optional settings.

A. Dismissing alerts based on age is a reactive and unsafe practice. An old, exposed secret can still be valid and exploitable, so each alert requires proper investigation and remediation, not arbitrary dismissal.

C. SCIM is an identity and access management (IAM) protocol for automating user provisioning. While a good security practice for managing user access, it does not directly address the issue of secrets being committed to code.

1. [Correct Option B] GitHub Docs, "Webhook events and payloads." Under the secretscanningalert event type, the documentation states this event is triggered "When a secret scanning alert is created, resolved, or reopened." This confirms that webhooks can be used to proactively monitor and build automated workflows for these alerts.

Source: GitHub Enterprise Cloud Documentation, Section: "Webhooks and events" > "Webhooks" > "Webhook events and payloads".

2. [Correct Option D] GitHub Docs, "Best practices for preventing data leaks in your organization." This guide emphasizes preventative measures, stating, "We recommend that you store secrets in a dedicated, secure location outside of your repository," and suggests using services like Azure Key Vault or GitHub secrets. Documenting these alternatives for developers is a core part of this best practice.

Source: GitHub Enterprise Cloud Documentation, Section: "Code security" > "Tools for code security" > "Best practices for preventing data leaks in your organization".

3. [Incorrect Option A] GitHub Docs, "Managing alerts from secret scanning." The documentation outlines the process for closing an alert, which requires providing a reason such as "Fixed," "False positive," or "Won't fix." It does not list age as a valid reason for dismissal, reinforcing that alerts must be triaged based on risk, not age.

Source: GitHub Enterprise Cloud Documentation, Section: "Code security" > "Secret scanning" > "Managing alerts from secret scanning".

4. [Incorrect Option C] GitHub Docs, "About SCIM for enterprises." The documentation clearly defines the purpose of SCIM: "If you use an identity provider (IdP) for identity and access management, you can configure SCIM to automatically create or suspend user accounts and grant access... when you make changes in the IdP." This confirms its role is in IAM, not in handling code-level secret alerts.

Source: GitHub Enterprise Cloud Documentation, Section: "Enterprise management" > "Managing identity and access for your enterprise" > "Managing identity and access with your identity provider" > "About SCIM for enterprises".

A. decryptsecret.sh is a filename. While you might exclude this file using paths-ignore:, it is not the YAML syntax itself.

C. branches-ignore: is a syntax used in other contexts like GitHub Actions workflows to exclude branches from triggers, not for configuring secret scanning file exclusions.

D. secret scanning.yml is the name of the configuration file where the exclusion syntax is placed, not the syntax element for excluding paths.

---

1. GitHub Docs. "Configuring secret scanning for your repositories." GitHub Enterprise Cloud Documentation. Accessed May 20, 2024.

Section: "Excluding directories from secret scanning"

Content: This official documentation explicitly states: "You can configure secret scanning for a repository by editing the /.github/secretscanning.yml file... Use paths-ignore to exclude specific directories from being scanned." It provides a clear YAML example:

yaml

paths-ignore:

- "lib/test/fixtures"

- "/testdata/.js"