Browse Certification Practice Tests by Exam Family

GitHub Foundations GH-900: Github Community

Try 10 focused GitHub Foundations GH-900 questions on Github Community, with explanations, then continue with IT Mastery.

On this page

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

Topic snapshot

FieldDetail
Exam routeGitHub Foundations GH-900
Topic areaExplore the Github Community
Blueprint weight5%
Page purposeFocused sample questions before returning to mixed practice

How to use this topic drill

Use this page to isolate Explore the Github Community for GitHub Foundations GH-900. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.

PassWhat to doWhat to record
First attemptAnswer without checking the explanation first.The fact, rule, calculation, or judgment point that controlled your answer.
ReviewRead the explanation even when you were correct.Why the best answer is stronger than the closest distractor.
RepairRepeat only missed or uncertain items after a short break.The pattern behind misses, not the answer letter.
TransferReturn to mixed practice once the topic feels stable.Whether the same skill holds up when the topic is no longer obvious.

Blueprint context: 5% 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.

Sample questions

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.

Question 1

Topic: Explore the Github Community

A new repository maintainer wants to add a reusable tool that integrates with GitHub for release notes and issue automation. The maintainer has not chosen a vendor yet and only needs to discover available options first. What should the maintainer do next?

Options:

  • A. Open a GitHub Discussion to ask contributors to write the integration

  • B. Browse GitHub Marketplace and review listings that match the need

  • C. Create a pull request that adds vendor-specific configuration files

  • D. Turn on branch protection for the default branch

Best answer: B

Explanation: GitHub Marketplace is used to discover apps and reusable integrations that work with GitHub. When no vendor has been selected yet, the right next step is to browse Marketplace listings and compare options before doing any tool-specific setup.

The core concept is that GitHub Marketplace helps users find tools, apps, and integrations for common GitHub-related needs. In this scenario, the maintainer is still at the discovery stage, so the next step is to look through Marketplace listings, review what each option does, and then decide which one fits the repository.

Starting vendor-specific configuration too early assumes a tool has already been chosen. Branch protection is useful for repository safety, but it does not help discover integrations. Asking contributors to build a custom integration is also unnecessary when the goal is simply to find existing reusable solutions.

Use Marketplace first for discovery; configure a selected tool afterward.

  • Vendor setup too early fails because configuration should come after a tool is chosen.
  • Security control mismatch fails because branch protection is unrelated to discovering Marketplace integrations.
  • Custom build detour fails because the scenario asks for finding existing reusable options, not creating a new integration.

Question 2

Topic: Explore the Github Community

A small team publishes a public GitHub repository for a documentation tool. Within weeks, developers from different companies submit pull requests that fix bugs, improve translations, and add examples the original team had not planned. Which foundational concept best explains the main benefit shown in this scenario?

Options:

  • A. Faster improvement through community contributions

  • B. Branch protection for the default branch

  • C. Private repository access control

  • D. GitHub Sponsors funding

Best answer: A

Explanation: The scenario shows one of the main benefits of open source: people outside the original team can contribute useful changes. That wider pool of contributors often leads to faster fixes, more ideas, and broader project improvement.

Open source collaboration means a project can be improved by a wider community, not just its original creators. In the scenario, outside developers contribute bug fixes, translations, and examples through pull requests. That demonstrates a key open source benefit: many people can help improve quality and add value faster than a small team working alone.

On GitHub, public repositories make this collaboration easier by letting others view the project, suggest changes, and discuss improvements. Pull requests are the mechanism used to propose those changes, but the benefit being tested here is the broader community contribution model itself.

The key takeaway is that open source can accelerate improvement and bring in diverse expertise.

  • Branch protection helps control how changes reach important branches, but it does not describe the benefit of many outside contributors improving the project.
  • Private access control limits visibility and contribution, which is the opposite of the public community collaboration shown.
  • GitHub Sponsors supports maintainers financially, but the scenario is about shared contribution and faster improvement, not funding.

