Free GH-500 practice questions

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

A developer working in a brand new public repository on GitHub.com, with no paid security product purchased, tries to push a commit that contains a recognised cloud provider access key. They have not visited any security settings. What behaviour should they expect when they run the push?

• AThe push is blocked by push protection, which is enabled by default for public repositories, and the developer is prompted to remove the secret or justify the bypass.check_circle Correct
• BThe push completes normally, and push protection becomes active only after a "Secret Protection" licence is bought and assigned to the repository.
• CThe push completes, but the developer is emailed afterwards and asked to rotate the key, since prevention is unavailable on public repositories.
• DThe push is rejected automatically until the developer is forced to delete the repository and recreate it without the secret in history.

Why A is correct: GitHub enables push protection by default for pushes to public repositories, so a recognised secret in the commit is blocked at push time and the developer must remove it or provide a bypass reason. This matches the default public-repository behaviour.

Why B is wrong: Buying a licence is the requirement for private and internal repositories, not public ones. For public repositories push protection is available without a paid product, so attributing the gate to licensing is incorrect here.

Why C is wrong: Detection on public repositories does generate alerts, which makes after-the-fact notification plausible, but push protection can also block the push beforehand on public repositories, so claiming prevention is unavailable understates the behaviour.

Why D is wrong: Push protection blocks the offending push and lets the developer remove or bypass the secret, but it never forces deletion and recreation of the whole repository. This overstates the consequence well beyond what the feature does.

A security engineer enables the dependency graph on a private repository and expects to see the project's npm packages listed. The repository checks in package.json but the team has chosen never to commit package-lock.json. They observe that the dependency graph shows the direct dependencies declared in the manifest but does not resolve the full set of transitive dependencies and pinned versions. Which explanation best accounts for what the dependency graph can and cannot show here?

• AThe dependency graph only ever reads lock files and ignores manifests entirely, so a repository with no committed lock file produces an empty dependency graph regardless of any manifest present.
• BThe dependency graph parses the manifest to list declared direct dependencies, but without a committed lock file it cannot determine the exact resolved versions of the transitive dependency tree.check_circle Correct
• CThe dependency graph requires the repository to run a build so it can capture dependencies at compile time, and the missing tree is simply because no Actions build has executed yet.
• DThe dependency graph is disabled for private repositories, so the partial listing must be coming from a cached public mirror rather than from the repository itself.

Why A is wrong: This overstates the limitation. The graph does parse supported manifests such as package.json, which is why the direct dependencies are visible at all, so the claim that the graph is empty without a lock file contradicts the observed result.

Why B is correct: The dependency graph reads supported manifest and lock files in the repository. A manifest such as package.json declares direct dependencies and version ranges, but the resolved transitive tree and pinned versions live in the lock file, so omitting package-lock.json leaves the graph unable to enumerate the full pinned dependency set.

Why C is wrong: The dependency graph is built by statically reading manifest and lock files in the repository, not by executing a build. Tying resolution to a compile-time capture confuses the graph with runtime instrumentation that it does not perform.

Why D is wrong: The dependency graph can be enabled on private repositories, and the engineer explicitly enabled it, so attributing the listing to a public mirror is wrong. The partial view is a lock-file question, not a private-repository restriction.

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.

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.

A compliance officer must hand an auditor a machine-readable inventory of the open-source components in a repository, in a widely recognised standard format produced directly by GitHub without writing a custom script. They open the dependency graph and look for an export option. Which export does GitHub provide for this, and in what format is it generated?

• AA vulnerability report exported from the dependency graph in CSV format, listing each component alongside its known advisories.
• BA license inventory exported from the dependency graph in plain Markdown, summarising each dependency's declared licence for the audit.
• CAn SBOM exported from the dependency graph in SPDX JSON format, listing the components GitHub has detected for the repository.check_circle Correct
• DAn SBOM exported from the dependency graph in CycloneDX XML format, which is the only Bill of Materials format GitHub can generate.

