12.2 Access Permissions and Roles

GitHub Foundations GH-900

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Domains, Scoring, and Candidate Profile 1.3 Official Resources and Hands-On Prep

2 Version Control Fundamentals

2.1 Purpose and Benefits of Version Control 2.2 Git vs GitHub 2.3 Repositories, Commits, and History 2.4 Branches, HEAD, and the Default Branch

3 Working with GitHub

3.1 Accounts, Organizations, and Enterprise Options 3.2 GitHub Flow 3.3 Markdown for Issues and Pull Requests 3.4 GitHub Desktop and GitHub Mobile

4 Repository Structure and Key Files

4.1 Repository Structure and Community Health Files 4.2 Creating Repositories with Templates and Branches 4.3 Adding and Managing Files

5 Repository Insights and Maintenance

5.1 Insights, Stars, Dashboards, and Dependency Insights 5.2 Repository Maintenance and Collaboration Best Practices

6 Issues and Pull Requests

6.1 Issues 6.2 Pull Requests 6.3 Linking PRs, Templates, Filters, and Assignments

7 Discussions, Notifications, and Documentation

7.1 Discussions 7.2 Notifications and Workflow Management 7.3 Gists, Wikis, and GitHub Pages

8 GitHub Actions

8.1 Actions Purpose, Workflows, and Events 8.2 Jobs, Steps, Runners, Secrets, and Reusable Actions

9 GitHub Copilot

9.1 Copilot Suggestions, Agents, Agent Mode, and Multi-Model Support 9.2 Copilot for Individuals, Business, and Enterprise

10 Codespaces and github.dev

10.1 Codespaces, Customization, and Dev Containers 10.2 github.dev vs Codespaces

11 Manage Projects with GitHub

11.1 GitHub Projects and Layout Options 11.2 Configuring Projects, Labels, Milestones, and Workflows 11.3 Saved Replies and Assignees 11.4 Project Insights

12 Account Security and Access

12.1 Two-Factor Authentication and Passkeys 12.2 Access Permissions and Roles 12.3 Enterprise Managed Users and Copilot Policy

13 Privacy, Branch Protection, and Organization Admin

13.1 Privacy, Visibility, and Branch Protection 13.2 Organization Settings, Teams, and Roles

14 Open Source, Sponsors, and InnerSource

14.1 Open Source Benefits and GitHub Sponsors 14.2 How GitHub Supports Open-Source Projects 14.3 InnerSource

15 Marketplace, Discovery, and Collaboration Models

15.1 Following Users and Organizations 15.2 GitHub Marketplace 15.3 Forks, Templates, and Discoverable Repositories

12.2 Access Permissions and Roles

Key Takeaways Explain This Topic AI

A personal-account repository has two permission levels: the owner (full control) and collaborators (pull and push); in a private personal repository, owners can grant only write access—no read-only collaborators.

Organization repository roles, from least access to most, are Read, Triage, Write, Maintain, and Admin.

Predefined organization roles include Owner, Member, Billing manager, Moderator, and Security manager; an outside collaborator has repository access without being an organization member.

Organization owners set base permissions that apply to all members on every organization repository; base permissions do not apply to outside collaborators.

Organization owners have admin access to every repository the organization owns.

Last updated: August 2026

Why GH-900 tests least privilege on two different ladders

After 2FA, Domain 6 asks you to identify access permissions and roles for repositories and organizations . A permission is a single action (delete an issue, push a commit, change billing). A role is a bundled set of permissions you assign to a person or a team. GH-900 expects you to keep personal-repository access , organization repository roles , and organization-level roles in separate buckets. Mixing them is the most common miss.

Personal repositories: owner and collaborators

A repository owned by a personal account has two permission levels : the repository owner and collaborators . There is a single owner with full control. Collaborators pull (read) and push (write) .

In a private personal repository, owners can grant collaborators only write access . GitHub is explicit: collaborators cannot have read-only access to a personal-account private repository. If a stem wants a contractor to view a private personal repo without pushing, the documented answer is to transfer the repository to an organization so you can assign Read . Unlimited collaborators are allowed on public and private personal repos on GitHub Free, but GitHub rate-limits how many people you can invite in 24 hours.

The owner uniquely (among other things) invites collaborators, changes visibility, deletes the repository, manages security and analysis settings, archives the repo, manages deploy keys and webhooks, and can merge to a protected branch even without approving reviews. Collaborators can fork, work issues and pull requests, merge pull requests, manage labels and milestones, act as code owners, and remove themselves . They cannot delete the repository or invite more collaborators.

When you remove a collaborator , they lose read/write access. If the repository is private and they forked it, that fork is deleted . Local clones they already made still exist on disk—revoking GitHub access does not wipe laptops.

Organization repository roles: least to most

On an organization-owned repository you assign Read, Triage, Write, Maintain, or Admin — least access to most access . You can assign those roles to members, outside collaborators , and teams . GitHub Enterprise Cloud organizations can also create custom repository roles . Choose the smallest role that matches the job.

Role GitHub's recommended audience Signature abilities and limits