Question 3

Topic: Explore the Github Community

Your team relies on a public open-source project on GitHub. You want to support the maintainer financially using a GitHub feature, without changing any code. What should you do next?

Options:

  • A. Use GitHub Sponsors from the maintainer’s profile or repository.

  • B. Star the repository to start a sponsorship.

  • C. Fork the repository and submit a pull request.

  • D. Open an issue asking how to send money.

Best answer: A

Explanation: GitHub Sponsors is GitHub’s built-in way to financially support eligible maintainers and projects. In this scenario, the correct next step is to use the Sponsor option from the maintainer’s profile or repository.

The core concept is choosing the GitHub feature that matches the goal. GitHub Sponsors is specifically designed to let users provide financial support to open-source maintainers or projects through GitHub. If you want to help financially and not by contributing code, you should use the Sponsor option on the maintainer’s profile or repository.

Other GitHub features serve different purposes. Issues are for discussing bugs, tasks, or questions. Pull requests are for proposing code changes. Stars show interest or appreciation, but they do not provide funding. The key takeaway is to match the action to the intent: use GitHub Sponsors for monetary support.

  • Issue misuse opening an issue asks for support details indirectly, but GitHub Sponsors is the direct GitHub feature for funding.
  • Code contribution forking and submitting a pull request helps improve the project, but it is not a financial support step.
  • Star confusion starring a repository shows interest and can help visibility, but it does not create a sponsorship.

Question 4

Topic: Explore the Github Community

A company keeps a repository named service-starter with a standard README, LICENSE, issue templates, and folder structure. New teams often need their own separate repositories that begin with this same setup, but they should not inherit the starter repository’s commit history or stay linked to it. What should the repository owner do next?

Options:

  • A. Mark service-starter as a template and create new repositories from it

  • B. Fork service-starter whenever a team begins a new project

  • C. Ask each team to manually copy the starter files into a new repository

  • D. Create a new branch in service-starter for each team

Best answer: A

Explanation: A template repository is the right choice when many new repositories should start from the same reusable structure. It gives each team an independent repository while avoiding the extra connection and history expectations that come with a fork.

The key concept is choosing a reusable starting point for new, separate repositories. In this scenario, teams need the same initial files and layout, but each project should stand on its own. That is exactly when a template repository is appropriate on GitHub.

A good beginner rule is:

  • Use a template when you want a repeatable starter structure.
  • Use a fork when you want to work from another repository while keeping a relationship to that source.
  • Use branches when the work belongs inside one repository, not across separate repositories.

Manual copying can work, but it is not the best GitHub process for repeatable setup. The main takeaway is that templates are for creating new repositories from a shared pattern.

  • Fork confusion is tempting, but forks are better for working from an existing repository rather than creating a standard starter for many separate repos.
  • Branch reuse fails because branches keep all work inside one repository, while the teams need independent repositories.
  • Manual copying is possible, but it skips the built-in GitHub feature made for reusable repository structure.
  • Template use matches the stated need for repeatable setup without treating the new project as ongoing work in the original repo.

Question 5

Topic: Explore the Github Community

Maya is exploring open-source documentation projects on GitHub. She finds several useful public repositories from the same organization and wants an easy way to keep up with that group’s public activity over time, not just save one project for later. What should she do next?

Options:

  • A. Watch one repository

  • B. Star the repositories

  • C. Follow the organization

  • D. Fork a repository

Best answer: C

Explanation: Maya wants to track a group’s broader public activity, not just bookmark a single project. Following an organization matches that discovery goal on GitHub better than watching, starring, or forking a repository.

The key concept is matching the GitHub action to the discovery need. When someone wants to keep up with a group behind multiple public repositories, following the organization is the most appropriate step. That choice helps them stay aware of the organization’s public activity as a community participant.

Watching is centered on updates for a specific repository. Starring is mainly a way to bookmark or show appreciation for repositories. Forking creates a copy for independent work and is not a discovery feature.

