GitHub GH-500 Sample Questions with Explanations

These original sample questions are designed to help you check how the exam topics appear in decision-style prompts. They are not taken from the live exam.

Use these sample questions as a guided self-assessment for GitHub Advanced Security (GH-500) topics such as secret scanning, code scanning, CodeQL, dependency review, Dependabot alerts, workflow security, security policies, and alert triage. The prompts focus on reducing software risk without turning scanning tools into checkbox activity.

Where these questions fit in the GH-500 guide

The sample set below is part of the GitHub Advanced Security GH-500 guide path:

• GitHub certification hub
• GH-500 exam guide
• GH-500 cheat sheet
• GH-500 study plan
• GH-500 FAQ
• GH-500 resources
• GH-500 glossary

GH-500 secure development sample questions

Work through each prompt before opening the explanation. Strong answers usually combine the right detection feature with ownership, triage, and remediation workflow.

---

Question 1

Topic: Responding to a leaked token alert

Secret scanning raises an alert for a cloud token committed to a private repository. The developer deletes the line and closes the pull request. What is the strongest next action?

• A. Close the alert immediately because the pull request no longer contains the token.
• B. Revoke or rotate the token, confirm whether it was used, and keep the alert workflow tied to documented remediation.
• C. Make the repository public so more reviewers can look for the token.
• D. Move the token into another branch and merge the branch later.

Best answer: B

Explanation: Secret exposure is a credential-risk problem, not just a code-diff problem. The key must be invalidated or rotated, possible usage should be checked, and the alert should remain part of the remediation record.

Why the other choices are weaker:

• A treats source removal as sufficient even though the credential may already be compromised.
• C expands exposure and does not remediate the token.
• D keeps the secret in version control.

What this tests: Secret scanning response, credential rotation, alert ownership, and remediation evidence.

Related topics: Secret scanning; Credential rotation; Alert triage; Remediation

---

Question 2

Topic: Customizing code scanning

A security team uses code scanning but repeatedly misses a risky in-house API pattern. The pattern is specific to the company’s framework and is not flagged by the default rules. What is the best improvement?

• A. Disable code scanning because default rules do not catch every framework-specific issue.
• B. Ask developers to manually search the whole repository before every commit.
• C. Create or enable a custom CodeQL query or query pack that detects the organization-specific risky pattern.
• D. Treat dependency review alerts as a replacement for source-code analysis.

Best answer: C

Explanation: Code scanning can be tuned with CodeQL queries so an organization can detect patterns that matter to its codebase. The important decision is adapting scanning to real risk, not abandoning automation.

Why the other choices are weaker:

• A removes a useful detection layer instead of extending it.
• B is not repeatable or enforceable at scale.
• D covers package risk, not custom source-code patterns.

What this tests: Code scanning customization, CodeQL, default rules versus custom risk, and scalable detection.

Related topics: Code scanning; CodeQL; Custom queries; Secure coding

---

Question 3

Topic: Reviewing dependency risk in a pull request

A pull request adds a new package version. The team wants reviewers to see whether the dependency introduces known vulnerabilities or license concerns before merge. Which feature is the closest fit?

• A. Repository topics, because they classify the project for search.
• B. GitHub Pages, because it publishes the package list publicly.
• C. Issue templates, because they force every pull request to describe dependencies.
• D. Dependency review on the pull request, combined with repository security policy and alert triage.

Best answer: D

Explanation: Dependency review is designed to surface dependency changes and risk in the pull request review flow. It supports decision-making before the vulnerable or policy-breaking dependency is merged.

Why the other choices are weaker:

• A helps repository discovery, not dependency risk review.
• B publishes content and may create exposure without improving review controls.
• C documents intent but does not inspect dependency metadata automatically.

What this tests: Dependency review, pull request gates, vulnerability awareness, and policy-driven review.

Related topics: Dependency review; Vulnerabilities; Pull requests; Policy

Independent study note

Tech Exam Lexicon and IT Mastery are independent study tools. They are not affiliated with, endorsed by, or sponsored by GitHub or any certification body.