Browse Certification Practice Tests by Exam Family

GitHub Advanced Security GH-500: GHAS Features

Try 10 focused GitHub Advanced Security GH-500 questions on GHAS Features, with explanations, then continue with IT Mastery.

On this page

Open the matching IT Mastery practice page for timed mocks, topic drills, progress tracking, explanations, and full practice.

Try GitHub Advanced Security GH-500 on Web View full GitHub Advanced Security GH-500 practice page

Topic snapshot

FieldDetail
Exam routeGitHub Advanced Security GH-500
Topic areaDescribe the GHAS Security Features and Functionality
Blueprint weight15%
Page purposeFocused sample questions before returning to mixed practice

How to use this topic drill

Use this page to isolate Describe the GHAS Security Features and Functionality for GitHub Advanced Security GH-500. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.

PassWhat to doWhat to record
First attemptAnswer without checking the explanation first.The fact, rule, calculation, or judgment point that controlled your answer.
ReviewRead the explanation even when you were correct.Why the best answer is stronger than the closest distractor.
RepairRepeat only missed or uncertain items after a short break.The pattern behind misses, not the answer letter.
TransferReturn to mixed practice once the topic feels stable.Whether the same skill holds up when the topic is no longer obvious.

Blueprint context: 15% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.

Sample questions

These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.

Question 1

Topic: Describe the GHAS Security Features and Functionality

A code scanning alert is opened in the private repository payments-api. During triage, the AppSec lead asks whether this repo is typical or whether other repositories in the organization have not yet adopted GHAS features such as code scanning and secret scanning. The organization manages 250 private repositories. What is the best next action?

Options:

  • A. Inspect each repository’s dependency graph settings manually.

  • B. Use Security Overview to review which repositories have GHAS features enabled.

  • C. Sort repositories by open alert count and treat zero alerts as missing GHAS.

  • D. Re-run CodeQL in every repository to discover adopted protections.

Best answer: B

Explanation: Security Overview is the centralized GHAS view for tracking adoption across repositories. When the goal is to see which repositories have enabled protections, it is better than inferring from alert counts or checking repositories one at a time.

The key concept is organization-level visibility. A single code scanning alert shows that one repository has a finding, but it does not show whether other repositories have adopted GHAS features. Security Overview helps security teams track feature adoption across repositories, so it is the right place to identify which repositories have code scanning, secret scanning, or other GHAS protections enabled or missing.

Inferring adoption from open alerts is unreliable because a repository can have GHAS enabled and still show no current findings. Re-running CodeQL or manually checking repository settings is slower and does not provide the same centralized adoption view. For rollout planning and gap identification, Security Overview is the best investigation step.

  • Alert count shortcut fails because zero alerts does not mean a repository lacks GHAS; it may simply have no active findings.
  • Re-running CodeQL tests analysis execution, but it is not the primary tool for measuring organization-wide feature adoption.
  • Checking dependency graph settings is too narrow and manual for tracking overall GHAS adoption across many repositories.

Question 2

Topic: Describe the GHAS Security Features and Functionality

A private repository on GitHub Enterprise Cloud already has GitHub Advanced Security enabled. The security team wants one native configuration that:

  • blocks exposed credentials before they enter the repository when possible
  • finds insecure code patterns during pull request review
  • detects vulnerable third-party packages and proposes fixes when available

Which configuration best meets these requirements?

Options:

  • A. Enable secret scanning with push protection, code scanning on pull requests and the default branch, and Dependabot alerts with security updates.

  • B. Enable secret scanning alerts after commits, code scanning on a weekly schedule only, and Dependabot alerts with security updates.

  • C. Enable secret scanning with push protection, code scanning on pull requests, and manual package review instead of Dependabot alerts.

  • D. Enable code scanning to detect leaked credentials, secret scanning alerts for vulnerable packages, and Dependabot security updates for custom code weaknesses.

Best answer: A

Explanation: The best choice uses each GHAS feature for the risk it is designed to address. Secret scanning with push protection helps prevent secret exposure before push, code scanning checks code for security weaknesses during review, and Dependabot handles vulnerable dependencies and can open update pull requests.

