GH-900 sample questions — 25 answered and explained

GitHub adds collaboration features (pull requests, issues, Actions, discussions, permissions) around the version control that Git provides.

Git provides the version control mechanics: commits, branches and merges. GitHub hosts Git repositories and wraps them with collaboration and project features such as pull requests for code review and issues for tracking work. Because a pull request ends in a merge, merging is the tempting distractor, but the merge itself is Git's operation.

1. Sort each option into 'Git mechanics' or 'GitHub collaboration'.
2. Commits, branches and merges are Git mechanics.
3. Pull requests and issues exist only on the hosting platform.
4. Choose pull requests and issues.

Exam tip: Commit, branch, merge: Git. Pull requests, issues: GitHub.

GitHub adds collaboration around Git repositories, for example code review on pull requests; history, branching and commit IDs come from Git.

The team already has everything Git provides: full history in each clone, branching and unique commit hashes. What a plain Git server does not offer is GitHub's collaboration layer, such as pull requests with line comments, reviews and approvals, issues, and GitHub Actions. The distractors are all genuine benefits of version control, but the team already has them.

1. Note what the team already has: Git plus a shared server.
2. List what comes with Git itself: history, branches, commit IDs.
3. Identify what only the platform adds: web-based review and discussion.
4. Choose the code review interface.

Exam tip: If Git can do it on a laptop, GitHub doesn't add it; GitHub adds collaboration around it.

Git's local toolset (diff, blame, merge, log) versus GitHub's collaboration features (pull request reviews, issues, assignees).

The question is which tasks are built into Git itself. GitHub shows blame views, diffs and a merge button, so all five tasks can be done on GitHub, but git blame, git diff and git merge run on any clone without it. Requesting a review approval (pull requests) and assigning a bug (issues) only exist on a hosting platform.

1. Note that GitHub can show all five tasks, so the question is which ones Git cannot do.
2. Recall Git's own commands: diff compares versions, blame shows line authors, merge combines branches.
3. Recall the platform-only concepts: pull request reviews and issue assignment.
4. Choose the approval request and the bug assignment.

Exam tip: GitHub shows diffs, blame and merges, but Git does them itself; reviews and issues need the platform.

Distributed version control: every clone is a complete repository with the full history.

In centralised systems the history lives on one server and clients work with the latest files. In Git, cloning copies the entire repository, including every commit, so developers can view history, commit and branch locally and then share by pushing and pulling. Commits are not broadcast automatically, and the repository is not split across servers.

1. Recall what a Git clone contains: the whole repository and its history.
2. Contrast with centralised systems, where history stays on the server.
3. Reject descriptions of sharding or automatic broadcasting.
4. Choose 'every clone is a complete copy'.

Exam tip: Distributed means every clone has the full history.

Because Git is distributed, history, commits and branches work locally; only sharing through a remote needs the server.

A Git clone contains the whole repository, so reading the log, committing and branching all keep working while the server is down. Anything that talks to the remote — push, pull, fetch, clone from that server — has to wait. Once the server returns, developers push their new commits.

1. Split the actions into local operations and remote operations.
2. Local: log, branch, commit. Remote: push, pull, clone from the server.
3. Keep only the local ones.
4. Choose reading the log and branching/committing.

Exam tip: Server down? Git still commits, branches and shows history; only sharing waits.

Every Git clone is a full backup of the repository's history at the time it was last updated.

Because Git is distributed, the developer's clone contains every commit, by every author, up to its last fetch. The team can create a new remote and push from that clone to rebuild the shared repository; only work pushed in the final hour (and not yet fetched by anyone) is missing. The distractors each describe a clone that holds less than a full repository.

1. Recall what a clone contains: all commits and their snapshots.
2. Note that the history includes other people's commits, not just your own.
3. Note the only gap: anything pushed after the clone's last update.
4. Choose the full history.

