Try 10 focused GitHub Foundations GH-900 questions on Github Projects, 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 | Manage Projects with Github |
| Blueprint weight | 10% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Manage Projects with 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: 10% 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: Manage Projects with Github
A team is planning a product update that includes many related issues and pull requests across two repositories. They want one place to organize the work, assign owners, and view progress in a board or table. Which GitHub concept best fits this scenario?
Options:
A. A project
B. An issue
C. A branch
D. A discussion
Best answer: A
Explanation: A GitHub project is designed to coordinate work across multiple items. It gives teams a shared place to organize issues and pull requests, assign ownership, and track progress with layouts such as boards or tables.
The key idea is coordinating related work across several items, not managing just one task or one line of code. GitHub Projects are meant for planning and tracking work at a broader level, especially when a team wants to collect issues and pull requests in one place and view them in layouts like board or table views.
In this scenario, the team needs to:
That matches a project. A single issue tracks one task, a branch isolates code changes, and a discussion supports conversation rather than structured work tracking.
Topic: Manage Projects with Github
A team uses a GitHub repository to store code, a wiki for setup notes, and discussions for open-ended design conversations. They are starting a release and want the next step to track tasks such as updating docs, reviewing pull requests, and testing fixes, with assignees and progress views in one place. What should they do next?
Options:
A. Create a GitHub Project for the release work
B. Add a new wiki page for each release task
C. List the tasks in the repository README
D. Open a discussion thread for all release tasks
Best answer: A
Explanation: The team needs a work-tracking tool, not a place to store code, long-form documentation, or conversations. GitHub Projects fits because it helps organize tasks, assign owners, and monitor progress across the release.
GitHub Projects is the GitHub feature for planning and tracking work. In this scenario, the team wants to manage release tasks, assign people, and view progress, which matches Projects directly. A repository is mainly where code and related files live. A wiki is better for reference documentation, such as setup instructions or guides. Discussions are better for questions, ideas, and open-ended conversations.
For a beginner workflow, the next step is:
The closest distractor is using discussions, but that helps conversation rather than structured task tracking.
Topic: Manage Projects with Github
A beginner team uses GitHub Issues and pull requests in one repository. They want to quickly mark items as bug, documentation, or urgent so contributors can filter and find related work across both issues and pull requests. Which GitHub feature best meets this need?
Options:
A. Saved replies
B. Assignees
C. Labels
D. Milestones
Best answer: C
Explanation: Labels are the GitHub feature designed to categorize both issues and pull requests. In this scenario, tags like bug, documentation, and urgent help the team organize work and filter for related items quickly.
The core concept is that labels classify work items in GitHub. Teams apply labels to issues and pull requests to show type, priority, status, or area of work, which makes filtering and triage easier.
In this scenario, the team wants to group items using tags such as bug, documentation, and urgent. That is exactly what labels are for:
A milestone groups work by a shared target or deadline, while labels describe what the item is or how it should be treated.
bug or documentation.Topic: Manage Projects with Github
A small product team has already created GitHub issues for features and bugs in a repository. They now want one place to plan the release, assign owners, and move work through stages such as To do, In progress, and Done. What is the best next step?
Options:
A. Start a GitHub Discussion for every task to track progress
B. Create a GitHub Project, choose a board layout, and add the issues
C. Open a pull request for each issue before any work starts
D. Change the repository visibility so everyone can see the tasks
Best answer: B
Explanation: GitHub Projects is the GitHub feature designed for planning and tracking work across items such as issues. A board layout fits the team’s need to move tasks through stages and keep ownership visible in one place.
The key concept is that GitHub Projects provides a planning and tracking space for work, while issues supply the individual tasks. In this scenario, the team already has issues, so the next step is to organize those issues in a project view that shows status and ownership.
A board layout is a strong fit because it lets the team:
A pull request is for proposing code changes, a discussion is for conversation, and repository visibility controls who can access the repo rather than how work is tracked.
Topic: Manage Projects with Github
A new maintainer is triaging a GitHub repository. The team wants to quickly group and filter work by type across both issues and pull requests. One open issue reports a login error, and one open pull request updates the contribution guide.
What is the best next step?
Options:
A. Assign both items to the same maintainer
B. Change the repository visibility to private
C. Create Git branches named bug and docs
D. Apply labels such as bug and documentation to the items
Best answer: D
Explanation: Labels are the GitHub feature used to categorize both issues and pull requests. In this scenario, adding labels like bug and documentation lets the team filter and organize work without changing ownership, code structure, or repository access.
Labels are lightweight tags you add to issues and pull requests to describe what they are, such as a bug, documentation change, enhancement, or priority level. That makes triage easier because teams can quickly filter, search, and report on related work items.
Here, the team wants to group work by type across both an issue and a pull request. Applying a bug label to the login issue and a documentation label to the guide update directly meets that goal. Labels organize the work itself; they do not change who owns it, how the code is branched, or who can view the repository.
The key takeaway is that labels are for categorization, while assignments, branches, and visibility settings serve different purposes.
Topic: Manage Projects with Github
A student team is building a class app in one GitHub repository. They want one place to track tasks such as “To do,” “In progress,” and “Done,” assign work to teammates, and view progress as a board or table during the semester.
Which GitHub feature best fits this need?
Options:
A. GitHub Projects
B. The repository wiki
C. A GitHub Discussion
D. A separate repository
Best answer: A
Explanation: GitHub Projects is the best choice because it is built for planning and tracking work. It lets teams manage tasks, assign ownership, and view progress in layouts such as boards and tables.
The key concept is that GitHub Projects is a work-tracking tool, not just a place to store content or have conversations. In this scenario, the team needs to manage tasks over time, see status changes like “To do” and “Done,” assign work, and review progress visually. That matches GitHub Projects.
A repository mainly stores code and files. A wiki is better for shared documentation. A discussion is better for open-ended conversation or Q&A. When the goal is organizing and tracking project work, GitHub Projects is the intended feature.
Topic: Manage Projects with Github
A maintainer for a GitHub repository triages many new bug issues each week. They keep posting the same comment asking reporters for reproduction steps, expected behavior, and environment details before the issue can be investigated. The team wants a faster, consistent way to send that message in GitHub.
What is the best next step?
Options:
A. Add a needs-info label to each new issue
B. Create a saved reply for the standard information request
C. Create a milestone for issues missing details
D. Enable branch protection on the default branch
Best answer: B
Explanation: The need is repeated communication, not tracking or branch security. A saved reply is the GitHub feature designed to reuse a standard response when maintainers frequently post the same message on issues or pull requests.
This scenario is about sending the same clarification message many times during issue triage. In GitHub, saved replies help maintainers respond faster and more consistently by reusing common text, such as requests for reproduction steps, logs, or environment details.
A label can mark an issue’s status, and a milestone can group work toward a target, but neither one solves the communication problem by itself. Branch protection is a repository safeguard for code changes, not an issue-triage tool. When the goal is to standardize a repeated comment, saved replies are the most direct next action.
The key takeaway is to match the need to the feature: repeated messages use saved replies; tracking and grouping use labels or milestones.
needs-info idea, but it does not provide the reusable message the maintainer keeps typing.Topic: Manage Projects with Github
A team is preparing a release that includes bug fixes in one repository, documentation updates in another repository, and several pull requests already in review. They want one GitHub place to track all of these items together, assign owners, and monitor progress.
What should the team use?
Options:
A. A GitHub Discussion
B. A single issue with a checklist
C. A repository wiki
D. A GitHub Project
Best answer: D
Explanation: Use a GitHub Project when a team needs to coordinate work across multiple items, such as issues and pull requests. Projects give a shared place to organize, assign, and track progress across that work.
The key concept is coordinating related work across multiple GitHub items. A GitHub Project is built for this purpose: it can bring together issues and pull requests, show their status in one place, and help a team manage ownership and progress. That makes it the best fit when work spans more than one item or repository.
A wiki is mainly for documentation, a discussion is for conversation, and a single issue can track one task or hold a simple checklist but does not provide the same project-level coordination view. When a team needs shared tracking across many work items, a project is the right GitHub tool.
Topic: Manage Projects with Github
A small team is using GitHub to manage a documentation sprint. They have several issues and want to see which tasks are To do, In progress, and Done throughout the week. The maintainer wants something better than posting a single status update comment on one issue.
Which GitHub feature is the best fit?
Options:
A. Open a GitHub Discussion for progress notes
B. Add a weekly comment to one issue with the latest team update
C. Create a GitHub Project and track items with a Status field
D. Put the current task list in the repository README
Best answer: C
Explanation: Use a GitHub Project when the goal is to track progress across multiple issues over time. Projects provide structured status tracking, so the team can see work move from planned to active to completed instead of relying on a one-off comment.
The key idea is choosing a tool designed for progress tracking rather than simple communication. A comment on an issue is useful for a point-in-time update about that specific issue, but it does not give the team a structured view of overall work. In this scenario, the team needs to monitor several tasks across the week and see changing states like To do, In progress, and Done.
GitHub Projects is the best fit because it can organize multiple issues in one place and track them with fields such as status. That makes it easier to review progress, spot unfinished work, and manage the sprint visually or in a table.
When the need is ongoing visibility across several items, use a Project instead of relying on a single issue comment.
Topic: Manage Projects with Github
A maintainer of a public repository often replies to new issues with the same message: ask for logs, reproduction steps, and the app version. They want to respond faster while keeping the wording consistent. Which GitHub feature best fits this need?
Options:
A. Labels
B. Milestones
C. Saved replies
D. Assignees
Best answer: C
Explanation: Saved replies are designed for repeated communication. In this scenario, the maintainer needs a fast, consistent way to post the same request on many issues, which is exactly what saved replies provide.
This scenario is about repeated project communication, not categorization or ownership. Saved replies help maintainers insert prewritten responses into issue or pull request comments, which saves time and keeps guidance consistent for contributors.
That makes them a good fit when a team frequently asks for the same details, such as logs, versions, screenshots, or reproduction steps. Labels would organize issues, milestones would group work toward a target, and assignees would show who is responsible, but none of those features solves the repeated-comment problem directly.
Use saved replies when the main goal is faster, standardized communication.
bug or documentation, but they do not provide reusable comment text.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.