12.2 Access Permissions and Roles
Key Takeaways
- 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.
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.
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
apihas Write onapiand 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.
From least access to most access, what is the documented order of repository roles on an organization-owned repository?
A consultancy needs temporary write access to one private repository in an organization but should not appear as an organization member or inherit the organization's base repository permissions. Which relationship matches that requirement?
Which statement about organization owners and base permissions is accurate?