Domain review: privacy, security and administration

Rosa Delgado led the session on Wednesday, April 21, as she had promised. Privacy, security and administration carries 10 to 15 in 100 of the exam, and Owen had studied most of it in depth in March. His dots were on Enterprise Managed Users and on Copilot policy, both added to the outline in January 2026, and on the difference between internal and private repositories. "The exam asks what these controls are for and who uses them," Rosa said. "You already set half of them up with me." The session covered securing accounts with two-factor authentication and passkeys, permissions and roles, Enterprise Managed Users, Copilot policy, repository visibility and branch protection, and organization settings and teams.

Securing accounts: 2FA and passkeys

Two-factor authentication, 2FA, requires a second proof of identity in addition to a password. GitHub supports an authenticator app that generates time-based codes, security keys and passkeys, GitHub Mobile as a second factor, and text messages in some regions, which are the least secure option. GitHub requires 2FA for everyone who contributes code on GitHub.com, and organization owners can require 2FA for all members, outside collaborators and billing managers; anyone without it is removed from the organization until they enable it. Every account should save its recovery codes somewhere safe, because they are the way back in if the second factor is lost.

A passkey is a modern credential based on public-key cryptography, stored on a device or in a password manager and unlocked with a fingerprint, face or device PIN. It resists phishing, because it works only on the real GitHub site, and it can replace both the password and the second factor for signing in. On GitHub, a passkey can be used to sign in without a password and also counts as a second factor. Security keys are physical devices that work the same way. The exam outline names passkeys explicitly, so expect a question on why they are stronger than codes: they cannot be typed into a fake site.

Other credentials

Signing in through the browser is only one way to reach GitHub. Git on the command line and other tools authenticate with personal access tokens or SSH keys. A fine-grained personal access token is limited to chosen repositories and permissions and has an expiry date, which makes it far safer than a classic token, whose scopes are broad. Organizations can require approval for fine-grained tokens and can block classic tokens altogether. An SSH key pair lets a computer push and pull without typing a password; the private key stays on the computer and the public key is added to the account. Tokens and keys should be named for what they are used for, given the shortest sensible lifetime, and revoked when no longer needed, and GitHub lists every one in the account settings so this is easy to review.

Permissions and roles

Permissions and roles

MSBA-161 covered roles in depth; the exam expects you to recognize them and choose correctly. Organization roles are owner, member, and specialist roles such as billing manager, moderator, security manager and GitHub App manager; outside collaborators have access only to the repositories they are given. Repository roles are, from least to most, Read, Triage, Write, Maintain and Admin. A person's effective role is the highest they receive from any source: the organization's base permission, their teams or a direct grant. The principle of least privilege says to give the lowest role that lets someone do their job.

Enterprise Managed Users

Normally, people use their own personal accounts to join organizations, and they keep those accounts when they leave. Enterprise Managed Users, EMUs, is an option for GitHub Enterprise Cloud in which the company creates and controls the accounts itself. User accounts are created and removed from the company's identity provider, such as Microsoft Entra ID or Okta, through SCIM provisioning; people sign in with single sign-on; their usernames and profile details come from the company; and managed users cannot create public content or collaborate outside the enterprise, for example by opening issues on other public repositories. The trade-off is control against openness: EMUs suit companies that must own every identity and keep all work inside, and do not suit open source contribution with the same account.

Copilot policy for organizations

When an organization or enterprise buys Copilot Business or Enterprise, owners decide who gets a seat and set policies that apply to every seat. Policies cover which features are enabled, such as Copilot in the IDE, on GitHub.com, in the CLI, the coding agent or preview features; which AI models are available; whether suggestions matching public code are allowed or blocked; and content exclusions, which keep chosen files or repositories out of Copilot's context. In an enterprise, enterprise owners can set a policy for all organizations or let each organization decide. Usage is visible in Copilot metrics and audit logs. The exam asks what can be controlled centrally and at which level, rather than where each switch is.

Repository visibility

Repositories have three possible visibilities. Public repositories can be seen by anyone on the internet, although only people with access can push. Private repositories can be seen only by people who have been given access, directly or through teams. Internal repositories exist only for organizations in an enterprise: every member of the enterprise can see them, but no one outside it can, which supports inner source. Changing visibility is an Admin action in the danger zone, and making a private repository public exposes its whole history, so secrets committed long ago become visible.

Branch protection and rulesets

Branch protection rules and rulesets stop accidental or unreviewed changes to important branches. They can require pull requests before merging, a number of approving reviews, review from code owners, passing status checks, resolved conversations, signed commits or linear history, and they can block force pushes and deletion. Rulesets, the newer system, can layer several sets on the same branch, protect tags as well as branches, be switched off without deleting them, and be seen by anyone with read access. Where several rules apply, the most restrictive wins.

Security features in one paragraph

The outline's security skills overlap with the features MSBA-161 lessons 7 to 9 covered, and a foundations question may name any of them. The dependency graph lists a repository's dependencies; Dependabot alerts warn when one has a known vulnerability, Dependabot security updates open pull requests to fix it, and Dependabot version updates keep dependencies current on a schedule. Secret scanning finds committed credentials, and push protection blocks a push that contains one before it reaches GitHub. Code scanning analyzes code for weaknesses. Private vulnerability reporting lets outsiders report a weakness privately through the Security tab. On public repositories most of these are free; on private repositories several are part of the paid GitHub Secret Protection and GitHub Code Security products.

Organization settings and teams

Organization owners manage the settings that apply across repositories. The ones most likely in questions are the base permission for members, member privileges such as who may create repositories and of which visibility, whether members may fork private repositories, required 2FA, verified domains for email notifications, third-party access restrictions for OAuth apps, and the audit log, which records who did what and when. Teams group members, can be nested so that child teams inherit the parent's access, are given repository roles in one place, can be mentioned with @organization/team, and can be requested as reviewers.

Two further organization controls appear in questions about privacy. Verified domains let an organization confirm that it owns a domain, show a verified badge, and route notification emails for organization activity only to members' addresses on that domain. And an organization on GitHub Enterprise Cloud can require SAML single sign-on without moving to EMUs, so members keep their personal accounts but must also authenticate through the company's identity provider to reach organization resources. Rosa summed up the area for Owen as three questions that any scenario reduces to: who is this person, what may they reach, and what is the evidence afterwards.

What Owen fixed

Owen's three dots became ticks with one sentence each. Enterprise Managed Users: company-owned accounts from the identity provider, with no public contributions. Copilot policy: seats and policies set by owners, at enterprise or organization level. Internal versus private: internal is visible to the whole enterprise, private only to people given access. Rosa added a fourth, unprompted: recovery codes are the answer when a question asks how to regain access after losing a phone.