Understand Privacy, Security, and Administration Study Guide — GH-900

Project Management and GitHub Administration

This domain accounts for 15% of the GitHub Foundations exam and tests your ability to configure and manage GitHub at the organizational and enterprise scale. Questions assess whether you know the exact names of roles, permission levels, and features — not just conceptual understanding. Expect scenario-based questions that require you to choose the right tool, role, or setting from a list of similarly named options.

Organizations

Core Concepts

A GitHub Organization is a shared account that allows groups of people to collaborate across many repositories simultaneously. Organizations have their own identity, billing, and membership structure.

Organization member roles:

Key facts:

• An organization can have multiple Owners — best practice is at least two.
• Billing Managers cannot see repositories or manage members; they can only manage subscriptions and payment.
• Outside Collaborators are individuals added to a specific repo without being full org members; they count against paid seats.
• Organizations are available on Free, Team, and Enterprise plans. Certain features (advanced audit log, SAML SSO) require Team or Enterprise.

Creating and Billing

• Any GitHub user can create an organization.
• Billing is per-organization unless the org is under an Enterprise account (which centralizes billing).
• GitHub Free for Organizations allows unlimited public repositories and limited private repository collaboration features.
• GitHub Team adds required reviewers, draft PRs, protected branches, and code owners.

Common Traps

• The exam may present Billing Manager as a way to manage repositories — it cannot.
• Outside Collaborator access does not make someone an org member; they won't appear under "Members."
• Owners are the only role that can delete an organization.
• Do not confuse organization role with repository role — a member with the Member org role still needs explicit repository permission.

Teams

Core Concepts

Teams are groups within an organization used to manage permissions and send notifications. Teams can be visible (any org member can see) or secret (only members and owners see them).

Nested Teams allow a hierarchy: a child team inherits permissions from its parent. This mirrors organizational structures (e.g., Engineering → Frontend, Engineering → Backend).

Nested teams inherit the parent team's repository access — child teams receive at least what the parent receives.

Team Permissions on Repositories

Teams are granted one of five repository permission levels (see Repository Permissions section). You assign a team to a repository with a specific role.

CODEOWNERS Integration

A CODEOWNERS file defines individuals or teams responsible for specific files or directories. When a PR modifies a file owned by a team, that team is automatically requested as a reviewer.

• File lives at: .github/CODEOWNERS, CODEOWNERS, or docs/CODEOWNERS
• Syntax example: *.js @org/frontend-team
• Requires branch protection rules with "Require review from Code Owners" enabled to enforce reviews.
• CODEOWNERS uses gitignore-style patterns.
• The last matching rule in the file takes precedence.

Common Traps

• Secret teams are not hidden from owners — owners always see all teams.
• CODEOWNERS enforcement only applies when the branch protection rule "Require a pull request before merging" → "Require review from Code Owners" is enabled; the file alone does not enforce.
• Child teams inherit parent permissions but cannot have weaker permissions than the parent on the same repo.
• Team mentions (@org/team-name) notify all team members only if the team's notification setting allows it.

Worked Scenario: A company wants the security team to automatically review any changes to config/secrets.yml. The security team must be listed as an owner in CODEOWNERS, AND the relevant branch must have a protection rule requiring Code Owner review. Just adding the CODEOWNERS file is insufficient.