GitHub Foundations #8 Domain 6: Privacy, Security, and Administration — Permissions, 2FA, and Dependabot
Domain 6 is where GitHub Foundations asks the most boundary questions. From which of the five repository roles can you change settings? What exactly does each of Dependabot’s three features do? It probes the precise lines between things that look alike. It seems like a lot to memorize, but everything reduces to two questions: “who can do what” and “which threat is blocked at which stage”.
Repository permissions — collaborators and the five roles #
On a personal account’s repository, the owner grants access by inviting collaborators. An Organization’s repositories divide permissions into the more granular five roles. This table is Domain 6’s most frequently tested spot.
| Role | What it allows | Typical audience |
|---|---|---|
| Read | View code, comment on issues and PRs | Members who only need to read |
| Triage | Read + manage issues and PRs (labels, assignment, closing) | Issue managers with no code changes |
| Write | Triage + push, merge PRs, create releases | Regular developers |
| Maintain | Write + manage non-destructive repository settings | Project leads |
| Admin | All settings, security features, collaborator management, deletion | Repository administrators |
Boundary questions hinge on two lines. The first role that can push code is Write, and high-impact actions like security settings and repository deletion are Admin only. Remember Triage as the role that organizes issues without code access, and Maintain as Admin minus the dangerous operations, and you can handle the scenario questions.
Organizations — owners, members, and teams #
Organization-level permissions come in two layers.
- Organization roles — an owner holds everything including organization settings, member management, and billing, while a member simply belongs to the organization and receives repository permissions separately. An outside collaborator, someone outside the organization granted access to specific repositories only, is also a distinction to know.
- Teams — a container for granting repository permissions to a group rather than person by person. Teams support nesting, with a parent team’s permissions inherited by child teams. You can also request a team as a PR reviewer or mention one with
@org/team-name.
The organization-wide base permission is the default level (None to Write) every member gets on every repository. When a question invokes the principle of least privilege, the answer points toward keeping base permission low and granting what is needed through teams.
Authentication — 2FA, PATs, and SSH #
Account protection and API access methods are also in scope.
- 2FA (two-factor authentication) — supports TOTP authenticator apps, security keys (WebAuthn), GitHub Mobile approval, and SMS. GitHub has been mandating 2FA for active accounts, so remember it as a requirement, not a recommendation. Passwordless sign-in with passkeys is also supported.
- PAT (Personal Access Token) — a token used in place of a password for API and HTTPS authentication. The distinction between the two kinds is an exam point. Classic tokens carry broad, account-wide scopes, while fine-grained tokens narrowly specify target repositories and permissions and require an expiration date. From a least-privilege standpoint the answer is always fine-grained.
- SSH keys — key-pair authentication used instead of HTTPS. Register the public key on your account and clone and push work without a password.
Branch protection and rulesets #
These are the server-side guards that protect shared branches from mistakes. On a branch like main you can enforce the following.
- No direct pushes without a PR, and a minimum number of approving reviews
- Merging blocked until specified status checks (CI) pass
- Force pushes and branch deletion blocked
Rulesets are the newer format that applies the same goals to a wider scope (tags, multiple branch patterns, the organization level). At the exam level it is enough to know the shared purpose — rule-based branch protection — and that rulesets are the newer, unified format.
The security feature map — what blocks which threat #
After the role table, the boundaries between the security features are the next most common Domain 6 question. Distinguish them by what each one watches.
| Feature | Watches | What it does |
|---|---|---|
| Dependabot alerts | Dependencies | Warns about dependencies with known vulnerabilities |
| Dependabot security updates | Dependencies | Automatically opens PRs that fix vulnerable dependencies |
| Dependabot version updates | Dependencies | Opens regular update PRs regardless of vulnerabilities (configured via dependabot.yml) |
| Secret scanning | Commit contents | Detects token and key patterns that have entered the repository and alerts |
| Push protection | Push time | Blocks a push containing secrets at the receiving stage |
| Code scanning (CodeQL) | Source code | Analyzes the code itself for vulnerable patterns (injection and the like) |
The three Dependabot features are a particular staple: alerts warn, security updates open vulnerability-fixing PRs, and version updates open regular update PRs. Secret scanning and push protection relate as after-the-fact detection versus advance blocking. What kind of real-world incident push protection prevents is covered, along with the response procedure, in Committed a Secret to Git? Rotate the Key First, Then Clean History with filter-repo.
The remaining pieces of this map are the dependency graph, which shows the dependency inventory itself, SECURITY.md, which announces where to report vulnerabilities, and security advisories, which publish vulnerabilities and announce patched versions.
Audit log and verified commits #
Two more items appear on the administration side.
- Audit log — an event log recording who did what and when in an Organization (member invitations, permission changes, repository deletion, and so on). Organization owners use it for incident investigations and compliance checks. Keep it separate from Insights, which shows repository activity statistics.
- Commit signing (verified) — sign commits with a GPG or SSH key and GitHub displays a Verified badge next to them. Since the author field of a commit can be set to anything, a signature is the proof that a commit really came from the key’s owner.
Privacy — profile and email #
- You can choose whether your contribution graph shows private repository activity, and Organization membership can be public or private.
- If you do not want your real email in commits, enable Keep my email addresses private in settings and commit with the
noreplyaddress GitHub provides. Commits made through the web UI use it automatically.
Wrapping up #
Three takeaways from this post.
- Repository permissions come in five roles — Read, Triage, Write, Maintain, Admin — with Write as the boundary for pushing and Admin as the boundary for high-impact settings.
- Authentication assumes mandatory 2FA as the baseline, and the recommended token answer is the least-privilege fine-grained PAT.
- Separate the security features by what they watch: dependencies belong to Dependabot, secrets to secret scanning and push protection, and code patterns to code scanning.
The next post, “GitHub Foundations #9 Domain 7: The GitHub Community + Exam Tips”, wraps up the final domain — open source, InnerSource, and the community features — together with the tips to check right before the exam.