Secret scanning, code scanning, and Dependabot protect different parts of the software supply chain and development workflow. Secret scanning with push protection is the preventive control for supported secrets, because it can stop the secret before it is pushed. Code scanning is for finding security issues in the code itself, so running it on pull requests helps reviewers catch weaknesses before merge and running it on the default branch keeps the main line monitored. Dependabot works from dependency metadata and security advisories to identify vulnerable packages, raise alerts, and create security update pull requests when a safe version is available. Together, these features cover leaked credentials, insecure code, and vulnerable dependencies across prevention, review, and remediation.

  • Secret scanning alerts after a commit and weekly-only code scanning leave gaps in both pre-push prevention and pull request-time detection.
  • The option that swaps feature purposes is incorrect because code scanning is not for leaked secrets, and secret scanning is not for dependency vulnerabilities.
  • Manual package review does not provide Dependabot’s continuous advisory-based detection or automated security update pull requests.

Question 3

Topic: Describe the GHAS Security Features and Functionality

Your GitHub Enterprise Cloud organization has GHAS enabled for a private payments monorepo. During one sprint, security found three different problems:

  • a developer attempted to push a placeholder cloud token that secret scanning would detect
  • a pull request updated a library to a version with a known CVE
  • a pull request introduced an unsafe data flow that CodeQL can detect

The team wants GitHub to catch these issues as early as possible in the developer workflow instead of relying on one manual review after merge. What is the best security action?

Options:

  • A. Enable only Dependabot alerts and security updates.

  • B. Enable only secret scanning with push protection.

  • C. Enable only CodeQL code scanning on pull requests.

  • D. Combine push protection, dependency review, and CodeQL pull request scanning.

Best answer: D

Explanation: The scenario includes three different problem types: exposed secrets, vulnerable dependency changes, and insecure code paths. No single GHAS feature covers all of them, so the best response is a layered workflow that uses the right control for each risk.

GHAS features have different scopes. Push protection addresses secret exposure before a secret is committed to the repository history. Dependency review helps evaluate dependency changes in pull requests so a vulnerable package version can be identified before merge. Code scanning with CodeQL analyzes source code for insecure patterns such as injection or unsafe data flows.

Because the repository is facing all three risks, treating this as one generic security review leaves gaps. A single-feature choice would only cover one part of the problem. The strongest approach is to combine the GHAS capabilities that match each risk and surface them during normal pull request and push workflows.

  • Secrets only helps stop exposed credentials but does not evaluate vulnerable package updates or unsafe code paths.
  • Dependency only addresses package risk, but it does not prevent secret leaks or analyze source code flows.
  • Code only can detect code flaws in pull requests, but it is not the primary control for secret pushes or vulnerable dependency changes.

Question 4

Topic: Describe the GHAS Security Features and Functionality

An AppSec team supports 150 repositories in one GitHub organization. A new repository ruleset requires dependency review and code scanning checks before pull requests can merge to main. During weekly remediation planning, the team needs one view to compare repositories, find the largest backlog of open Dependabot and code scanning alerts, and spot repositories that still need GHAS attention without opening each repository separately. What should they use first?

Options:

  • A. Review the organization’s Security Overview

  • B. Review the main branch protection settings

  • C. Review recent CodeQL workflow run logs

  • D. Review the Security tab in each repository

Best answer: A

Explanation: Security Overview is the best fit when a team needs to compare security posture across many repositories. It centralizes alert and coverage information so remediation can be prioritized without checking each repository individually.

Security Overview is intended for organization- or enterprise-level visibility. In this scenario, the AppSec team needs to compare many repositories, identify where alert volume is highest, and see which repositories still need security follow-up after workflow controls were introduced. That is exactly when Security Overview is more appropriate than a single repository Security tab.