Read Non-code contributors who want to view or discuss Pull, fork, open issues, comment, submit ordinary PR reviews, view Actions runs. Cannot push, merge, apply labels, or approve / request changes when reviews are required . Public wikis can be edited; private wikis cannot .

Triage People who manage issues, discussions, and pull requests without write access Everything in Read, plus apply/dismiss labels, close/reopen/assign all issues and PRs, apply milestones, mark duplicates, request reviews, hide comments. Still cannot push, merge, create labels, or create milestones.

Write People who actively push Push, merge pull requests, approve required reviews, apply suggested changes, create/edit/delete labels and milestones, lock conversations, transfer issues, act as CODEOWNERS, convert draft PRs, edit private wikis. Cannot manage who has access to the repository.

Maintain Project managers who manage the repository without sensitive or destructive actions Write plus many repository-management settings (topics, wikis enablement, some merge settings) without deleting the repo or handling the most sensitive security and access changes.

Admin People who need full access, including sensitive and destructive actions Manage individual, team, and outside-collaborator access ; manage security; delete the repository.

Memorize three discriminators:

Triage versus Write: triage does not push or merge. If the person must commit, they need Write or higher.

Write versus Admin: write can ship code; only Admin manages repository access (who is on the repo).

Maintain versus Admin: maintain is for day-to-day project management; deleting the repo and managing security / collaborator access sit with Admin .

Required reviews are a favorite trap. Read and Triage can submit reviews, but they cannot approve or request changes when the branch requires reviews. Write, Maintain, and Admin can.

Deploy keys bypass the role table: anyone who holds the private key can read or write according to the key's setting, even after they are removed from the organization . Treat deploy keys as credentials, not as a substitute for a person-shaped role.

Loading diagram... Personal collaborators versus organization repository roles

Organization-level roles, base permissions, and outside collaborators

Repository roles answer “what can this person do in this repo ?” Organization roles answer “what can this person do to the organization ?” You can invite someone as an owner , billing manager , or member . After they join, owners can add predefined or custom roles such as Moderator or a CI/CD role. Custom organization roles (for example “view the audit log” without full ownership) are a GitHub Enterprise Cloud feature.

Predefined organization roles GH-900 expects you to name

Organization owners have complete administrative access . GitHub recommends at least two owners so the org is not stranded. Owners also have admin access to every repository the organization owns—you do not grant Admin repo-by-repo for owners.

Members are the default non-administrative role. By default they can create repositories and projects, subject to org settings. Their repository access then comes from base permissions , team grants, and per-repo roles.

Billing managers manage billing settings and payment information . They are the right answer when finance needs invoices without becoming an owner. Billing manager is not Admin on every repo.

Moderators are members who can block and unblock non-member contributors , set interaction limits , and hide comments in the organization's public repositories. Use this for community health, not for security alerts.

Security managers can be assigned to a member or a team . The role grants permission to view security alerts and manage security-feature settings across the organization, plus read permission on all repositories . It is the least-privilege answer for a security team that must see every repo's alerts without becoming owners.

GitHub App managers can manage settings of GitHub App registrations the org owns. The role does not grant install/uninstall of GitHub Apps on the organization. Know it exists; GH-900 more often tests Owner versus Security manager versus Billing manager.

Outside collaborators have access to one or more organization repositories but are not members . Consultants and temporary contractors are the textbook case. They do not get org-wide member privileges, they do not receive base permissions , and they are the people removed (not merely blocked from resources) if the org requires 2FA and they have not enabled it.

An outside collaborator is not “a member with Read.” Membership and collaborator status are different relationships. Converting a member to an outside collaborator drops them from the member list while leaving selected repo access.

Base permissions apply to members, not to outside collaborators

Organization owners set base permissions that apply to all members when they access any of the organization's repositories. Defaults: members have Read on the organization's public repositories. Owners can raise or lower that floor (including No permission , Read , Write , Admin , depending on the org's options).

Rules that show up in stems:

Base permissions do not apply to outside collaborators . A contractor with no explicit repo role does not inherit the member floor.

A higher per-repository grant overrides the base. A member with base Read who is given Write on api has Write on api and still has only the base elsewhere.

Changing base permissions affects new and existing members .

Permissions for private forks are not automatically updated when base permissions change.

Internal repositories have a minimum of read even if base permission is none .

Exam traps for D6.2

Personal ≠ organization. Personal private repos cannot do read-only collaborators. Organizations can assign Read.

Order is Read, Triage, Write, Maintain, Admin. Triage is above Read and below Write. It is not a synonym for Maintain.

Triage cannot push or merge. Write can.

Only Admin (and org owners, who already have Admin on every org repo) manages repository access .

Owners ≠ billing managers ≠ security managers. Billing is money. Security manager is alerts plus read-all-repos. Owners are full admin.

Outside collaborator ≠ member. Repo access without membership; excluded from base permissions.

Base permission is a member floor , overridable upward per repo, ignored for outside collaborators.

Deploy keys can outlive org removal if someone still holds the private key.