A good beginner rule is: follow people or organizations for broader activity, and watch repositories for updates to one project.

  • Watch one repo is too narrow because it focuses on a single repository instead of the whole group.
  • Star repositories helps save or endorse projects, but it does not primarily track an organization’s activity.
  • Fork a repository is for making your own copy to work on, not for community discovery.

Question 6

Topic: Explore the Github Community

A repository admin wants to add a ready-made integration that extends GitHub by automatically labeling new issues and connecting to an external service. The team does not want to build a custom tool. What is the best next step?

Options:

  • A. Create a new Git branch to enable the integration

  • B. Change the repository visibility to public so integrations will work

  • C. Open a repository discussion so contributors can label issues manually

  • D. Search GitHub Marketplace for an app or tool that fits the need

Best answer: D

Explanation: GitHub Marketplace is relevant when a team wants to extend GitHub with a prebuilt app or integration. In this case, the admin needs added functionality without custom development, so looking in Marketplace is the most appropriate next action.

GitHub Marketplace helps users discover and install reusable apps, tools, and integrations that add capabilities to GitHub. When a team wants to connect GitHub to another service or automate a task without writing its own solution, Marketplace is the natural place to start.

In this scenario, the requirement is clear: add existing functionality, not build from scratch. That makes a Marketplace search the best next step because it helps the admin evaluate available extensions that already support the workflow.

A branch is for organizing code changes, a discussion is for conversation, and repository visibility controls who can see the repo. None of those actions directly help the team find and adopt a reusable extension.

  • Using a branch confuses source control work with finding a reusable GitHub extension.
  • Starting a discussion may gather opinions, but it does not locate or install an existing integration.
  • Changing visibility is a repository access decision, not the normal way to add GitHub functionality.

Question 7

Topic: Explore the Github Community

A student developer club maintains reusable Markdown templates and example workflows. The club wants anyone on GitHub to see how the files change over time, reuse them in other projects, and suggest improvements. The content contains no sensitive data. Which action best supports these goals?

Options:

  • A. Store the files in a private Gist

  • B. Put the project in a public GitHub repository

  • C. Keep the repository private and email ZIP files

  • D. Publish only a GitHub Pages site for the project

Best answer: B

Explanation: A public GitHub repository is the best fit because it supports transparent history, easy reuse, and open contribution workflows. People can view commits, fork or copy the project, and participate through issues and pull requests.

The core idea is that public collaboration on GitHub increases visibility and lowers the barrier for reuse and contribution. A public repository lets anyone inspect the project’s commit history for transparency, copy or fork the contents for reuse, and propose changes through issues and pull requests. That combination directly matches the club’s goals.

If the material is safe to share publicly, a public repository is the standard GitHub approach for community participation. Adding files such as README, LICENSE, and CONTRIBUTING can make reuse and contributions even clearer, but the key decision is making the repository public rather than keeping the work restricted or publishing only a finished output.

The closest distractor is a public Pages site, which helps with viewing content but does not provide the same repository-centered collaboration experience.

  • Private sharing fails because emailed ZIP files do not provide public transparency or a normal GitHub contribution path.
  • Pages only helps people read published content, but it is not the main place for code reuse and contribution workflows.
  • Private Gist is limited and hidden from the broader community, so it does not support open collaboration well.

Question 8

Topic: Explore the Github Community

A repository maintainer wants to add a tool that can automatically label new issues. The team has not chosen a vendor yet and first wants to discover GitHub-compatible options and read summary details before deciding. What is the best next step?

Options:

  • A. Search GitHub Marketplace for issue-labeling apps and compare listings.

  • B. Make the repository public so tools can connect to it.

  • C. Run local Git commands to find supported GitHub integrations.

  • D. Open a pull request with one vendor’s configuration files.

Best answer: A

Explanation: When a team needs to discover GitHub-compatible tools before picking one, GitHub Marketplace is the right starting point. It is designed for browsing and comparing available apps and integrations, not for doing vendor-specific setup first.