Exam tip: Any up-to-date clone can rebuild a lost Git server: it has the whole history.

A repository is a project's files and their complete version history.

A Git repository is the unit Git manages: the project files plus all the commits that make up their history (stored in the hidden .git directory). A commit is one snapshot inside it, a branch is a pointer to a commit, and a repository on GitHub is simply one place a repository can be hosted.

1. Distinguish the container (repository) from what is inside it.
2. A commit is one snapshot; a branch is a pointer.
3. A repository need not be on GitHub.
4. Choose files plus full history.

Exam tip: Repository = files + history. Commit = one snapshot. Branch = pointer.

Which CODEOWNERS file applies to a pull request.

Each CODEOWNERS file applies to the branch it is on, and review requests come from the copy on the pull request's base branch. Because the file has not reached main yet, a pull request into main gets no automatic requests. The tempting branch protection answer confuses two things: requesting reviews happens automatically, while requiring a code owner's approval is an optional rule. The location (.github, root or docs) and team ownership are both valid here.

1. Note the PR's base branch: main.
2. Check where the CODEOWNERS file exists: only on an unmerged feature branch.
3. Recall that requests come from the base branch's CODEOWNERS.
4. Rule out location, team and branch-protection explanations using the stem's facts.

Exam tip: CODEOWNERS works from the pull request's base branch; protection only makes owner approval required.

A repository's security policy is its SECURITY.md file.

GitHub treats SECURITY.md as the security policy: it gives instructions for reporting a vulnerability and usually lists which versions are supported with security updates. GitHub surfaces it from the repository's Security area, so researchers find the private route before filing a public issue.

1. Identify the need: supported versions plus a private vulnerability reporting route.
2. Recall the community health file for security policies.
3. Reject files about help, contributions or conduct.
4. Choose SECURITY.md.

Exam tip: Vulnerability reporting instructions and supported versions belong in SECURITY.md.

SECURITY.md is documentation, and it can be inherited.

A security policy tells reporters which versions receive security fixes and how to report a vulnerability. It is documentation only: it does not enable Dependabot or any scanning. Like other community health files, an organization or account can provide a default SECURITY.md in a public repository named .github, used by every repository without its own. The file can be placed in the root, docs or .github folder of the repository.

1. Recall what a security policy contains.
2. Separate documentation from settings that enable scanning.
3. Recall which files can be organization defaults.
4. Recall the three accepted locations and reject the description that belongs to CONTRIBUTING.md.

Exam tip: SECURITY.md documents how to report; it does not turn on scanning.

Organization-wide defaults come from a public .github repository.

GitHub lets an organization or personal account provide default community health files, such as CODE_OF_CONDUCT.md, from a repository named .github. That repository must be public. Any repository without its own file of that type uses the default, so existing and future repositories are covered without copying. A template repository only seeds new repositories, and a repository named after a user is for profile READMEs.

1. Note the scope: existing repositories, no copying.
2. Recall where defaults are stored: a repository named .github.
3. Recall that the defaults repository must be public.
4. Reject templates, which only help new repositories.

Exam tip: Defaults: a PUBLIC repository named .github; a repo's own file overrides it.

Closing keywords only work for pull requests that target the default branch.

If a pull request targets any branch other than the default branch, GitHub ignores the closing keywords: no link is created and merging has no effect on the issue. The syntax here is fine (a colon is optional), descriptions are a valid place for keywords, and assignment is irrelevant.

1. The keyword and syntax are valid.
2. Check the target branch: release-2.0 is not the default.
3. Keywords are ignored for non-default targets, so the issue stays open.

Exam tip: Closing keywords only fire on merges into the default branch.

Closing several issues, including one in another repository, needs a keyword per issue and the full cross-repository reference.

Two rules combine. First, each issue needs its own keyword ('Resolves #10, resolves #123'), so a comma list after one keyword closes only the first. Second, an issue in another repository is written OWNER/REPOSITORY#NUMBER; a bare #12 means issue 12 in the pull request's own repository, and the repository name alone is not enough.

