GitHub Foundations (GH-900) · 13% practice allocation

GitHub GH-900: Collaborate Using GitHub Practice Questions

5 free sample questions from the Collaborate Using GitHub domain, with answers and explanations. The full GH-900 bank has 150 questions across 7 domains. Questions are scenario-based and written from the official GitHub exam guide.

1.

You are configuring a repository's branch protection rule for the main branch. You want to ensure that every merged commit history remains linear (no merge commits). Which branch protection setting should you enable?

  • A. Require signed commits
  • B. Restrict who can push to matching branches
  • C. Require a pull request before merging
  • D. Require linear history✓ Correct
Explanation

'Require linear history' prevents merge commits from being pushed to the protected branch, forcing contributors to use squash merges or rebase merges instead, which keeps the commit history linear.

Why the others are wrong:

  • 'Require a pull request before merging' enforces code review workflow but does not prevent merge commits.
  • 'Require signed commits' enforces GPG/SSH commit signing for auditability but has nothing to do with history linearity.
  • 'Restrict who can push' controls who has write access but does not affect merge strategy or history shape.
2.

A team uses GitHub Issues to track work. At the end of a sprint, the team lead wants to automatically close issue #42 when a related pull request is merged into main. Which of the following PR descriptions will correctly close the issue upon merge?

  • A. Addresses #42
  • B. Fixes #42✓ Correct
  • C. References #42
  • D. Related to #42
Explanation

'Fixes #42' is one of GitHub's supported closing keywords (others include 'Closes', 'Resolves', 'Fix', 'Close', 'Resolve'). When the PR is merged into the default branch (or the branch specified in the issue), GitHub automatically closes the linked issue.

Why the others are wrong:

  • 'References #42' creates a cross-reference link between the PR and the issue but does NOT close the issue.
  • 'Related to #42' is not a recognized GitHub keyword and only creates a hyperlink mention, not an auto-close trigger.
  • 'Addresses #42' is not a supported closing keyword; it creates a mention but will not close the issue automatically.
3.

A project manager sets up a GitHub Project (v2) to track a quarterly release. She wants to visualize tasks plotted against a timeline to see which items overlap and identify scheduling conflicts. Which GitHub Projects (v2) layout should she use?

  • A. Table layout
  • B. Milestone burndown chart
  • C. Roadmap layout✓ Correct
  • D. Board layout
Explanation

The Roadmap layout in GitHub Projects (v2) displays items on a horizontal timeline, allowing teams to see date ranges, identify overlapping work, and detect scheduling conflicts.

Why the others are wrong:

  • Board layout uses a Kanban-style column view organized by status — useful for workflow state but not for timeline visualization.
  • Table layout shows items in a spreadsheet-like grid with custom fields — good for bulk editing but not for timeline/scheduling views.
  • 'Milestone burndown chart' is not a GitHub Projects (v2) built-in layout; GitHub does provide basic milestone progress bars, but there is no native burndown chart layout in Projects v2.
4.

A developer wants to signal that a pull request is still a work in progress and should not be merged yet, but they still want teammates to be able to see the changes and leave early feedback. What is the BEST way to accomplish this on GitHub?

  • A. Open the pull request and immediately request a review, then add a 'do-not-merge' label
  • B. Open the pull request normally and add a '[WIP]' prefix to the title
  • C. Push the branch without opening a pull request and share the branch URL
  • D. Open the pull request as a Draft PR✓ Correct
Explanation

Draft PRs are GitHub's built-in mechanism for marking a pull request as not ready to merge. The 'Ready for review' button must be clicked before the PR can be merged and before required reviewers are auto-requested.

Why the others are wrong:

  • Adding '[WIP]' to the title is an informal convention with no enforcement by GitHub — nothing prevents a merge.
  • Requesting a review and adding a label is manual and inconsistent; GitHub does not block merging based on a label alone.
  • Sharing a branch URL without a PR provides no structured review interface or merge workflow.
5.

A team maintains an open-source library and wants a space where users can ask how-to questions, and where the best answer can be marked as the accepted solution (similar to a forum). Issues are reserved strictly for confirmed bugs. Which GitHub feature is MOST appropriate?

  • A. GitHub Issues with a 'question' label
  • B. GitHub Discussions with the Announcements category
  • C. GitHub Discussions with the Q&A category✓ Correct
  • D. A GitHub Wiki page with a FAQ section
Explanation

GitHub Discussions with the Q&A category is purpose-built for community questions. It supports marking a specific reply as the 'Accepted Answer,' which highlights the solution and makes it easy for future visitors to find. It also keeps the Issues tracker clean for confirmed bugs.

Why the others are wrong:

  • GitHub Issues with a 'question' label can work informally, but Issues do not support the 'accepted answer' mechanic and are harder to separate from bugs in practice.
  • The Announcements category in Discussions is restricted so only maintainers can post — it is for one-way broadcasts, not community Q&A.
  • A Wiki FAQ is static documentation; it does not support threaded discussion, voting, or accepted answers.

Test yourself across every GH-900 domain

The free GH-900 practice test mixes about 20 questions weighted like the exam. The full 150-question bank adds instant grading, flashcards and a timed mock exam.

Take the free GH-900 practice testPractice the full bank

Study this domain

Collaborate Using GitHub study guide (GH-900) →

Other GH-900 domains

← All GitHub Foundations study resources