Try 10 focused GitHub Foundations GH-900 questions on Collaborate Using Github, with explanations, then continue with IT Mastery.
Open the matching IT Mastery practice page for timed mocks, topic drills, progress tracking, explanations, and full practice.
Try GitHub Foundations GH-900 on Web View full GitHub Foundations GH-900 practice page
| Field | Detail |
|---|---|
| Exam route | GitHub Foundations GH-900 |
| Topic area | Collaborate Using Github |
| Blueprint weight | 15% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Collaborate Using Github for GitHub Foundations GH-900. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 15% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
Topic: Collaborate Using Github
A team maintains a public GitHub repository. Several users have asked for a dark mode feature, but the maintainers first want open-ended community feedback about whether the idea is useful and what it should include. They are not ready to assign work or track implementation yet.
What is the best next action?
Options:
A. Change the repository visibility to private
B. Start a GitHub Discussion for community feedback
C. Create a pull request with a placeholder change
D. Open a GitHub Issue and assign it immediately
Best answer: B
Explanation: Use a GitHub Discussion when the goal is to gather opinions, ideas, and conversation without turning the topic into a tracked work item yet. An issue is better once the team is ready to record a specific task, bug, or feature request to manage.
The key concept is choosing the GitHub collaboration tool that matches the need. In this scenario, the maintainers want broad community input first, not task tracking or implementation. A Discussion fits that purpose because it supports open-ended conversation, idea exploration, and feedback from multiple participants.
An Issue is a better fit when the team is ready to track a defined piece of work, such as a bug, task, or approved feature request. A pull request is for proposing actual changes to the repository, and repository visibility settings control access rather than collaboration format.
When the goal is conversation first and work later, start with a Discussion.
Topic: Collaborate Using Github
A repository has many open issues. The maintainers want contributors to quickly see which items are bugs, documentation tasks, or enhancements, even before anyone is assigned to work on them. Which GitHub feature best fits this need?
Options:
A. Issue assignees
B. Issue labels
C. Pull requests
D. Discussions
Best answer: B
Explanation: Use labels when the goal is to categorize issues for clearer workflow tracking. Labels help teams identify issue type or status at a glance, while assignment is mainly for ownership.
The key concept is issue labeling. In GitHub, labels are used to organize and categorize issues so people can quickly understand what kind of work each item represents, such as a bug, enhancement, or documentation task. That matches the scenario because the team wants visibility by issue type before work ownership is decided.
Assignment serves a different purpose: it shows who is responsible for working on an issue. If the need is classification rather than ownership, labels are the better fit. This is a common beginner workflow practice for keeping issue lists clear and searchable.
Topic: Collaborate Using Github
A teammate fixed issue #18 in a shared GitHub repository by committing changes to a branch named docs-fix. The team wants the change reviewed before anything is merged into main. What is the best next step?
Options:
A. Change repository permissions so more people can edit main directly
B. Open a pull request from docs-fix into main and link issue #18
C. Open a new issue describing the completed fix
D. Merge docs-fix directly into main because the changes are already committed
Best answer: B
Explanation: A pull request is the GitHub feature used to propose changes from one branch into another and have them reviewed before merge. Since the fix is already on docs-fix and the team wants review before updating main, opening a pull request is the right next action.
In GitHub, a pull request is created after changes are pushed to a branch and you want those changes considered for merge. It shows the differences between the source branch and the target branch, gives reviewers a place to comment, request changes, and approve the work, and supports linking related issues such as #18. That makes it the correct workflow for a reviewed change.
An issue tracks a task or problem, but it does not present branch changes for review. Changing permissions affects who can edit the repository, not how a proposed change is reviewed. Directly merging into main would skip the review step that the scenario explicitly requires.
main fails because it skips the requested review before merge.Topic: Collaborate Using Github
After helping during a launch, Priya set a busy repository to Watch. The launch is over, and she now wants GitHub to notify her only when she is directly involved, such as being @mentioned or assigned. What should she do next?
Options:
A. Change notifications from web to email only
B. Unsubscribe from one pull request conversation
C. Change the repository’s watch setting to a narrower level or stop watching
D. Create a personal fork of the repository
Best answer: C
Explanation: Priya should adjust her watching behavior because the extra notifications are coming from repository-wide watching. Narrowing or stopping watching reduces broad updates while still allowing notifications when she is directly involved, such as through mentions or assignments.
In GitHub, watching controls how much repository-wide activity you are notified about. Priya explicitly watched a busy repository for launch updates, so the correct next step is to lower that watch level or stop watching once she no longer needs broad visibility.
GitHub notifications can come from different sources:
Because Priya wants only direct-involvement notifications, changing the repository watch setting matches her goal. If the problem were just one noisy issue or pull request, unsubscribing from that single thread would be more appropriate. Changing delivery method or creating a fork does not reduce repository-wide notification triggers.
Topic: Collaborate Using Github
A beginner contributor opens a busy repository and sees dozens of issues and pull requests. She needs to quickly find only the open pull requests assigned to her so she can review them first. Which GitHub feature should she use?
Options:
A. Create a milestone for her pending reviews
B. Use filters on the pull requests list
C. Start a repository discussion about review priority
D. Enable branch protection for the default branch
Best answer: B
Explanation: Filters help users narrow issues or pull requests to the items that match specific conditions. In this case, the contributor wants only open pull requests assigned to her, which is exactly what filtering is for.
GitHub filters are used to quickly find relevant issues or pull requests in busy repositories. They let you narrow a list by properties such as status, assignee, author, label, or review state. In this scenario, the contributor does not need to change the repository or create new tracking items; she just needs to view a smaller, relevant subset of pull requests.
A filter works well here because it can reduce the list to:
That makes filters the best fit for locating relevant work quickly. Other features may help with planning or repository rules, but they do not primarily solve the problem of finding matching issues or pull requests in a list.
Topic: Collaborate Using Github
A teammate opens a pull request to resolve issue #18 and writes Fixes #18 in the pull request description. After the pull request is merged into the repository’s default branch, issue #18 closes automatically.
Which GitHub concept explains this behavior?
Options:
A. Linked issues with a closing keyword
B. Adding the issue and pull request to the same project
C. Branch protection on the default branch
D. Assigning the issue to the pull request author
Best answer: A
Explanation: This scenario describes GitHub issue linking through a closing keyword such as Fixes #18. When the pull request is merged, GitHub recognizes the linked issue and closes it automatically.
The core concept is issue linking between a pull request and an issue. In GitHub, a pull request description can include a closing keyword like fixes, closes, or resolves followed by an issue number. At a foundational level, this tells GitHub that the pull request is intended to complete that tracked work.
When the pull request is merged into the repository’s default branch, GitHub can automatically close the linked issue. This helps teams connect discussion, code changes, and task tracking without needing to close the issue manually.
The key takeaway is that automatic issue closure comes from the pull request’s linked-issue keyword, not from permissions, assignments, or project organization features.
Topic: Collaborate Using Github
A team uses GitHub issues to track work in a private repository. Labels show the type of work, and assignees show who currently owns it. A new issue already has the documentation label. During planning, Jordan says, “I’ll update the setup guide for this issue today.” No code changes have been made yet.
What is the best next step?
Options:
A. Open a pull request for the issue immediately
B. Move the conversation to a GitHub Discussion
C. Change the repository visibility to public
D. Assign the issue to Jordan
Best answer: D
Explanation: The issue already has a label that identifies the work category, so the missing workflow detail is ownership. Assigning the issue to the person who agreed to do the work gives the team clear responsibility and status visibility.
In GitHub, labels and assignees serve different workflow purposes. Labels classify an issue, such as bug, documentation, or priority, while assignees show who is responsible for working on it. Here, the issue is already labeled documentation, and a specific team member has volunteered to handle it, so the next step is to assign that issue to that person.
This helps the team quickly answer two common questions:
Opening a pull request is premature before changes exist, and the other options do not improve issue workflow clarity. The key idea is to use assignment when ownership is the missing information.
Topic: Collaborate Using Github
A contributor updates the README.md file on a branch in a repository. Before the change is added to the default branch, the team wants one place to review the proposed diff, leave comments on specific lines, and discuss whether to merge it.
Which GitHub concept best explains this scenario?
Options:
A. Commit
B. Discussion
C. Issue
D. Pull request
Best answer: D
Explanation: A pull request is the GitHub feature used to propose changes from one branch to another and discuss those exact changes before merging. It supports review comments and collaboration directly on the code or documentation diff.
The core concept is a pull request. In GitHub, a pull request is used when someone has already made changes on a branch and wants others to review, comment, and decide whether those changes should be merged into another branch, such as the default branch. This makes it the right place for conversation about specific code or documentation edits, including line-by-line review comments.
A pull request is more specific than a general conversation tool because it is attached to the proposed changes themselves. That is why teams use it for review and merge decisions, while other features are better for tracking work or holding broader discussions.
Topic: Collaborate Using Github
A documentation contributor writes a short Markdown example she wants to share with people from several GitHub projects. She does not want to add it to any repository, and it is not meant to become long-term project documentation. What should she do next?
Options:
A. Create a Gist for the snippet
B. Open a pull request with the snippet
C. Commit the file to one repository
D. Add the content to a repository wiki
Best answer: A
Explanation: Use a Gist when you need to share a standalone snippet on GitHub without making it part of a repository. The scenario explicitly says the content should not go into repo files and is not intended as wiki-style project documentation.
A Gist is the right GitHub feature for quick, shareable code or text that stands on its own. In this scenario, the contributor wants to share a small Markdown example across several projects, but does not want to place it inside any repository. That rules out committing a repository file or opening a pull request, because both make the content part of a repo workflow. A wiki is also the wrong fit because wikis are for ongoing repository-related documentation, not ad hoc standalone snippets.
A good beginner rule is:
If the content should live separately from a repo, a Gist is usually the best choice.
Topic: Collaborate Using Github
Mia set a repository to Watch during a product launch so she would not miss updates. The launch is over, and she now gets notifications for many issues and pull requests she is not involved in. She still wants updates on one bug report she is helping investigate. What should Mia do?
Options:
A. Open a discussion to ask maintainers not to create as many issues
B. Fork the repository so notifications come only from her copy
C. Unwatch the repository and subscribe only to the specific bug report or pull request
D. Keep watching the repository and ignore the extra notifications
Best answer: C
Explanation: Mia’s problem is that repository-wide watching is too broad for her current needs. The best fix is to stop watching the whole repository and subscribe only to the specific thread she still needs to follow.
On GitHub, watching a repository is for broader repository activity, while subscribing is for following a specific issue, pull request, or discussion. In this scenario, Mia no longer needs updates from the whole repository, so keeping Watch enabled creates unnecessary noise. The better workflow is to reduce repository-level notifications and keep a targeted subscription only on the bug report she is actively helping with.
This is a common notification-management choice:
The key idea is to match the notification scope to the work she is actually doing.
Use the GitHub Foundations GH-900 Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Try GitHub Foundations GH-900 on Web View GitHub Foundations GH-900 Practice Test
Read the GitHub Foundations GH-900 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.