Understand Privacy, Security & Administration
This skill area is 10–15% of the exam. It covers securing accounts with 2FA and passkeys, repository and organization permissions and roles, identity integration with SAML SSO, SCIM, and team synchronization, Enterprise Managed Users and org-wide Copilot policy, repository visibility and branch protection, and managing organization settings, teams, and roles.
Account Security: 2FA & Passkeys
- Two-factor authentication (2FA) adds a second verification step beyond your password. Supported methods include an authenticator app (TOTP), security keys, GitHub Mobile, and SMS (least secure).
- Passkeys allow secure, passwordless sign-in using device biometrics or a PIN (built on WebAuthn/FIDO2) and are resistant to phishing.
- Always save your recovery codes — they restore access if you lose your second factor.
- GitHub now requires 2FA for accounts that contribute code on GitHub.com, reflecting a platform-wide security push.
Security keys and passkeys (WebAuthn) are the most phishing-resistant options; SMS is the weakest 2FA method. Passkeys enable passwordless login. Expect a question ranking or selecting the most secure method.
Permissions & Roles
Repository Roles
Access to a repository is granted through roles, from least to most privileged:
| Role | Typical capabilities |
|---|---|
| Read | View and clone the repo; open issues and PRs; comment. |
| Triage | Read plus manage issues and PRs (labels, assignments) without write access to code. |
| Write | Triage plus push code, manage branches, and merge PRs. |
| Maintain | Write plus manage some repository settings (not sensitive/destructive ones). |
| Admin | Full control — all settings, security, collaborators, and deletion. |
Organization Roles
- Owner — full administrative access to the organization and all its resources; use sparingly.
- Member — the default role for people in the org; access to repos is granted via teams/roles.
- Moderator, Billing manager, and security manager are additional specialized roles.
- Outside collaborator — a person given access to specific repos without being an org member.
- Access is best managed by adding people to teams and granting the team a repository role — the principle of least privilege.
Identity & Access: SAML SSO, SCIM & Team Sync
Companies connect GitHub to their identity provider (IdP), such as Microsoft Entra ID or Okta, so that access follows the employee directory. Three related features do this, and each solves a different problem. All of them need GitHub Enterprise (Cloud, or SAML-enabled Enterprise Server for SCIM).
| Feature | Question it answers | What it does | Where it's configured (Enterprise Cloud) |
|---|---|---|---|
| SAML single sign-on (SSO) | “Who are you?” — authentication | Members must sign in through the IdP before reaching the org's resources. Each GitHub account is tied to an IdP account through a linked identity. | Organization or enterprise |
| SCIM | “Should you have access at all?” — provisioning | The IdP automatically grants, updates, and removes access as people join, move, or leave the company. | Organization (personal accounts) or enterprise (EMU only) |
| Team synchronization | “Which teams are you in?” — group membership | Connects IdP groups to GitHub teams, so group membership changes are reflected on the team automatically. | Organization (Entra ID or Okta) or enterprise (Entra ID only) |
SCIM Provisioning
SCIM (System for Cross-domain Identity Management) is an open standard that lets administrators automate the exchange of user identity information between systems. SAML proves who someone is when they sign in; SCIM manages the lifecycle of their access.
How It Works by Deployment
| Deployment | What SCIM manages | Supported IdPs |
|---|---|---|
| Organization (Enterprise Cloud, personal accounts) | Adds people to the organization and, when they are deprovisioned in the IdP, automatically removes them from the organization. Their personal GitHub account itself is untouched. | Microsoft Entra ID, Okta, OneLogin |
| Enterprise Managed Users (Enterprise Cloud) | Creates, updates, suspends, and reactivates the managed user accounts themselves. SCIM is mandatory for EMU. | Partner IdPs: Entra ID (SAML or OIDC), Okta, PingFederate. Other SCIM 2.0 IdPs can use the REST API |
| Enterprise Server (self-hosted) | Creates, updates, and suspends user accounts on the instance when SAML SSO is in use. | Entra ID, Okta (PingFederate in preview) |
Key Rules
- SAML SSO is a prerequisite for SCIM.
- Without EMU, SCIM is configured at the organization level, never the enterprise level. You can't configure SCIM on an enterprise account unless it was created for Enterprise Managed Users.
- Once SCIM is enabled, membership changes should be driven from the IdP. Someone invited by hand on GitHub bypasses SCIM, so the IdP can't deprovision them later.
Team Synchronization
Team synchronization links a GitHub team to one or more IdP groups. When someone is added to or removed from the group in the IdP, the change is reflected on the GitHub team automatically, with no manual updates or custom scripts.
Requirements & Behavior
- Requires GitHub Enterprise Cloud with SAML SSO enabled. Each user needs a linked SAML identity.
- Supported IdPs: Microsoft Entra ID (commercial tenants) and Okta for organizations. Enterprise-wide team sync works with Entra ID only.
- You can connect up to five IdP groups to a single GitHub team.
- Once a team is synced, its membership can't be managed on GitHub or through the API. It is managed in the IdP, and existing team members who aren't in the connected groups are removed.
- Parent teams can't be synchronized with IdP groups.
- It is not a provisioning service. It doesn't invite people to the organization, and a user is only added to a team if they are already an organization member. Use SCIM to get people into the org.
Team Sync vs. IdP Groups with Enterprise Managed Users
EMU enterprises don't use team synchronization. Instead they manage team memberships with IdP groups sent over SCIM. The idea is the same, but the rules differ:
| Team synchronization | IdP groups (EMU) | |
|---|---|---|
| Accounts | Personal accounts with SAML SSO | Managed user accounts |
| IdP groups per team | Up to 5 | 1 |
| Adds users to the org? | No, they must already be members | Yes, automatically |
| Edit membership on GitHub? | No, it's managed in the IdP | No, it's managed in the IdP |
| Nested teams | Parent teams can't sync | Connected teams can't be a parent or a child |
Match the scenario to the feature: “require employees to sign in with company credentials” → SAML SSO. “Remove access automatically when someone leaves the company” → SCIM. “Keep GitHub team membership in step with Entra ID or Okta groups” → team synchronization. “The company must own and control the accounts themselves” → Enterprise Managed Users.
Enterprise Managed Users & Org Copilot Policy
Enterprise Managed Users (EMUs)
- With EMUs, user accounts are provisioned and fully controlled by the enterprise through its identity provider (IdP) via SAML/OIDC SSO and SCIM.
- Managed users can only interact within the enterprise — they can't push to public repos, use personal repos, or collaborate outside it — giving the company tight control over identity and data.
- Contrast with standard SSO, where members bring their existing personal GitHub accounts.
Organization-wide Copilot Policy Management
- Admins manage Copilot for the org: grant/revoke seats, set policies (e.g. suggestions matching public code, chat availability), and configure content exclusions so Copilot ignores specified files/repos.
- This centralized governance is what Copilot Business/Enterprise adds over individual plans.
Repository Visibility & Branch Protection
Visibility Options
| Visibility | Who can see it |
|---|---|
| Public | Anyone on the internet; ideal for open source. |
| Private | Only you and people/teams you explicitly grant access. |
| Internal | Visible to all members of the enterprise — the basis of InnerSource. Available in organizations owned by an enterprise. |
Branch Protection Rules
- Protect important branches (like
main) by requiring pull request reviews before merging, requiring status checks to pass, requiring signed commits, and restricting who can push. - They can prevent force-pushes and branch deletion, and enforce a linear history.
- Rulesets are the newer, more flexible way to define and target these protections.
The classic exam scenario: "ensure code is reviewed before it reaches main." The answer is a branch protection rule requiring pull request reviews (and often passing status checks). Combine with CODEOWNERS to auto-request the right reviewers.
Managing Organizations, Teams & Roles
- Teams group members and can be nested to mirror your org structure; child teams inherit parent access.
- Grant repository access to teams rather than individuals for easier, auditable management.
- Org settings control member privileges, base permissions, 2FA requirements, verified domains, and third-party app access.
- Use @team mentions and team review assignments to route work efficiently.
Study Resources
- Securing Your Account with 2FA (GitHub Docs) 2FA methods, passkeys, and recovery codes.
- Repository Roles (GitHub Docs) Read, Triage, Write, Maintain, and Admin permissions explained.
- About Enterprise Managed Users (GitHub Docs) How EMUs centralize identity via an IdP with SCIM.
- About SCIM for Organizations (GitHub Docs) How SCIM provisions and deprovisions organization members, and which IdPs support it.
- Managing Team Synchronization (GitHub Docs) Requirements, supported IdPs, and limits for syncing teams with IdP groups.
- About Protected Branches (GitHub Docs) Branch protection rules and rulesets.
- GitHub Foundations — Part 2 (Microsoft Learn) Security, privacy, and administration modules.