Objectives in this domain

Enable GitHub Security suites at the enterprise, organization, and repository levels, and understand feature differences across GitHub Enterprise Cloud and GitHub Enterprise Server.
Section 6.1medium
Define default security configurations and inheritance behaviour to enable Code Security, Secret Protection, and Supply Chain Security across repositories.
Section 6.2hard
Define enterprise and organization security policies and rulesets, configure enforcement boundaries, bypass permissions, exceptions, and security roles.
Section 6.3hard
Enable and configure default or approved custom CodeQL workflows, and use APIs and automation for large-scale security configuration and governance.
Section 6.4hard

Sample question from this domain

Free 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. 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.

Other domains in this exam

Describe GitHub Security suites, features, and ecosystem18% of the exam
Configure and use Secret Protection18% of the exam
Configure and use supply chain security18% of the exam
Configure and use Code Security14% of the exam
Security operations: best practices, prioritization, and remediation18% of the exam

See also the GH-500 cert hub, the study guide, and the cheat sheet.