GitHub Foundations · 25% of the exam

Collaboration Features — Issues, PRs, Discussions: free practice questions

5 sample questions from our 31-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real GitHub exam.

1. A senior engineer reviews a pull request and notices several small problems across multiple files. She wants to propose exact line-by-line code replacements that the author can apply with a single click, but she does NOT yet want to submit her overall review verdict — she wants to queue all suggestions together and submit them as one review. Which sequence of actions correctly achieves this?

  • A. For each line, click 'Add single comment' and include a suggestion block in each comment, then submit the review as 'Comment'
  • B. For each line, click the suggestion icon in the diff view to insert a suggestion block, then click 'Add review comment' (not 'Add single comment') to batch them, and finally click 'Finish your review' to submit all at once✓ Correct
  • C. Use the GitHub CLI to push corrected commits directly to the pull request branch, which surfaces as suggestions in the Files Changed tab
  • D. Open each file in the web editor, make the changes, and commit them to the PR branch; GitHub converts these commits to inline suggestions automatically
  • E. For each line, click 'Add single comment' immediately — GitHub automatically batches all single comments into one pending review until you explicitly submit
Explanation

Option B is correct: when reviewing a PR, clicking 'Add review comment' (rather than 'Add single comment') adds the suggestion to a pending batch that is held until 'Finish your review' is clicked, allowing the reviewer to submit all suggestions as a single review event. Option A is wrong because 'Add single comment' publishes the comment immediately as a standalone remark, bypassing the pending-review queue. Option C is wrong because pushing commits via the CLI modifies the branch directly; it does not create suggestions. Option D is wrong for the same reason — committing changes to the branch does not generate suggestion blocks in the review interface. Option E is wrong because 'Add single comment' does NOT queue comments into a pending review; each one is posted immediately.

2. A regulated financial company configures the following branch protection rule on their `main` branch: - ✅ Require a pull request before merging - ✅ Require approvals: **2** - ✅ Dismiss stale pull request approvals when new commits are pushed - ✅ Require review from Code Owners - ✅ Require status checks to pass before merging - ✅ Restrict who can push to matching branches (only the 'release-team' group) A developer on the 'release-team' group has already obtained 2 approvals (including one from a relevant CODEOWNER). She then pushes a small documentation fix directly to `main` using `git push origin main`. Which TWO statements correctly describe what happens?

  • A. The push is rejected because the branch protection rule requires all changes to go through a pull request, even for members of 'release-team'✓ Correct
  • B. The push succeeds because the developer is a member of the 'release-team' group, which is explicitly allowed to push to main
  • C. The push succeeds but GitHub automatically opens a pull request on her behalf to retroactively capture the change
  • D. The existing pull request's approvals are automatically dismissed because a new commit was pushed to the branch✓ Correct
  • E. The push is blocked because CODEOWNER review is required, and a direct push bypasses the review process entirely
  • F. The push triggers all required status checks to re-run; if they pass, the commit is accepted without a pull request
Explanation

Options A and D are both correct. Option A: 'Require a pull request before merging' applies to ALL pushes to the protected branch, including those from users in the restricted push list — 'Restrict who can push' controls which accounts can push AT ALL, but the PR requirement still enforces that changes must arrive via a pull request; a direct push is rejected by this rule. Option D: 'Dismiss stale pull request approvals when new commits are pushed' means that if a commit is pushed to the HEAD of the PR branch, existing approvals are invalidated — however, since option A correctly states the push is rejected, option D applies to the scenario context of the existing PR (the prior approvals on her open PR would have been dismissed had she pushed to the PR branch before merging). Both A and D reflect real behavior of these two settings working in tandem. Option B is wrong: the 'Restrict who can push' setting gates who may attempt a push, but it does NOT override the 'Require a pull request' rule — the push is still rejected. Option C is wrong: GitHub never auto-creates a pull request from a rejected or completed push. Option E is a partially true distractor — CODEOWNER review is required — but the primary rejection reason is the PR requirement (option A), not CODEOWNER enforcement specifically on a direct push. Option F is wrong: status checks are evaluated within a pull request workflow; a direct push that violates the PR requirement is rejected outright and does not trigger the status-check gate.

3. 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 team members to be able to view and comment on it. What is the most appropriate action?

  • A. Open the pull request as a Draft PR✓ Correct
  • B. Add a 'WIP' label to the pull request
  • C. Add a comment to the pull request saying 'Do not merge'
  • D. Set the pull request as a private repository
Explanation

Draft PRs are GitHub's built-in mechanism for marking a pull request as not ready for review or merge. The 'Mark as ready for review' button must be clicked before the PR can be merged, and required reviewers are not automatically notified. Adding a 'WIP' label (option B) is a manual convention with no enforcement by GitHub — it does not prevent merging or suppress review requests. A comment (option C) is purely informational with no enforcement. Setting the repository to private (option D) is unrelated to PR status and would affect all repository access, not just this PR.

4. Which keyword, when used in a pull request description or commit message on the default branch, will automatically close a linked issue when the PR is merged?

  • A. RELATES TO #42
  • B. FIXES #42✓ Correct
  • C. REFERENCES #42
  • D. SEE #42
Explanation

GitHub recognizes a set of closing keywords — including 'fixes', 'closes', 'resolves', 'fix', 'close', and 'resolve' (case-insensitive) — that automatically close a linked issue when the PR is merged into the default branch. 'FIXES #42' is one of these recognized keywords. 'RELATES TO' (option A), 'REFERENCES' (option C), and 'SEE' (option D) are not recognized closing keywords; they will create a cross-reference hyperlink in the issue timeline but will not automatically close the issue.

5. A maintainer is reviewing a pull request and wants to suggest a specific one-line code change directly in the diff so that the PR author can apply it with a single click. Which GitHub feature should the maintainer use?

  • A. Leave an inline comment describing the desired change in plain text
  • B. Use a suggestion block (` ```suggestion ``` `) in an inline comment✓ Correct
  • C. Open a new issue describing the desired change and cross-reference the PR
  • D. Edit the contributor's branch directly and push the change
Explanation

GitHub's suggestion blocks let reviewers propose exact code changes inside a diff comment using the ` ```suggestion ``` ` fenced block. The author (or anyone with write access) can then click 'Commit suggestion' to apply it as a commit, or batch multiple suggestions into a single commit. Why the others are wrong: - A plain inline comment describes the change but forces the author to manually implement it — there is no one-click apply. - Opening a new issue is a heavyweight process for a single-line change and breaks the review flow. - Editing the contributor's branch directly bypasses the review process and may violate contribution etiquette or branch protection rules.

26 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free