A repository Security tab is useful after the team knows which repository to investigate in detail. Branch protection and repository rulesets show what merge controls are enforced, and CodeQL workflow logs show details about a specific scan run, but neither provides a consolidated cross-repository posture view. When the need is broad triage across repositories, start with Security Overview.

  • Per-repo focus The repository Security tab is useful for detailed investigation, but it is not the most efficient first view for organization-wide comparison.
  • Policy view only Branch protection settings explain required checks on a branch, not the backlog of alerts across repositories.
  • Run-level detail CodeQL workflow logs help troubleshoot individual analysis runs, not summarize overall security posture across the organization.

Question 5

Topic: Describe the GHAS Security Features and Functionality

An organization uses a repository ruleset that requires pull requests into main. The AppSec team is reviewing Security Overview to decide which repository to address first this sprint. They want the repository where unresolved risk is already high and GHAS coverage is too weak to help catch future issues before merge.

RepositoryInternet-facingUnresolved high/critical alertsCode scanningDependency review on PRsPush protection
payments-apiYes5OffOffOff
hr-portalNo2OnOnOn
docs-siteYes0OffOffOff
shared-sdkNo0OnOnOn

Which repository should be prioritized first?

Options:

  • A. shared-sdk

  • B. payments-api

  • C. hr-portal

  • D. docs-site

Best answer: B

Explanation: Security Overview is most useful when you combine alert volume with enablement gaps. payments-api stands out because it is internet-facing, already has unresolved high/critical alerts, and lacks code scanning, dependency review, and push protection on the protected PR workflow.

The key Security Overview decision is not just “which repo has alerts” or “which repo lacks features.” It is which repository has the strongest combination of current unresolved risk and weak GHAS coverage. Here, payments-api has both: multiple high/critical alerts and no code scanning, no dependency review on pull requests, and no push protection. That means the team has immediate exposure and limited prevention on future changes, even though pull requests to main are required.

Security Overview helps teams prioritize by looking across repositories for patterns such as:

  • open alert severity
  • missing GHAS feature enablement
  • repository exposure, such as internet-facing services
  • whether existing workflow controls can actually block risky changes

A repository with no unresolved alerts but weak coverage is still important to improve, but it is usually a rollout target after the repo with both active risk and poor coverage.

  • The option for hr-portal is less urgent because it has fewer high/critical alerts and its PR workflow already includes key GHAS checks.
  • The option for docs-site is a coverage gap, but there are no unresolved high/critical alerts to triage first.
  • The option for shared-sdk is the lowest priority here because it has no unresolved high/critical alerts and GHAS controls are already enabled.

Question 6

Topic: Describe the GHAS Security Features and Functionality

Your team protects main with a repository ruleset that requires security checks to pass before a pull request can merge. AppSec wants to stop pull requests that introduce a library version with a known published vulnerability. Which GitHub Advanced Security feature best fits this requirement?

Options:

  • A. Run CodeQL code scanning on pull requests

  • B. Add a SECURITY.md policy file

  • C. Require dependency review on pull requests

  • D. Enable secret scanning push protection

Best answer: C

Explanation: This scenario is about a vulnerable third-party package entering through a pull request. In GHAS, that risk maps to dependency management, with dependency review providing the PR-focused control that can support merge protection.

GitHub Advanced Security features map to different risk types. Secret scanning detects exposed credentials and tokens. Code scanning, including CodeQL, analyzes your source code for insecure patterns, data-flow issues, and other coding weaknesses. Dependency management covers risks from third-party packages, such as known vulnerable versions referenced by security advisories.

When the goal is to prevent a pull request from merging because it adds a vulnerable dependency, dependency review is the best fit. It evaluates dependency changes in the PR and works naturally with required checks and repository rulesets. Dependabot alerts and security updates also belong to dependency management, but dependency review is the control designed for this pull-request gate.

The key distinction is that the risk is in the dependency version, not in leaked secrets or custom application code.

  • Secret scanning mismatch detects exposed secrets such as tokens or keys, not vulnerable package versions.
  • Code scanning mismatch finds weaknesses in code logic or data flow, not whether a dependency version has a known CVE.
  • Policy-only control helps define reporting and response expectations, but it does not detect or block vulnerable dependencies in a pull request.