Why A is wrong: The dependency graph export produces a component inventory, not a vulnerability report, and the standard SBOM format is SPDX rather than an ad hoc CSV. Bundling advisories into the export confuses the dependency graph SBOM with Dependabot alert data.

Why B is wrong: While licence information can appear alongside dependencies, the dedicated export is an SBOM in SPDX JSON, not a Markdown licence summary. A Markdown document is also not the machine-readable standard format the auditor requires.

Why C is correct: GitHub can export a Software Bill of Materials from the dependency graph in the SPDX JSON format, which is an open, widely recognised standard. This gives the auditor a machine-readable component inventory drawn directly from the detected dependencies without any custom scripting.

Why D is wrong: The dependency graph SBOM export is generated in SPDX, not CycloneDX, so naming CycloneDX XML as the format and the only option is incorrect. CycloneDX is a real standard but not the one this export produces.

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.

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.

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

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.

A team is reviewing a code scanning alert raised by CodeQL. The alert references a CWE in its classification but has no CVE attached. A developer argues the alert must be invalid because real vulnerabilities always carry a CVE. What is the most accurate explanation of why this CodeQL alert has a CWE but no CVE?

• AThe missing CVE means CodeQL failed to fully analyse the dataflow, so the alert is a partial result that should be dismissed as a false positive.
• BCodeQL alerts are tagged with the CWE weakness category they detect, while a CVE is assigned only when a vulnerability in a released product is publicly disclosed, which a first-party finding need not be.check_circle Correct
• CCodeQL only assigns a CVE once the alert severity reaches critical, so this alert simply has not crossed the threshold that mints an identifier.
• DA CWE without a CVE indicates the finding is in a dependency rather than first-party code, since dependency issues carry only weakness categories.

Why A is wrong: This is tempting because incomplete analysis can occur, but the absence of a CVE says nothing about analysis completeness; it reflects that no public vulnerability identifier applies to a first-party source finding.

Why B is correct: CodeQL classifies findings by the weakness pattern using CWE, but a CVE is reserved for a publicly disclosed vulnerability in a product or package, so an as-yet-undisclosed flaw in the team's own code legitimately has a CWE and no CVE.

Why C is wrong: Severity does not mint a CVE, and CodeQL does not issue CVEs at all; CVE identifiers come from CVE Numbering Authorities for disclosed vulnerabilities, independent of any alert's severity.

Why D is wrong: This inverts the reality: dependency vulnerabilities surfaced through the Advisory Database typically do carry CVEs, whereas CodeQL alerts on first-party source are the ones that commonly have a CWE but no CVE.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

An organisation owner on GitHub Enterprise Cloud applies a security configuration as the default for the organisation. The configuration enables secret scanning with push protection and code scanning. A week later a developer creates a brand new private repository in that organisation and does not touch any security settings. What is the expected outcome for the new repository?

• AThe configuration applies only to repositories that existed when it was set as the default, so the new repository starts with all security features off.
• BThe default security configuration attaches to the new repository on creation, so secret scanning with push protection and code scanning are enabled without manual action.check_circle Correct
• CThe configuration attaches but stays in a pending state until an organisation owner manually confirms it for each new repository in Security Overview.
• DThe configuration is ignored because private repositories require a GitHub Advanced Security seat to be assigned to the creating developer before any features apply.

Why A is wrong: This inverts the purpose of a default, which is precisely to cover repositories created afterwards. It is tempting because a one-time apply to existing repositories is also possible, but choosing it as the default is what captures new repositories.

Why B is correct: Setting a security configuration as the organisation default means it automatically attaches to newly created repositories, applying its enabled features. The new private repository therefore inherits secret scanning with push protection and code scanning without the developer doing anything.

Why C is wrong: There is no per-repository confirmation step for a default configuration; attachment and application happen on creation. The idea of a review queue sounds like a sensible control, but it is not how default configurations behave.

Why D is wrong: Applying a configuration that enables licensed features is what consumes entitlement; there is no separate per-developer seat gate that blocks the default from attaching. The licensing reference is plausible, but it does not stop the default from applying on creation.