1. Give every issue its own closing keyword.
2. Refer to the other repository's issue as owner/repo#number.
3. A bare #number always means the current repository.
4. Only one option satisfies both rules.

Exam tip: One keyword per issue; other repositories need owner/repo#number.

Manual links are made in the Development sidebar, and the two sides have different repository rules.

Without editing the description, closing keywords are out, so the link must be manual, which needs write access. GitHub lets you link from the pull request's Development sidebar only to issues in the same repository, but from the issue's Development sidebar you choose any repository and then a pull request or branch. Mentions only cross-reference and projects only group items.

1. Description edits are ruled out, so keywords are out.
2. Manual linking happens in the Development sidebar.
3. The PR side only lists same-repository issues.
4. The issue side can choose another repository's pull request.

Exam tip: Linking across repositories manually? Start from the issue's Development sidebar.

Issue templates are files in the .github/ISSUE_TEMPLATE folder.

When a repository has files in .github/ISSUE_TEMPLATE on its default branch, the New issue page shows a template chooser. The workflows folder is for Actions, CONTRIBUTING.md offers guidance rather than a form, and the wiki is not read for templates.

1. Templates are repository files, not wiki pages or docs.
2. The folder is .github/ISSUE_TEMPLATE.
3. They must be on the default branch to appear.

Exam tip: Issue templates: .github/ISSUE_TEMPLATE on the default branch.

Copilot can check suggestions against public code on GitHub; a policy blocks matching suggestions or shows them with references to the matching code.

The public code policy has two outcomes: block suggestions that match public code, or allow them with information about where the matching code appears so the developer can review it. Copilot does not rewrite matches, queue them for approval or filter by license. Only public repositories on GitHub.com are searched; private code and code hosted elsewhere are not part of the check.

1. The concern is suggestions that duplicate public code.
2. Copilot compares suggestions with public repositories on GitHub.
3. The policy either blocks the match or shows it with references.
4. Reject invented behaviours such as rewriting or approval queues.

Exam tip: Public code matches: block them or show them with references, as the policy says.

Copilot agent mode in the IDE completes a task autonomously: it reads files, edits code, runs commands and corrects itself.

The developer wants Copilot to act, not just answer: choose files, edit, run tests and react to failures. That autonomous loop of reading, editing and running commands is agent mode. Ask mode answers questions, plan mode writes an implementation plan, and inline chat changes a selection you point it at without running and iterating on commands.

1. List what Copilot must do: pick files, edit, run tests, fix failures.
2. Running commands and iterating means autonomous tool use.
3. That is agent mode.
4. Ask answers, plan plans, inline chat edits a selection.

Exam tip: Want Copilot to do the task end to end in your editor, running commands as it goes? Agent mode.

Ask mode answers; plan mode plans; agent mode acts in your IDE; cloud agent acts in the background on GitHub.

Each Copilot surface has a distinct job. Ask mode answers questions and suggests code. Plan mode writes an implementation plan. Agent mode autonomously completes a task inside your IDE by reading files, editing code and running commands. Copilot cloud agent does similar work in an ephemeral cloud environment and delivers a pull request. The distractors describe the other three.

1. Match each description to a Copilot surface.
2. Answers only: ask mode. Plans only: plan mode.
3. Cloud environment plus pull request: cloud agent.
4. Edits and commands in your IDE: agent mode.

Exam tip: Agent mode = autonomous work in your IDE; cloud agent = autonomous work on GitHub in the background.

Repository roles: Read, Triage, Write, Maintain and Admin.

Applying and dismissing labels on issues, pull requests and discussions needs triage access. Creating, editing or deleting the labels themselves needs write access. Write and Maintain would also work for labelling but allow pushing code, so the least-access role is Triage.