Question 7

Topic: Describe the GHAS Security Features and Functionality

An organization uses GitHub Advanced Security on private repositories. Security Overview shows several material-risk alerts that need both application context and security risk judgment before remediation timelines are set. The company wants repository teams to keep ownership of code changes, while a central AppSec team needs cross-repository alert visibility and triage capability without broad administrative rights. Which configuration best meets these requirements?

Options:

  • A. Assign the AppSec team as organization security managers and keep repository maintainers responsible for fix PRs.

  • B. Grant all developers read access to all repositories so any team can review and dismiss material-risk alerts.

  • C. Limit GHAS alert access to repository maintainers and require manual escalation of serious findings to security.

  • D. Make the AppSec team organization owners so they can directly administer every repository and alert.

Best answer: A

Explanation: Material-risk GHAS alerts often require two perspectives: developers understand code context and safe remediation, while security evaluates organizational risk and prioritization. Using organization security managers gives the AppSec team the visibility they need without over-privileging them, and repository maintainers still own the code changes.

The key concept is balancing shared alert response with least privilege. For material-risk GHAS alerts, development teams provide application context, test impact, and implement the fix. Security teams provide broader risk assessment, prioritization, and governance across repositories.

Assigning the central AppSec team as organization security managers is the best fit because it gives them cross-repository access to security alerts and triage workflows without requiring full organization ownership. Repository maintainers and code owners should still review, test, and merge remediation changes because they understand the codebase and release constraints.

Making security full organization owners grants unnecessary administrative power, while relying only on repository teams or broadening access to all developers weakens consistent governance and least-privilege access.

  • Org owner access is excessive because alert visibility and triage do not require full administrative control of the organization.
  • Maintainers-only triage fails because manual escalation can delay or miss the separate security judgment needed for material risk.
  • All developers everywhere violates least privilege and makes alert dismissal and oversight harder to govern consistently.

Question 8

Topic: Describe the GHAS Security Features and Functionality

Your organization uses GitHub Advanced Security across 140 private repositories. The AppSec lead is asked to report, by the end of the day, which repositories owned by the Payments team have open high-severity Dependabot or code scanning alerts and which of those repositories do not have secret scanning enabled.

What is the best security action?

Options:

  • A. Review the dependency graph for each Payments repository

  • B. Run a new CodeQL analysis on all Payments repositories

  • C. Use organization-level Security Overview and filter to the Payments repositories

  • D. Open the Security tab in each Payments repository and compare results manually

Best answer: C

Explanation: Security Overview is the best choice when the need spans multiple repositories and includes both alert status and feature coverage. A single repository Security tab is useful for repo-level investigation, but it is not the efficient view for organization-wide triage or reporting.

The core concept is scope. Security Overview is intended for organization or enterprise security visibility across repositories, so it is the right place to answer questions like “which repos have open alerts?” and “which repos are missing a security feature?” in one workflow. In this scenario, the AppSec lead needs a same-day view across all Payments repositories and across multiple GHAS signal types, not a deep dive into one repository.

Security Overview helps by letting teams:

  • review security posture across many repositories
  • filter by repository set or ownership context
  • compare alert counts and severities
  • see feature enablement coverage such as secret scanning

Checking individual repository Security tabs is slower and does not provide the same cross-repository reporting view. The dependency graph and CodeQL analysis each solve narrower problems than the one described.

  • Manual repo review is possible, but it is inefficient when the request is to compare many repositories quickly.
  • Dependency graph only helps with dependency inventory, not combined alert and feature-coverage reporting.
  • Run CodeQL again may produce code scanning results, but it does not answer the broader cross-repository visibility need.

Question 9

Topic: Describe the GHAS Security Features and Functionality

A fintech organization uses GitHub Enterprise Cloud for a private monorepo. A security review found these gaps:

  • developers occasionally commit API credentials
  • pull requests can add packages with known vulnerabilities
  • insecure coding patterns are often discovered only during late manual testing

