18 real GH-500 sample questions, each with a worked explanation and a rationale for every option, right and wrong. No account, no card. This is the reasoning the GH-500 tests: knowing why the tempting answer is wrong, not just spotting the right one.
The real GH-500 is Approximately 75 questions in 90 minutes, pass mark 700 / 1000. For a domain-by-domain breakdown and a study plan, read the GH-500 study guide. The full bank has 292 questions.
lock_openFree sampleDescribe GitHub Security suites, features, and ecosystemmedium
A platform team is mapping out which GitHub Advanced Security capabilities belong to which licensable product so they can budget seats correctly. They need to place CodeQL-based code scanning and the alerts it raises under the correct product line. Which product does code scanning with CodeQL belong to?
- ACode Security, because code scanning with CodeQL performs static analysis to find vulnerabilities in the codebase.check_circle Correct
- BSecret Protection, because CodeQL inspects source files for sensitive strings before they are committed.
- CSupply Chain Security, because CodeQL evaluates the security of third-party dependencies pulled into the build.
- DSecurity Overview, because code scanning alerts are surfaced there for the whole organisation.
Place code scanning with CodeQL under the Code Security product within GitHub Advanced Security. GitHub Advanced Security is divided into product lines by the type of risk each addresses. Code scanning with CodeQL is static analysis of first-party source for vulnerabilities, which is the defining function of Code Security, distinct from credential detection (Secret Protection) and dependency risk (Supply Chain Security).
Why A is correct: Code scanning with CodeQL is the static application security testing capability, and GitHub packages it under the Code Security product. It analyses code paths for vulnerabilities such as injection flaws, which is exactly the Code Security remit.
Why B is wrong: This is tempting because both features analyse source code, but Secret Protection covers secret scanning and push protection for credentials, not static analysis of code logic. CodeQL does not look for committed credentials, so it is not part of Secret Protection.
Why C is 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 this product placement is wrong.
Why D is wrong: Security Overview is a reporting and navigation surface that aggregates alerts from multiple features; it is not a licensable product that owns code scanning. Seeing CodeQL alerts in Security Overview does not make code scanning part of it.
lock_openFree sampleDescribe GitHub Security suites, features, and ecosystemmedium
A security lead for an organisation wants a single place to see the count of open code scanning, secret scanning, and Dependabot alerts across every repository, broken down by repository and severity, without opening each repository in turn. Which part of the GitHub security suite is designed for this cross-repository view?
- AThe Security tab of one representative repository, which rolls up alerts from all sibling repositories in the organisation.
- BSecurity Overview at the organisation level, which aggregates alerts from all enabled features across repositories.check_circle Correct
- CThe Dependabot alerts page, which lists every alert type the organisation has enabled, grouped by repository.
- DThe organisation audit log, which records every alert as it is created and can be filtered by severity.
Use organisation-level Security Overview to view and filter alerts from all security features across repositories. Security Overview exists precisely to give security teams a consolidated, filterable picture of risk spanning many repositories and several alert types, which a single repository Security tab, a feature-specific alert page, or the audit log cannot provide because each is scoped narrowly.
Why A is wrong: A repository Security tab is scoped to that single repository only and does not aggregate sibling repositories. It is tempting because that tab does list all alert types, but only for the one repository it belongs to.
Why B is correct: Security Overview is the dashboard that consolidates code scanning, secret scanning, and Dependabot alerts across repositories, with filtering by repository and severity. It is the purpose-built cross-repository reporting surface in the suite.
Why C is wrong: The Dependabot alerts page shows only dependency vulnerability alerts; it does not include code scanning or secret scanning results. It is plausible because it spans repositories, but it covers a single feature, not all three.
Why D is wrong: The audit log records events such as setting changes and access actions, not a live, severity-ranked inventory of open security alerts. It is tempting as an org-wide view but is an event stream, not an alert dashboard.
lock_openFree sampleDescribe GitHub Security suites, features, and ecosystemmedium
During a procurement review, a team must distinguish what each GitHub Advanced Security product is responsible for. They specifically need the product whose job is to keep credentials such as API keys and tokens out of the codebase, both by detecting them and by blocking them at the point of a push. Which product fits that description?
- ASupply Chain Security, through Dependency Review blocking pull requests that introduce risky packages.
- BCode Security, through code scanning rules that flag hard-coded credentials as a vulnerability class.
- CSecret Protection, through secret scanning to detect exposed credentials and push protection to block them before they are committed.check_circle Correct
- DSecurity Overview, through its consolidated alert feed that quarantines any pushed secret automatically.
Identify Secret Protection as the product providing secret scanning detection and push protection prevention for credentials. Secret Protection groups the two credential-focused controls: secret scanning detects exposed tokens already present, and push protection prevents new secrets from entering the repository at push time. Neither dependency tooling, static code analysis, nor the reporting dashboard owns this credential-specific detection-plus-prevention pairing.
Why A is wrong: Dependency Review does block risky changes at pull request time, which makes this tempting, but it acts on vulnerable or malicious dependencies, not on committed credentials. Supply Chain Security does not detect secrets in source.
Why B is wrong: Code scanning can sometimes flag insecure patterns, so this seems plausible, but the dedicated detection and push-time blocking of credentials is the role of secret scanning and push protection, which sit in Secret Protection, not Code Security.
Why C is correct: Secret Protection is the product that bundles secret scanning, which detects credentials in the repository, with push protection, which blocks a push that contains a recognised secret. This matches both the detection and prevention requirements exactly.
Why D is wrong: Security Overview only reports and helps navigate alerts; it does not detect or block secrets and has no quarantine action. It is tempting because secret scanning alerts appear there, but reporting is not the same as the detection and prevention controls.
lock_openFree sampleConfigure and use Secret Protectionhard
A team lead is explaining why GitHub treats some secret scanning detections as high-confidence and prioritises them differently from generic pattern matches. They want to give two accurate reasons that genuinely set high-confidence secrets apart and justify prioritised handling. Which two statements correctly characterise high-confidence secrets? Select TWO.
- AThey are detected only after a repository is made public, because high-confidence detection is disabled while a repository remains private.
- BThey match patterns supplied by partner providers for their own token formats, which makes a positive match strongly indicative of a real credential.check_circle Correct
- CThey are the only secret type push protection can block, so any other detected pattern is reported but never prevented at push time.
- DBecause a match is highly likely to be a usable credential, they are suited to prioritised alerting and to validity checks against the provider.check_circle Correct
Identify that high-confidence secrets stem from partner-defined token patterns with low false positives, justifying prioritised alerting and validity checks. High-confidence secrets are matched using patterns that partner providers supply for their own token formats, so a hit is very likely a genuine credential rather than noise. That reliability is precisely what justifies prioritising these alerts and running validity checks against the provider, focusing responders on credentials most likely to be live, independent of whether the repository is public or whether other patterns can also be blocked.
Why A is wrong: Detection of these secrets is not gated on a repository becoming public; Secret Protection scans private repositories too. This confuses the historically free push protection on public repositories with the confidence level of a detection.
Why B is correct: High-confidence secrets correspond to partner-defined patterns for recognisable token formats, so a match is very likely a genuine credential rather than a coincidental string. That low false-positive rate is exactly why they are treated with high confidence.
Why C is wrong: Push protection blocks supported high-confidence patterns and can also act on enabled custom patterns configured for push protection, so high-confidence is not the sole blockable category. This wrongly treats the high-confidence set as the entire scope of prevention.
Why D is correct: The strong likelihood that a high-confidence match is a real, usable token is what makes prioritised alerting and provider validity checks worthwhile for these detections. Prioritising them focuses responders on the credentials most likely to be live and exploitable.
lock_openFree sampleConfigure and use Secret Protectionmedium
An open-source maintainer hosts a popular public repository on GitHub.com and has never purchased any paid security product for it. They want to confirm whether secret scanning will detect leaked tokens such as a published cloud provider key in that public repository at no extra cost. What is the correct position for a public repository under GitHub.com?
- ASecret scanning runs on the public repository only after the maintainer buys a "GitHub Advanced Security" or "Secret Protection" licence and assigns a seat.
- BSecret scanning is available free of charge for the public repository, so it can detect supported leaked credentials without any paid product.check_circle Correct
- CSecret scanning only ever runs on public repositories that belong to a paid organisation account, not on personal public repositories.
- DSecret scanning is unavailable for public repositories because exposed secrets there are treated as already public and beyond remediation.
Recognise that secret scanning is free for public repositories on GitHub.com whereas private and internal repositories need a paid Secret Protection licence. GitHub funds "secret scanning" for public repositories so that leaked credentials in open-source code are caught without cost, including partner notification for many provider tokens. The paid "Secret Protection" entitlement is what extends the same detection to private and internal repositories, which is why no purchase is required for the public case.
Why A is wrong: This is tempting because private and internal repositories do require a paid "Secret Protection" licence, but public repositories on GitHub.com receive secret scanning free of charge, so no purchase or seat assignment is needed.
Why B is correct: GitHub provides "secret scanning" for public repositories at no cost as part of the platform, so the maintainer can detect supported partner and provider secrets without buying "Secret Protection". This matches the free public-repository entitlement.
Why C is wrong: Account type is not the gate here. Free public-repository secret scanning applies regardless of whether the repository is owned by a personal account or an organisation, so restricting it to paid organisations is incorrect.
Why D is wrong: Public exposure makes detection more urgent, not pointless, and GitHub still scans and alerts on it. The premise that public secrets are beyond remediation is wrong, so this option misstates the behaviour.
lock_openFree sampleConfigure and use Secret Protectionmedium
An organisation owner has purchased "Secret Protection" and wants every repository created in the organisation from now on to have secret scanning switched on automatically, without an administrator visiting each new repository to enable it. Which organisation-level configuration achieves this for future repositories?
- AManually enabling secret scanning in each repository's settings, which GitHub then propagates as the organisation default for any later repository.
- BAdding secret scanning to a branch protection rule on the default branch, which forces the feature on for every repository that adopts the rule.
- CApplying a security configuration that enables secret scanning and setting it to automatically apply to newly created repositories in the organisation.check_circle Correct
- DEnabling the "automatically enable for new repositories" toggle in the organisation audit log so each creation event activates the feature.
Use a security configuration set to apply to new repositories so that secret scanning is enabled automatically across the organisation. Security configurations let an organisation define a reusable set of security feature settings, including "secret scanning", and choose to apply them automatically to repositories created later. This is why a configuration, rather than a per-repository toggle, a branch protection rule, or the audit log, is the correct way to default the feature on for future repositories.
Why A is wrong: Enabling a feature in one repository changes only that repository; GitHub does not promote a single repository's toggle into an organisation-wide default. This option confuses a per-repository action with an organisation policy.
Why B is wrong: Branch protection rules govern merges, reviews, and status checks on branches, not whether a security feature such as secret scanning is enabled. This conflates branch-level merge controls with feature enablement.
Why C is correct: A security configuration bundles feature settings such as secret scanning and can be set to apply automatically to new repositories, so each future repository inherits the enabled state without manual work. This is the intended organisation-level mechanism.
Why D is wrong: The audit log only records events and offers no toggle to enable features on creation. It is tempting because it is an organisation-wide surface, but it cannot apply security settings to repositories.
lock_openFree sampleConfigure and use supply chain securityhard
A platform team enables Dependabot alerts on a Node.js repository but deliberately leaves Dependabot security updates switched off, because they want to review every dependency bump before it lands. After a critical advisory is published for a direct dependency they are surprised that nothing changes in the codebase. Which TWO statements correctly describe the behaviour they should expect from this configuration? Select TWO.
- ADependabot raises an alert for the vulnerable dependency but does not open any pull request to upgrade it, because security updates are the feature that creates the remediation pull request.check_circle Correct
- BDependabot still requires the dependency graph to be enabled for the alert to appear, because alerts are matched against advisories using the resolved dependency data the graph produces.check_circle Correct
- CDependabot automatically opens a version update pull request for the package on its next scheduled run, since version updates cover security fixes when security updates are off.
- DDependabot blocks any further pushes to the default branch until the critical alert is dismissed, because critical-severity alerts gate the branch by default.
Separate Dependabot alerts, which only notify and depend on the dependency graph, from security updates, which open the remediation pull request. Dependabot alerts and Dependabot security updates are distinct: the alert uses dependency graph data matched against advisories to notify maintainers, while the security update is the feature that opens a pull request bumping the package to a patched version. With security updates off, a critical advisory yields an alert and no pull request, and version updates are an unrelated scheduled feature that does not act as a security fallback. Dependabot alerts also do not block pushes; merge gating belongs to Dependency Review.
Why A is correct: Alerts are notification-only; the pull request that bumps a package to the minimum non-vulnerable version is produced by Dependabot security updates, which the team chose not to enable, so an alert appears with no accompanying pull request.
Why B is correct: Dependabot alerts depend on the dependency graph to know which packages and versions a repository resolves; without the graph there is no dependency data to match against the GitHub Advisory Database, so the graph is a prerequisite for the alert.
Why C is wrong: This is tempting because both features open pull requests, but version updates are configured separately in a dependabot.yml schedule and are not a fallback that delivers security fixes when security updates are disabled.
Why D is wrong: Dependabot alerts never block pushes; gating a merge on dependency risk is the role of Dependency Review with a configured action, so a critical alert on its own has no branch-blocking effect.
lock_openFree sampleConfigure and use supply chain securityhard
A security engineer is prioritising a long backlog of open Dependabot alerts and decides to use the Exploit Prediction Scoring System (EPSS) score that GitHub surfaces alongside each alert. A colleague who is used to working only from CVSS severity asks how EPSS should change their triage. Which TWO statements about EPSS in this context are accurate? Select TWO.
- AA high EPSS score automatically raises the alert's GitHub severity to critical, so sorting by severity already incorporates the exploitation probability.
- BEPSS is a separate signal from CVSS severity, measuring likelihood of exploitation rather than the potential impact, so it complements rather than replaces the severity rating.check_circle Correct
- CEPSS estimates the probability that a vulnerability will be exploited in the wild in the near term, so two alerts with the same severity can be ordered by their differing exploitation likelihood.check_circle Correct
- DEPSS is a confirmed exploitation flag set only after GitHub observes the vulnerability being attacked in a customer repository, so any non-zero score means active compromise.
Use EPSS as a predictive exploitation-likelihood signal that complements, rather than replaces or rewrites, CVSS severity when prioritising Dependabot alerts. EPSS gives a probability that a vulnerability will be exploited in the wild within a short forward window, which is orthogonal to CVSS impact. GitHub surfaces it on Dependabot alerts so teams can rank same-severity findings by exploitation likelihood and combine the two dimensions. It does not change the advisory severity and is a forecast rather than evidence that a particular repository has been attacked.
Why A is wrong: This is tempting because both feel like risk numbers, but EPSS does not rewrite the advisory's severity; the severity comes from the advisory itself and EPSS is shown as a distinct field that the engineer must weigh separately.
Why B is correct: CVSS describes how damaging a flaw could be while EPSS describes how probable exploitation is, so the two answer different questions and are used together; a high-severity, low-EPSS alert and a moderate-severity, high-EPSS alert can both warrant attention for different reasons.
Why C is correct: EPSS produces a probability of exploitation over a short forward window, which is independent of severity, so it lets the engineer break ties between alerts that share a CVSS rating by favouring the one more likely to be attacked.
Why D is wrong: EPSS is a predictive probability published by an external model, not an observed-attack indicator, so a non-zero score reflects estimated likelihood rather than confirmation that any specific repository has been compromised.
lock_openFree sampleConfigure and use supply chain securityhard
An organisation owner wants Dependabot to stop cluttering the alert queue with low-impact findings whose vulnerable code is only used at build time, while still surfacing anything that could affect production. They are reviewing Dependabot auto-triage rules, including the GitHub-managed preset. Which TWO statements correctly describe how auto-dismiss behaviour through auto-triage rules works? Select TWO.
- AGitHub provides a managed auto-triage rule that auto-dismisses low-impact alerts for development-scoped dependencies, which the organisation can switch on without authoring the criteria themselves.check_circle Correct
- BCustom auto-triage rules can only dismiss alerts and cannot be configured to snooze them until a patched version is released, so any rule-based handling is permanent.
- CAn alert auto-dismissed by a rule is not deleted and is automatically reopened if it later becomes relevant, for example if its severity rises or the dependency moves into a runtime scope.check_circle Correct
- DEnabling auto-triage rules disables Dependabot security updates for the affected repositories, because GitHub will not open a pull request for an alert that a rule has touched.
Describe Dependabot auto-triage rules, including the managed development-scope preset and the reversibility of auto-dismissed alerts. Dependabot auto-triage rules let organisations filter the alert queue automatically. GitHub offers a managed preset that auto-dismisses low-impact alerts on development-scoped dependencies, and rules can snooze as well as dismiss. Auto-dismissal preserves the alert and reactivates it when relevance changes, so a finding that becomes production-affecting reappears. The rules do not disable security updates, which continue to open remediation pull requests for alerts left open.
Why A is correct: GitHub ships a preset auto-triage rule that targets low-impact alerts on development-scoped dependencies, so the organisation can adopt this behaviour by enabling the managed rule rather than building matching logic from scratch.
Why B is wrong: This is tempting because dismissal is the headline action, but auto-triage rules also support snoozing an alert until a patch is available, so rule-based handling is not limited to permanent dismissal.
Why C is correct: Auto-dismissal hides the alert rather than discarding it, and Dependabot reactivates a dismissed alert when conditions change so that a finding that becomes production-relevant returns to the open queue for triage.
Why D is wrong: Auto-triage rules govern how alerts are filtered and do not turn off security updates; an alert left open by the rules can still receive a security update pull request, so the two features operate independently.
lock_openFree sampleSecurity operations: best practices, prioritization, and remediationhard
An organisation owner is configuring Dependabot auto-triage rules so that low-impact alerts are dismissed automatically and the team only sees alerts that warrant action. Which TWO statements about Dependabot auto-triage rules are correct? Select TWO.
- AGitHub provides a preset auto-dismiss rule that automatically dismisses alerts for vulnerabilities in development-scope dependencies that are not reachable in runtime, and it can be paused per repository.check_circle Correct
- BA custom auto-triage rule can match alerts by criteria such as severity, ecosystem, scope, and CWE, and the matching action can dismiss the alert or snooze it until the dependency is patched.check_circle Correct
- CAuto-triage rules apply equally to code scanning, secret scanning, and Dependabot alerts, so one rule can dismiss low-severity findings across all three alert types at once.
- DWhen an auto-triage rule dismisses an alert, the dismissal is permanent and Dependabot will not reopen it even if later evidence shows the dependency is reachable and exploitable.
Know that Dependabot auto-triage rules act only on Dependabot alerts, offer a managed dismissal preset, and support custom criteria with dismiss or snooze actions. Dependabot auto-triage rules operate solely on Dependabot alerts. GitHub provides a managed preset that auto-dismisses low-impact development-dependency alerts and can be paused per repository, and owners can add custom rules that match on severity, ecosystem, scope, or CWE and then dismiss or snooze alerts until a patch lands. They never extend to code scanning or secret scanning, and auto-dismissals can resurface if conditions change, so they cut noise without hiding genuine risk permanently.
Why A is correct: GitHub ships a managed preset that auto-dismisses certain low-impact development-dependency alerts and can be enabled or paused at the repository level. This matches the goal of suppressing noise from dependencies that do not affect production while keeping owners in control per repository.
Why B is correct: Custom auto-triage rules let an owner filter Dependabot alerts on attributes like severity, package ecosystem, manifest scope, and CWE, then choose to dismiss matching alerts or snooze them until a patch is available. That is precisely how teams tune which alerts are auto-handled versus surfaced for action.
Why C is wrong: Auto-triage rules are a Dependabot alerts feature and do not govern code scanning or secret scanning alerts, which use their own triage and dismissal mechanisms. The idea of a single cross-feature rule is appealing for scale, but no such unified rule exists, so this statement is wrong.
Why D is wrong: Alerts auto-dismissed by a rule are not closed forever; if the situation changes so the alert no longer matches the dismissal criteria, it can resurface for review. Treating auto-dismissal as irreversible misrepresents the feature, which is designed to reduce noise without permanently hiding risk.
lock_openFree sampleSecurity operations: best practices, prioritization, and remediationmedium
A security engineer is triaging a Dependabot alert and wants to understand the weakness category behind the vulnerability so the team can search for the same coding mistake elsewhere in their own first-party code. The GitHub Advisory Database entry lists a CVE identifier, a CWE, and a CVSS score. Which of these is designed to classify the underlying type of software weakness rather than to identify a specific reported instance or rate its severity?
- AThe CVE identifier, because it groups together every vulnerability that shares the same root cause across all affected products.
- BThe CVSS score, because its base, temporal, and environmental metrics together decompose the flaw into the weakness category that produced it.
- CThe CVE identifier, because each CVE is issued per weakness type so that one CVE maps to exactly one CWE category.
- DThe CWE, because it names the general class of software weakness, such as improper input neutralisation, that the specific vulnerability is an instance of.check_circle Correct
Distinguish CWE as the weakness-type classification from CVE as a specific vulnerability identifier and CVSS as a severity rating. CWE is the Common Weakness Enumeration, a catalogue of weakness categories such as improper input neutralisation or use of hard-coded credentials. It abstracts the kind of mistake so engineers can find recurrences of the same pattern. A CVE identifies one specific publicly disclosed vulnerability in a product, and CVSS provides a severity score from exploitability and impact metrics. Only CWE classifies the underlying type of weakness, which is what supports searching first-party code for the same flaw.
Why A is wrong: This is tempting because a CVE is the most prominent identifier on the advisory, but a CVE names one specific publicly disclosed vulnerability in a particular product, not a reusable category of weakness shared across products.
Why B is wrong: CVSS base metrics describe exploitability and impact characteristics to produce a severity number; they rate how serious a flaw is and never classify the type of weakness behind it.
Why C is wrong: A CVE is issued per disclosed vulnerability, not per weakness type, and a single advisory can map a CVE to one or more CWEs, so the CVE is not the categorising framework here.
Why D is correct: CWE (Common Weakness Enumeration) is a hierarchy of weakness types, so it gives the engineer a category like SQL injection or path traversal that they can use to hunt for the same flaw pattern across their own code.
lock_openFree sampleSecurity operations: best practices, prioritization, and remediationmedium
A maintainer has fixed a vulnerability privately in their open-source project and now wants the fix to feed GitHub's vulnerability detection so that downstream consumers of the package start receiving Dependabot alerts. They are working from a repository security advisory they drafted during the embargo. After they publish that advisory, what is the primary mechanism by which downstream repositories begin to be alerted?
- APublishing the advisory adds it to the GitHub Advisory Database, where Dependabot matches it against the resolved dependency versions in downstream dependency graphs to raise alerts.check_circle Correct
- BPublishing the advisory triggers GitHub to push a security update pull request directly into every downstream repository that depends on the package.
- CPublishing the advisory emails the security contacts of every downstream repository, which is what creates the alert in those repositories.
- DPublishing the advisory immediately yanks the vulnerable package versions from the registry so downstream builds fail until they upgrade, which surfaces the issue.
Explain that a published GitHub Security Advisory enters the Advisory Database and drives Dependabot alerts by matching the dependency graph. When a maintainer publishes a repository security advisory, GitHub reviews and curates it into the GitHub Advisory Database with the affected ecosystem and version ranges. Dependabot then matches database advisories against the resolved packages and versions recorded in each repository's dependency graph, raising an alert wherever a vulnerable version is in use. Publication does not push pull requests into other repositories, remove packages from registries, or rely on email to create alerts.
Why A is correct: A published repository security advisory is reviewed into the GitHub Advisory Database, and Dependabot compares those advisories against each repository's dependency graph data, so downstream consumers on affected versions receive alerts.
Why B is wrong: This is tempting because remediation pull requests are a real feature, but GitHub does not push fixes into other people's repositories on publication; each downstream repository only gets a security update pull request if it has Dependabot security updates enabled for itself.
Why C is wrong: Notifications may reach maintainers of affected repositories, but the alert itself is created by matching the advisory against the dependency graph, not by an email, so email is a side effect rather than the alerting mechanism.
Why D is wrong: GitHub advisories do not remove or yank packages from external registries; the advisory records affected version ranges and powers alerting, while yanking a release is a separate action only the package owner can take on the registry.
lock_openFree sampleConfigure and use Code Securitymedium
A team already runs a third-party static analysis tool in their continuous integration pipeline and wants its findings to appear as code scanning alerts in the repository Security tab, displayed inline on the relevant lines of changed files in pull requests. The tool can export its results in a standard format. Which approach makes those third-party findings appear as native code scanning alerts?
- AOpen the third-party tool's JSON report as a workflow artifact so GitHub parses it into the code scanning alerts list automatically.
- BAdd the third-party tool to the default CodeQL configuration so CodeQL re-runs the tool and converts its output to alerts.
- CPost the tool's results to the repository using the check runs API, which surfaces them on the Security tab as code scanning alerts.
- DHave the tool produce a SARIF file and upload it to code scanning using the upload-sarif action or the SARIF upload API.check_circle Correct
Recognise that third-party tool findings become native code scanning alerts only by uploading SARIF via the upload-sarif action or SARIF API. Code scanning is engine-agnostic at the data layer: it stores and manages alerts described in the SARIF format regardless of which tool produced them. Delivering a tool's results as SARIF through the upload-sarif action or the SARIF upload API is what creates managed alerts that appear in the Security tab and as pull request annotations, which is not achievable with artifacts, the CodeQL configuration, or generic check runs.
Why A is wrong: Uploading a report as a workflow artifact merely stores a file for download; GitHub does not parse arbitrary artifacts into alerts. Code scanning only ingests results delivered specifically as SARIF through the upload mechanism, so an artifact alone produces no alerts.
Why B is wrong: Default setup runs CodeQL queries only and cannot invoke or wrap an unrelated third-party scanner. CodeQL does not convert another tool's output, so this conflates the CodeQL engine with the generic SARIF ingestion path.
Why C is wrong: The check runs API can annotate a commit or pull request with check output, but those annotations are not code scanning alerts and do not populate the Security tab's code scanning list. Only SARIF ingestion creates managed code scanning alerts.
Why D is correct: Code scanning ingests results in the SARIF format, so exporting the tool's findings as SARIF and uploading them with the upload-sarif action or the code scanning SARIF API turns them into native alerts that appear in the Security tab and inline in pull requests. This is the supported interoperability path for third-party tools.
lock_openFree sampleConfigure and use Code Securitymedium
A monorepo is analysed by two scanners: CodeQL for application code and a separate infrastructure-as-code scanner. Both upload SARIF for the same commit, but the second upload appears to overwrite the first so only one tool's alerts remain visible. What SARIF upload practice keeps both sets of results as distinct, co-existing code scanning alerts?
- AGive each tool's upload a distinct category value so code scanning tracks the two analyses separately for that commit and ref.check_circle Correct
- BUpload both SARIF files in a single combined run so code scanning merges the two tools into one result set.
- CSchedule the two scanners on different days so their uploads never target the same commit and cannot collide.
- DSet a unique runAutomationDetails id on each tool's check run so the Security tab keeps them on separate pages.
Use a distinct SARIF category per tool so multiple analyses for the same commit and ref are tracked and displayed separately. Code scanning treats an analysis as the tuple of tool, ref, and category. When two tools share the same effective category, a fresh upload from one is interpreted as updating the same analysis and supersedes the other. Supplying a unique category for each scanner lets code scanning keep the analyses independent so both tools' alerts remain on the same commit.
Why A is correct: Code scanning identifies an analysis by the combination of tool, ref, and the category supplied at upload. Assigning each scanner a unique category means a new upload only refreshes the matching analysis, so both tools' alerts persist side by side instead of one overwriting the other.
Why B is wrong: Combining unrelated tools into one upload does not preserve their separation and is not how code scanning distinguishes analyses. It is tempting as a way to keep everything together, but without distinct categories one analysis still replaces the other.
Why C is wrong: Staggering schedules avoids same-commit uploads but defeats the goal of having both tools' current results on the latest commit. It is a workaround that sacrifices coverage rather than the supported way to keep concurrent analyses distinct.
Why D is wrong: While SARIF does carry automation details, code scanning keys analyses on the upload category rather than on a hand-set check run page, and the example wrongly ties this to check runs. Relying on a check run id instead of a category does not stop one analysis replacing another.
lock_openFree sampleConfigure and use Code Securitymedium
An organisation is deciding when CodeQL is the appropriate engine versus when a third-party analysis tool integrated through SARIF is the better fit. They write Go, TypeScript, and a large body of COBOL, and they want deep dataflow detection of injection and authentication flaws in the languages where it is supported. What is the most accurate basis for choosing between CodeQL and a third-party tool here?
- ACodeQL should be used for every language because its dataflow analysis is available for all programming languages once code scanning is enabled.
- BCodeQL should cover the languages it supports for deep dataflow detection, and a third-party tool uploaded as SARIF should cover the languages CodeQL does not support.check_circle Correct
- CA third-party tool should be used for every language because SARIF ingestion always produces richer alerts than CodeQL's native analysis.
- DThe engines are interchangeable, so the team should pick whichever scanner their pipeline already runs and apply it uniformly to all three languages.
Select CodeQL for its supported languages and a SARIF-integrated third-party tool for languages CodeQL does not cover. Engine choice is driven by language support and the depth of analysis required, not by a blanket preference. CodeQL provides deep dataflow analysis only for the languages it supports, so a third-party tool uploaded as SARIF is the appropriate complement for an unsupported language such as COBOL, letting both engines contribute alerts to the same code scanning view.
Why A is wrong: CodeQL supports a defined set of languages and does not analyse every language, so this overstates its coverage. It is tempting because CodeQL is the default engine, but unsupported languages still need another approach.
Why B is correct: The choice turns on language support and analysis depth. CodeQL gives strong dataflow detection for its supported languages such as Go and TypeScript, while a SARIF-integrated third-party tool fills coverage for a language like COBOL that CodeQL does not analyse, so the two are complementary rather than mutually exclusive.
Why C is wrong: SARIF only standardises how results are delivered and says nothing about analysis depth; it does not make a third-party tool inherently richer than CodeQL. Discarding CodeQL where it is strong sacrifices its deep dataflow detection.
Why D is wrong: Treating the engines as interchangeable ignores that each supports different languages and offers different analysis depth. Applying one scanner uniformly will either leave a CodeQL-unsupported language uncovered or forgo CodeQL's dataflow strength where it applies.
lock_openFree sampleGitHub Security suites administrationhard
A security lead is configuring the bypass list on an organisation ruleset that enforces required code scanning and pull request review. They want a named incident-response team to be able to push directly to protected branches during an outage, and they want individual senior engineers to retain that ability only while acting through a pull request, not on direct pushes. Which bypass list configurations support these goals? Select TWO.
- AAdd the incident-response team to the bypass list with the bypass mode set to always, so the team can bypass the rules on both direct pushes and pull requests.check_circle Correct
- BAdd the senior engineers to the bypass list with the bypass mode set to pull requests only, so they can bypass the rules only when merging through a pull request.check_circle Correct
- CGrant the incident-response team write access to the repositories, since the bypass list automatically includes anyone with write permission during a declared incident.
- DSet the ruleset enforcement status to evaluate for the senior engineers only, so the rules are reported but not enforced against that group.
Configure ruleset bypass entries using bypass modes (always versus pull requests only) to scope exemptions to the right actors and contexts. Ruleset bypass entries name a role, team, or app and attach a bypass mode. The always mode exempts the actor in all contexts including direct pushes, while the pull-request-only mode restricts the exemption to merges performed through a pull request. Enforcement status is ruleset-wide and write access never confers bypass, so only the two explicit bypass entries meet the stated goals.
Why A is correct: Adding a team with the always bypass mode lets its members skip the rules in every context, including direct pushes to a protected branch, which is exactly what an incident-response team needs during an outage.
Why B is correct: The pull-request-only bypass mode limits the exemption to merges made via a pull request and does not grant a direct-push exemption, matching the requirement to let senior engineers bypass only through pull requests.
Why C is wrong: Write access lets a user push normal commits but does not place them on a ruleset bypass list, and there is no automatic incident-based inclusion. Bypass permission must be configured explicitly on the ruleset rather than inferred from a permission level.
Why D is wrong: Enforcement status is a property of the whole ruleset, not a per-user setting, so it cannot single out a group. Evaluate would also stop blocking everyone, not just the senior engineers, which is not what the lead wants.
lock_openFree sampleGitHub Security suites administrationmedium
An enterprise owner on GitHub Enterprise Cloud wants one named baseline that enables secret scanning with push protection and code scanning, and wants it offered to every organisation in the enterprise so each organisation owner can apply it without rebuilding it. The owner does not want to log in to each organisation to recreate the same settings. Which mechanism lets the owner author the baseline once at the enterprise tier and make it available to the organisations beneath it?
- ACreate the security configuration inside each organisation, then export and import the JSON between organisations so the settings stay identical across the enterprise.
- BDefine a repository ruleset at the enterprise tier that turns on secret scanning and code scanning whenever a branch matching the ruleset receives a push.
- CAssign the security manager role at the enterprise tier so the holders inherit a standard set of enabled features across all member organisations automatically.
- DCreate an enterprise-level security configuration, which the enterprise owner authors once and which then becomes available for organisation owners to apply to their repositories.check_circle Correct
Recognise that an enterprise-level security configuration is authored once and made available for organisations to apply. Security configurations can be defined at the enterprise tier so the enterprise owner authors the baseline of features such as secret scanning with push protection and code scanning a single time. That configuration then becomes available to the organisations in the enterprise, where organisation owners apply it to repositories without recreating the settings.
Why A is wrong: There is no export-import flow for security configurations, and this still requires touching every organisation, which is exactly what the owner wants to avoid. It is tempting because copying config-as-code feels scalable, but it is not how the feature distributes baselines.
Why B is wrong: Rulesets govern branch and tag protections such as required checks and restricted pushes; they do not enable security features. The plausibility is that rulesets exist at enterprise scope, but they enforce branch rules rather than provision the scanning suite.
Why C is wrong: The security manager role grants permission to view and manage security settings and alerts; it does not bundle or push a feature baseline. Granting access is not the same as authoring and distributing a configuration, so this confuses a role with a configuration.
Why D is correct: Enterprise-level security configurations let an enterprise owner define a reusable baseline at the top tier that flows down to the organisations, where organisation owners can apply it. This matches authoring once and offering it downward without recreating settings per organisation.
lock_openFree sampleGitHub Security suites administrationmedium
A platform team administers a GitHub Enterprise Server instance and has purchased a GitHub Advanced Security entitlement. They want secret scanning and code scanning to become available to administrators of the repositories on the instance. Before any organisation or repository setting can turn these features on, what must a site administrator do at the instance level?
- AEnable GitHub Advanced Security for the instance through the management console settings, after which organisations and repositories can turn the features on.check_circle Correct
- BAdd a dependabot.yml file to the instance configuration directory so the server registers the GitHub Advanced Security entitlement for every repository at once.
- COpen a support ticket so GitHub remotely activates the features against the instance, because GitHub Enterprise Server cannot self-enable GitHub Advanced Security.
- DAssign a GitHub Advanced Security seat to each developer in the management console, after which the features appear automatically in every repository.
Know that GitHub Advanced Security on GitHub Enterprise Server is enabled at the instance level by a site administrator before lower scopes can use it. GitHub Enterprise Server is self-managed, so the entitlement is activated by a site administrator enabling GitHub Advanced Security for the whole instance in the management console. That instance-level step is the prerequisite that makes secret scanning and code scanning selectable at organisation and repository scope.
Why A is correct: On GitHub Enterprise Server a site administrator enables GitHub Advanced Security at the instance level via the management console before any lower scope can use it. Only once it is enabled on the instance can organisation and repository administrators turn secret scanning and code scanning on.
Why B is wrong: A dependabot.yml configures Dependabot version updates for a single repository and has nothing to do with enabling GitHub Advanced Security on an instance. It is tempting as a config-as-code idea, but it is the wrong file at the wrong scope.
Why C is wrong: GitHub Enterprise Server is self-managed and the site administrator enables GitHub Advanced Security themselves; no ticket is required to flip the feature on. The plausibility comes from licensing involving GitHub, but activation of the feature is a local administrative action.
Why D is wrong: Per-user seat assignment is the GitHub Enterprise Cloud billing model, not how a server instance is switched on. Seat language is a real concept elsewhere, which makes it tempting, but the server prerequisite is enabling the feature on the instance, not assigning seats.
Examworthy is not affiliated with or endorsed by GitHub. All questions are original, blueprint-aligned practice material. We never reproduce live exam items. GH-500 and related marks belong to their respective owners.