1. Name the action: apply and remove existing labels.
2. Recall that applying labels needs triage access.
3. Note the constraint: no code push.
4. Pick the lowest role that meets both: Triage.

Exam tip: Triage applies labels; write creates them (and can push code).

New repositories include default labels such as bug, documentation, enhancement, good first issue and help wanted.

GitHub uses the good first issue label to fill the repository's contribute page, which is where newcomers look for approachable work. help wanted is the tempting near-twin: it asks for help but makes no promise that the task suits a beginner. Pinning and milestones change visibility or grouping, not the contribute page.

1. Note the audience: first-time contributors.
2. Recall which default label feeds the contribute page.
3. Separate 'beginner-friendly' from 'help needed'.
4. Choose good first issue.

Exam tip: good first issue is for newcomers; help wanted is for any help.

Maintain is for people who manage a repository without sensitive or destructive actions.

Maintain builds on Write and adds settings such as the description, topics, wikis, merge options, Pages publishing and interaction limits. It deliberately excludes access management, branch protection and rulesets, visibility changes, webhooks and deploy keys, and deleting, archiving or transferring the repository, all of which belong to Admin. Write cannot touch the repository's settings at all.

1. List the needed actions: description, topics, merge options.
2. List the forbidden ones: access, protection, deletion.
3. Recall that Maintain sits between Write and Admin.
4. Choose Maintain.

Exam tip: Maintain manages the repository; Admin adds access, protection, visibility and destructive actions.

Branch protection and rulesets are managed by repository administrators.

Maintain is meant for managing a repository without sensitive or destructive actions, and GitHub treats protection of branches as sensitive: only the Admin role (and organization owners, who have admin on every repository) can create or change branch protection rules and rulesets. A CODEOWNERS file is needed only for the separate code owner review option, and Write sits below Maintain.

1. Note the role held: Maintain.
2. Recall what Maintain excludes: access, protection, visibility, deletion.
3. Conclude the setting needs Admin.
4. Reject the CODEOWNERS and Write explanations.

Exam tip: Only repository admins (and organization owners) manage branch protection and rulesets.

A personal-account repository has an owner and collaborators; granular roles need an organization.

In a private repository owned by a personal account, the owner can only invite collaborators, and collaborators can push. GitHub's own guidance is to transfer the repository to an organization, or create it there, when finer access is needed: organization repositories offer Read, Triage, Write, Maintain and Admin. Triage does not exist for personal repositories, code owners are reviewers who need write access, and protecting one branch leaves the rest writable.

1. Note the owner type: a personal account.
2. Recall personal repositories have only owner and collaborator levels.
3. Recall that granular roles exist in organizations.
4. Choose transferring the repository to an organization.

Exam tip: Need read-only or other granular roles? Move the repository into an organization.

You can follow organizations, as well as users, to see their public activity.

Following an organization puts its public activity, such as new discussions, sponsorships and repositories, on your personal dashboard, and you can unfollow at any time. No membership is needed. Starring or watching one repository, even the organization's .github or profile repository, only covers that repository. GitHub labels following organizations as a public preview feature, so details may change.

1. Note the subject: an organization's activity, not one repository.
2. Note the constraint: no membership.
3. Recall that organizations can be followed like users.
4. Reject options scoped to a single repository.

Exam tip: Follow an organization to see its public activity without joining it.

Watching, following and starring do different jobs on GitHub.

Watching is set per repository and controls notifications: watching all activity notifies you about new issues, pull requests and more. Following is for users and organizations and puts their public activity on your personal dashboard. Starring bookmarks a repository and shows appreciation but sends no notifications and no activity feed. So the repository need calls for watching and the colleague need calls for following; any option that uses starring for either need fails it.

1. Split the request into its two needs.
2. Map repository notifications to watching.
3. Map a person's activity feed to following.
4. Reject any option that uses starring for either need.

Exam tip: Watch repositories for notifications, follow people for their activity, star to bookmark.