The team wants GHAS controls built into the developer workflow, with prevention or review feedback before code reaches the default branch when possible and alerts for existing issues afterward. Which action is the best fit?

Options:

  • A. Enable dependency graph and SBOM export, and review pull requests for leaked secrets.

  • B. Enable secret scanning and Dependabot security updates, and use manual code review for insecure code.

  • C. Enable code scanning with CodeQL and third-party SARIF uploads, and rely on branch protection for dependency risk.

  • D. Enable secret scanning with push protection, dependency review with Dependabot alerts, and code scanning with CodeQL.

Best answer: D

Explanation: The gaps involve three different GHAS problem areas: secrets, dependencies, and code vulnerabilities. The best fit is the combination of secret scanning with push protection, dependency review with Dependabot alerts, and code scanning with CodeQL because it adds prevention and feedback directly into normal development workflows.

GHAS works best as a layered secure-SDLC toolset rather than a single control. In this scenario, leaked credentials are addressed by secret scanning plus push protection, which can stop likely secrets before they are pushed and still alert on exposed secrets already in the repository. Vulnerable package risk is addressed by dependency review on pull requests so risky dependency changes are surfaced before merge, while Dependabot alerts identify known vulnerable dependencies already present. Insecure code patterns are a code scanning problem, so CodeQL is the native GHAS choice to analyze code in pull requests and branches for security issues. Visibility features such as SBOMs and inventory data are useful, but they do not replace preventive secret controls, dependency change analysis, or code scanning.

  • Dependabot security updates can help remediate known vulnerable packages, but this choice misses dependency review for pull requests and does not use GHAS code scanning for insecure code.
  • Adding SARIF alongside CodeQL focuses on code scanning only; branch protection by itself does not detect leaked secrets or analyze dependency vulnerability risk.
  • Dependency graph and SBOM export improve visibility, but they do not detect committed secrets or perform security analysis on source code.

Question 10

Topic: Describe the GHAS Security Features and Functionality

A GitHub Enterprise Cloud organization uses GHAS with a central AppSec team. In a private shared-library repository, a Dependabot alert appears for package acme-parser. Security Overview shows the same alert in 37 repositories. The alert is critical, no patched version is available, and Dependabot cannot create a security update pull request. Repository maintainers can view the alert, but the central AppSec team owns organization-wide risk decisions. What is the best security action?

Options:

  • A. Dismiss the alert because no patched version exists

  • B. Wait for Dependabot to generate a security update pull request

  • C. Disable Dependabot alerts for the shared library

  • D. Escalate the alert to the central AppSec team and document temporary mitigation

Best answer: D

Explanation: This alert should be escalated because it affects many repositories, has no available fix, and the central AppSec team owns cross-repository response. A missing patch is not evidence for dismissal, and waiting for automation is not appropriate when Dependabot cannot create an update pull request.

Escalation is the right response when an alert has broad organizational impact and the repository team cannot fully remediate it on their own. In this scenario, Security Overview shows the same critical Dependabot alert across many repositories, no patched version exists, and Dependabot cannot open a security update pull request. That means the issue needs coordinated ownership for temporary mitigation, risk communication, and follow-up until a fix becomes available.

Dismissal should be reserved for cases with evidence that the alert is not applicable, such as a documented false positive or unreachable dependency path. When a safe upgrade exists and the impact is local to one repository, direct remediation is usually preferred. Here, the combination of org-wide scope and no current fix makes escalation the best action.

  • No patch available is not a valid reason to dismiss a Dependabot alert; dismissal needs evidence that the alert does not apply.
  • Waiting for automation fails because Dependabot cannot create a security update pull request when no fixed version is available.
  • Turning off alerts hides ongoing risk instead of supporting coordinated triage and mitigation.

Continue with full practice

Use the GitHub Advanced Security GH-500 Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try GitHub Advanced Security GH-500 on Web View GitHub Advanced Security GH-500 Practice Test

Free review resource

Read the GitHub Advanced Security GH-500 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.

Revised on Thursday, May 14, 2026