GH-500 · Domain 6: GitHub Security suites administration · 13% of the exam
Task 6.2: Configure security features and defaults
Security configurations, defaults for new repositories, enforcement and what repositories inherit from global settings.
Study it
Security configurations, defaults, enforcement and global settings
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the GitHub documentation page that proves it.
Question 1 · choose 1
An organization's custom security configuration is set as the default for all new repositories. After an acquisition, 25 repositories are transferred into the organization, and none of them has the configuration's features. What should the owner do?
AApply the configuration to the 25 transferred repositories from the Repositories tab
BRe-save the configuration as the default, which reapplies it to every repository
CWait a day for the nightly sync that applies defaults to transferred repositories
DRecreate the 25 repositories as new ones and push their history again
Show the answer and why
AApply the configuration to the 25 transferred repositories from the Repositories tab
Correct
Transferred repositories need the configuration applied manually.
BRe-save the configuration as the default, which reapplies it to every repository
Incorrect
Setting a default affects newly created repositories only.
CWait a day for the nightly sync that applies defaults to transferred repositories
Incorrect
Defaults never reach transferred repositories automatically.
DRecreate the 25 repositories as new ones and push their history again
Incorrect
That works around the rule at a high cost; applying the configuration is enough.
The default security configuration for an organization is only applied automatically to new repositories created in the organization. If a repository is transferred into the organization, you still need to apply an appropriate configuration manually, for example by filtering the repository table and applying it.
An enforced custom security configuration enables push protection and code scanning default setup, and leaves validity checks not set. A repository administrator in an attached repository turns validity checks off. What happens?
AThe change is blocked: enforced configurations lock every setting in the repository
BThe change is allowed, and the repository's status changes to failed
CThe change detaches the repository from the configuration automatically
DThe change is allowed: the configuration doesn't set validity checks
Show the answer and why
AThe change is blocked: enforced configurations lock every setting in the repository
Incorrect
Enforcement covers only the features the configuration sets.
BThe change is allowed, and the repository's status changes to failed
Incorrect
Changing an unset feature doesn't fail the attachment.
CThe change detaches the repository from the configuration automatically
Incorrect
Changing an unset feature doesn't detach anything.
DThe change is allowed: the configuration doesn't set validity checks
Correct
Features that aren't set aren't enforced.
Enforcing a configuration blocks repository owners from changing features that are enabled or disabled by the configuration, but features that are not set aren't enforced. Here push protection and default setup are locked, while validity checks remain the repository's choice.
What happens to a repository's security settings when it is detached from its configuration?
AThey stay as they are, now managed at repository level
BThey are reset to off
CThey switch to the enterprise defaults
DThey are deleted with the configuration
Show the answer and why
AThey stay as they are, now managed at repository level
Correct
Detaching keeps the existing settings.
BThey are reset to off
Incorrect
Detaching doesn't change them.
CThey switch to the enterprise defaults
Incorrect
No defaults are applied.
DThey are deleted with the configuration
Incorrect
The configuration isn't deleted.
Detaching a repository from a security configuration doesn't change its existing enablement settings; the repository shows "No configuration" and is managed individually from then on.
Why does applying a security configuration also apply it to archived repositories?
ATo restore archived repositories automatically
BSome features, such as secret scanning, run there
CArchived repositories need extra licenses
DArchived repositories can't be filtered out of the repository table
Show the answer and why
ATo restore archived repositories automatically
Incorrect
Applying doesn't unarchive them.
BSome features, such as secret scanning, run there
Correct
Secret scanning runs on archived repositories, and coverage stays in place if they are unarchived.
CArchived repositories need extra licenses
Incorrect
That isn't the reason.
DArchived repositories can't be filtered out of the repository table
Incorrect
The reason is coverage, not filtering.
A configuration is applied to both active and archived repositories because some features, for example secret scanning, run on archived repositories, and an unarchived repository is then already protected.
An organization applies an enforced security configuration that enables code scanning default setup. Weeks later one repository has no code scanning, although nobody changed the configuration. Which situation explains this?
AThe repository has no CodeQL workflow file in .github/workflows
BAll of its pull requests come from forks
CIts administrator turned push protection off for the repository
DGitHub Actions was later disabled in that repository
Show the answer and why
AThe repository has no CodeQL workflow file in .github/workflows
Incorrect
Default setup creates its own configuration; it doesn't need a workflow file in the repository.
BAll of its pull requests come from forks
Incorrect
Default setup also scans pushes to the default branch and protected branches.
CIts administrator turned push protection off for the repository
Incorrect
Push protection is a secret scanning control and doesn't affect code scanning.
DGitHub Actions was later disabled in that repository
Correct
Actions being enabled at first and then disabled in a repository is one of the situations that break enforcement of code scanning.
Some situations break the enforcement of security configurations. Code scanning enablement doesn't apply to a repository if GitHub Actions is enabled at first and later disabled in the repository, if the actions that code scanning needs aren't available there, or if the definition of which languages default setup shouldn't analyze is changed.