Examworthyexamworthy.comGitHub Advanced Security (GH-500) cheat sheet
GitHub
Free to share. Examworthy is not affiliated with or endorsed by GitHub; GH-500 and related marks belong to their respective owners.
At a glance
Format: Multiple choice and multiple response, online proctored
Domain weight map
Heaviest first - spend your time hereHow this exam thinks
GH-500 is a configure-the-right-control exam: nearly every question is a scenario where the answer is the documented GitHub Advanced Security feature, enabled at the correct repository, organisation, or enterprise scope, that prevents the problem early rather than remediating it late.
Spot the trap
Tempting wrong answers, and why they failTempting but wrong
CodeQL belongs to Secret Protection because it scans source files for sensitive strings before they are committed.
Why it fails
Wrong. Secret Protection covers secret scanning and push protection for credentials. CodeQL performs static analysis of code logic for vulnerabilities; it does not hunt for committed credentials, so it sits in Code Security, not Secret Protection.
Describe GitHub Security suites, features, and ecosystem
Tempting but wrong
Secret scanning runs on a public repository only after the maintainer buys a Secret Protection or GitHub Advanced Security licence and assigns a seat.
Why it fails
A paid licence and seat are required only for private and internal repositories. Public repositories on GitHub.com receive secret scanning free of charge, so no purchase or seat assignment is needed for them.
Configure and use Secret Protection
Tempting but wrong
The dependency graph only reads lock files and ignores manifests, so a repository with no committed lock file has an empty dependency graph.
Why it fails
The graph does parse supported manifests such as package.json, which is why direct dependencies still appear without a lock file. A missing lock file only prevents resolving the exact pinned transitive versions; it does not leave the graph empty.
Configure and use supply chain security
Tempting but wrong
A CVE identifier groups together every vulnerability sharing the same root cause across all affected products.
Why it fails
A CVE names one specific publicly disclosed vulnerability in a particular product, not a reusable category of weakness shared across products. The framework that groups flaws by shared root cause or type is CWE, not CVE.
Security operations: best practices, prioritization, and remediation
Tempting but wrong
Storing a tool's JSON report as a workflow artifact lets GitHub parse it into the code scanning alerts list automatically.
Why it fails
A workflow artifact is just a stored file for download; GitHub does not parse arbitrary artifacts into alerts. Code scanning only ingests results delivered specifically as SARIF through the upload-sarif action or SARIF API, so an artifact alone produces no alerts.
Configure and use Code Security
Tempting but wrong
You can keep security configurations identical across an enterprise by exporting and importing the JSON between organisations.
Why it fails
There is no export-import flow for security configurations, and recreating them in every organisation is exactly the per-organisation work to avoid. Distribution happens by authoring an enterprise-level security configuration that flows down, not by copying config files.
GitHub Security suites administration
Tempting but wrong
CodeQL belongs to Supply Chain Security because it evaluates the security of third-party dependencies pulled into the build.
Why it fails
Wrong. Supply Chain Security covers the dependency graph, Dependabot, and dependency review, which assess third-party components. CodeQL analyses first-party source code rather than declared dependencies, so it belongs to Code Security.
Describe GitHub Security suites, features, and ecosystem
Tempting but wrong
Secret scanning runs on public repositories only when they belong to a paid organisation account, not on personal public repositories.
Why it fails
Account type is not the gate. Free public-repository secret scanning applies whether the repository is owned by a personal account or an organisation, so it is wrong to restrict it to paid organisations.
Configure and use Secret Protection
Key terms
Exam-day rules
- Read the scenario for its requirement first. The security need named in the question, paired with the scope it concerns, is what picks the answer, so find both before you judge the options.
- Prefer the documented, built-in mechanism. When an option describes a supported GitHub feature and another describes a hand-rolled workaround such as re-pushing files or parsing artifacts, the supported feature is almost always the answer.
- Choose prevention over cleanup. Push protection at push time, dependency review before merge, and a CodeQL pull request scan beat after-the-fact remediation when the scenario allows catching the problem early.
- Match the enablement scope exactly. Decide whether the action belongs at repository, organisation, or enterprise level, and remember a default security configuration only covers repositories created after it is set, so existing ones need bulk attachment.
- Map every feature to its product. Code scanning with CodeQL is Code Security, secret scanning and push protection are Secret Protection, and dependency review and Dependabot are supply chain features; licensing questions hinge on this split.
Revision schedule
- Day 1Map the blueprint and book a date
- Week 1Build the product and scope maps
- Weeks 1 to 2Go deep on Secret Protection and supply chain security
- Weeks 2 to 3Lock Code Security and the CodeQL model
- Weeks 3 to 4Cover security operations and remediation at scale