GH-500 - GitHub Security suites administration (14% of the exam) - Section 6.2

Define default security configurations and inheritance behaviour to enable Code Security, Secret Protection, and Supply Chain Security across repositories.

Define default security configurations at the enterprise or organisation level and understand how inheritance propagates settings to new and existing repositories. Configure global settings to ensure Code Security, Secret Protection, and Supply Chain Security are consistently enabled without requiring per-repository manual setup.

security configurationsdefault configurationinheritanceglobal settings

Practice question for this objective

Free sampleGitHub Security suites administrationhard

An organisation applied a custom security configuration to a group of private repositories, enabling secret scanning with push protection and code scanning default setup. The platform team now wants to manage those particular repositories' security settings individually at the repository level, so they detach the configuration from that group. Assuming no one changes the repositories afterwards, what is the state of the previously enabled features on those repositories immediately after detaching?

ASecret scanning, push protection, and code scanning are switched off on those repositories, because detaching removes every setting the configuration had turned on and returns each repository to its pre-configuration state.
BSecret scanning and push protection stay enabled but code scanning default setup is disabled, because default setup can only persist while a configuration that defines it remains attached to the repository.
CAll three features are placed into an enforced read-only state on those repositories, so repository administrators can view them but cannot change them until the configuration is reattached.
DSecret scanning, push protection, and code scanning remain enabled with their current settings, but the repositories are no longer associated with the configuration and are now managed individually. Correct

Detaching a security configuration from repositories preserves their enabled security settings and only ends the managed relationship, moving control to the repository level. Detaching does not alter the existing security enablement state of a repository; it removes the association with the configuration so the settings persist but are now managed individually rather than centrally through the configuration.

Why A is wrong: This is tempting because detaching sounds like an undo, but detaching only ends the managed relationship; it does not roll back the enabled settings, so the features are not switched off.

Why B is wrong: This invents a special case for code scanning; default setup does not depend on a live configuration link to keep running, so it is not singled out and disabled on detach.

Why C is wrong: This confuses detaching with enforcement; enforcement is what locks settings while a configuration is attached, whereas detaching ends the relationship and leaves the settings fully editable at repository level.

Why D is correct: Correct: detaching preserves the existing security enablement settings on each repository and only severs the link to the configuration, so the features stay on while management moves to the repository level.

See more GH-500 practice questions, answers explained.

Exam traps in GitHub Security suites administration

Answers that look right on this material and are not. Each one is a distractor from a different question in the GH-500 bank for this domain.

Nothing further is required, because setting a security configuration as the default retroactively attaches it to every repository in the organisation, including ones created before the configuration existed.
Why it is wrong: This is the tempting assumption that 'default' means 'all', but the default only governs repositories created from that point onward; pre-existing repositories are left untouched until the configuration is explicitly applied to them.
Default setup replaces the advanced setup workflow automatically, and the committed CodeQL workflow is disabled; the team must delete the configuration to keep their advanced setup.
Why it is wrong: This is tempting because default setup can take precedence in some flows, but applying a configuration does not silently delete a repository's committed advanced setup, so it is not the described outcome.
The transfer stripped the configuration during migration, so the lead must wait for the next nightly reconciliation job to reapply the organisation default automatically.
Why it is wrong: This is tempting because transfers can drop settings, but there is no nightly job that reapplies the default to transferred repositories, so waiting will not enable the features.

Examworthy is not affiliated with or endorsed by GitHub. Original, blueprint-aligned practice material only.