ExamworthyExamworthy
Open the appStart free

GH-500 - GitHub Security suites administration - 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.

More in this domain

Back to all GitHub Security suites administration objectives, or the GH-500 cert hub.

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