The core concept is discovery. GitHub Marketplace helps users find GitHub-integrated apps, actions, and other reusable tools, then review their purpose before deciding whether to install or configure them. In this scenario, the team has not selected a vendor yet, so the best next action is to browse Marketplace listings for issue-labeling options.

A good beginner flow is:

  • identify the need
  • search GitHub Marketplace
  • compare listings and permissions
  • choose a tool, then follow its setup steps

Using Git commands would not discover Marketplace integrations, and changing repository visibility is unrelated. Jumping straight to a pull request with one vendor’s config skips the discovery step the team explicitly wants.

  • Git vs. GitHub fails because Git commands manage version control, not Marketplace discovery.
  • Wrong setting fails because repository visibility does not need to change just to browse available tools.
  • Too early to configure fails because adding one vendor’s files comes after the team has reviewed and chosen an option.

Question 9

Topic: Explore the Github Community

A small team maintains a public GitHub repository. They want new pull requests to be labeled automatically and first-time contributors to receive a welcome message. The team wants the fastest, lowest-maintenance approach and does not want to build and host its own service.

What is the best next step?

Options:

  • A. Write a custom Git hook and ask every contributor to install it locally

  • B. Create a GitHub Discussion telling contributors to add labels manually

  • C. Review GitHub Marketplace for an existing app or action that provides PR labeling and contributor greetings

  • D. Change the repository visibility to private before adding automation

Best answer: C

Explanation: When a team needs common GitHub functionality quickly, a reusable app or action is usually better than building a custom process from scratch. GitHub Marketplace is designed to help teams find existing integrations and tools for common repository tasks.

The key concept is choosing a reusable community resource when the requirement is common, the team wants low maintenance, and there is no need for a custom-built solution. Automatic labeling and greeting contributors are standard GitHub workflow tasks, so the best next action is to check GitHub Marketplace for an existing app or action that already does this.

A good beginner decision process is:

  • Look for an existing Marketplace integration or reusable action.
  • Confirm it matches the repository need.
  • Review its permissions and maintenance status before using it.

Building a custom bot or service adds extra work to create, host, secure, and maintain it. Manual communication or unrelated repository settings do not solve the automation requirement.

  • Local Git hook fails because local hooks are not a GitHub-wide reusable solution and depend on every contributor installing them.
  • Discussion post is collaboration guidance, not automation, so it does not meet the low-maintenance workflow goal.
  • Repository visibility is unrelated because changing public or private access does not add labeling or greeting behavior.

Question 10

Topic: Explore the Github Community

A new contributor finds an open-source maintainer on GitHub and wants to see that maintainer’s public activity over time. They do not want notifications limited to one bug report or one pull request. What is the best next step?

Options:

  • A. Clone the repository with Git

  • B. Subscribe to the issue where the maintainer last commented

  • C. Watch the maintainer’s repository

  • D. Follow the maintainer’s GitHub profile

Best answer: D

Explanation: Following is used to keep up with a person’s public activity on GitHub. Subscribing is narrower and applies to notifications for a specific issue or pull request.

The key distinction is person-level activity versus thread-level notifications. If someone wants updates about a maintainer’s public work across GitHub, the right action is to follow that user’s profile. If they only wanted alerts about comments and changes on one issue or one pull request, subscribing to that specific thread would fit instead.

Watching a repository is broader than a single issue, but it is still repository-focused rather than person-focused. Cloning a repository uses Git to copy files locally and does not control GitHub notification behavior.

When the goal is to track a person’s public activity, follow the user; when the goal is to track one conversation, subscribe to that issue or pull request.

  • Subscribing is too narrow because it only tracks notifications for one specific issue or pull request.
  • Watching targets a repository rather than the maintainer’s activity across GitHub.
  • Cloning is local access to repository contents, not a GitHub community notification feature.

Continue with full practice

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

Free review resource

Read the GitHub Foundations GH-900 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.

Revised on Thursday, May 14, 2026