Prepare for GitHub Foundations (GH-900) with free sample questions, a full-length diagnostic, topic drills, timed practice, Git basics, repositories, pull requests, issues, collaboration workflows, project management, security, and detailed explanations in IT Mastery.
GitHub Foundations validates foundational understanding of GitHub products, collaboration, contribution workflows, repositories, Git basics, project management, security, administration, and community concepts.
IT Mastery practice for GitHub Foundations (GH-900) is live now. Use this page to start the web simulator, review the exam snapshot, work through 24 public sample questions, and continue into full IT Mastery practice with the same IT Mastery account on web, iOS, iPadOS, macOS, or Android.
Start a practice session for GitHub Foundations (GH-900) below, or open the full app in a new tab. For the best experience, open the full app in a new tab and navigate with swipes/gestures or the mouse wheel—just like on your phone or tablet.
Open Full App in a New TabA small set of questions is available for free preview. Subscribers can unlock full access by signing in with the same app-family account they use on web and mobile.
Prefer to practice on your phone or tablet? Download the IT Mastery – AWS, Azure, GCP & CompTIA exam prep app for iOS or IT Mastery app on Google Play (Android) and use the same IT Mastery account across web and mobile.
Free diagnostic: Try the GitHub Foundations GH-900 full-length practice exam before subscribing. Use it as one GitHub basics baseline, then return to IT Mastery for timed mocks, topic drills, explanations, and the full GH-900 question bank.
| Area | What to practise |
|---|---|
| Git and GitHub basics | version control, commits, branches, repositories, remotes, and core GitHub vocabulary |
| Repositories | repository structure, issues, pull requests, discussions, releases, and visibility |
| Collaboration | forks, branches, reviews, comments, merge behavior, and contribution workflows |
| Modern development | project boards, GitHub Pages, packages, Codespaces awareness, and community workflows |
| Privacy, security, and administration | account security, repository permissions, organizations, and basic governance |
Most GitHub Foundations questions test whether you understand the basic path from local work to shared review. Keep this workflow straight before memorizing isolated terms.
flowchart LR
Clone["Clone or open repo"] --> Branch["Create branch"]
Branch --> Commit["Commit changes"]
Commit --> Push["Push branch"]
Push --> PullRequest["Open pull request"]
PullRequest --> Review["Review and checks"]
Review --> Merge["Merge"]
Merge --> Release["Release or deploy"]
GitHub Foundations questions usually use small, practical exhibits: a repository screen, pull request state, issue thread, branch list, or workflow check result. Start by identifying the GitHub object in the exhibit, then choose the action that matches the normal collaboration workflow.
| Exhibit type | What to recognize |
|---|---|
| Repository file list | the repository is the project container for code, history, issues, pull requests, and releases |
| Branch list | work can be isolated before merging into the default branch |
| Pull request status | review comments, checks, conflicts, and approvals affect merge readiness |
| Issue thread | discussion, bug reporting, and task tracking can happen before code changes |
| Fork notice | external contributors can propose changes without direct write access |
| Release page | a versioned package can include notes, tags, and downloadable assets |
Example pull request exhibit:
Pull request: Add password reset email template
Checks: 1 failing
Review: changes requested
Merge button: disabled
Best reading: the pull request is not ready to merge. The contributor should address the failing check and review feedback, then request review again.
Example issue exhibit:
Issue title: Login page returns 500 for locked accounts
Labels: bug, needs-triage
Assignee: unassigned
Linked pull request: none
Best reading: this is an issue, not a code change yet. The next step is triage, reproduction, assignment, or discussion before a pull request is opened.
Example branch exhibit:
| Branch | Meaning |
|---|---|
main | default branch used for reviewed work |
feature/reset-email | isolated feature work before review |
hotfix/login-error | focused fix branch that should still go through the repository’s review rules |
Use these filters when the answer is about normal GitHub workflow rather than memorized vocabulary:
| Day | Practice focus |
|---|---|
| 7 | Take the free full-length diagnostic and tag misses by Git, repository, collaboration, security, or community topic. |
| 6 | Drill Git basics, commits, branches, remotes, repositories, forks, and GitHub vocabulary. |
| 5 | Drill pull requests, reviews, checks, merge behavior, conflicts, issues, and discussions. |
| 4 | Drill project management, releases, packages, Codespaces awareness, GitHub Pages, and modern development basics. |
| 3 | Drill privacy, security, repository visibility, permissions, organizations, and administration basics. |
| 2 | Complete a timed mixed set and explain the GitHub object or workflow step behind each miss. |
| 1 | Review weak workflow terms; avoid memorizing isolated interface labels without context. |
If several unseen mixed attempts are above roughly 75% and you can explain the GitHub object, permission boundary, or collaboration step behind your misses, you are likely ready. Further practice should improve workflow fluency, not simply repeat definitions.
Use these child pages when you want focused IT Mastery practice before returning to mixed sets and timed mocks.
Need concept review first? Read the GitHub Foundations GH-900 Cheat Sheet on Tech Exam Lexicon, then return here for timed mocks, topic drills, and full IT Mastery practice.
These are original IT Mastery practice questions aligned to the live GitHub Foundations (GH-900) route and the main blueprint areas shown above. Use them to test GitHub vocabulary, collaboration workflow, repository, pull request, security, and automation basics here, then continue in IT Mastery with mixed sets, topic drills, and timed mocks.
Topic: Apply Modern Development Practices
A developer uses GitHub Copilot in a Codespace to generate a new input-validation function for a web app. The code compiles, and the work is still on a feature branch in a repository that follows GitHub Flow. What should the developer do next before creating or merging a pull request?
Best answer: A
Explanation: GitHub Copilot assists with code generation, but it does not replace human judgment. The right next step is to review the generated code and validate it with testing before moving forward in the pull request workflow. Copilot is an AI coding assistant, not an approval or verification system. Even if generated code compiles, it can still contain logic errors, insecure patterns, or behavior that does not match the actual requirement. In a beginner GitHub workflow, the safe next step is to check the suggestion yourself and validate it with tests before opening or merging a pull request.
A good pattern is:
Compilation alone is not enough, and Copilot output should always receive human review.
Topic: Manage Projects with GitHub
A repository maintainer often posts the same response on issues and pull requests: thanking contributors, asking for reproduction steps, and linking the CONTRIBUTING.md file. The maintainer wants a GitHub feature that lets them quickly reuse that message instead of retyping it each time.
Which GitHub concept best matches this scenario?
Best answer: C
Explanation: Saved replies are reusable comment responses for common messages in GitHub conversations. In this scenario, the maintainer wants to quickly post the same guidance in multiple issues and pull requests, which is exactly what saved replies are for. The core concept is saved replies. They help streamline repeated communication by storing common response text that can be inserted into issue and pull request comments. That fits this scenario because the maintainer repeatedly shares the same thank-you note, troubleshooting request, and documentation link.
Saved replies are useful when you often post messages such as:
This is different from tools that organize work or guide contributors before they submit something. Here, the need is faster reuse of a comment during ongoing collaboration.
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?
Best answer: A
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: Work with GitHub Repositories
A new maintainer inherits a GitHub repository. Before planning maintenance work, they want a quick, high-level view of the project’s dependencies without manually reading every package file.
What should they do next?
Best answer: C
Explanation: Dependency insights helps maintainers quickly understand a repository’s dependencies at a high level. It is the most direct GitHub feature for visibility into dependency information before deciding on maintenance actions. The core concept is choosing the GitHub feature that gives dependency visibility without extra manual work. For a beginner maintainer who wants a quick overview, dependency insights is the right next step because it is meant to surface dependency information in the repository context.
Using an issue would only ask people to provide information manually. Reviewing pull requests can show past changes, but it does not give a simple current overview of dependencies. Stars and traffic metrics help with repository popularity and usage, not dependency understanding.
When the goal is high-level dependency visibility, start with dependency insights rather than communication or activity tools.
Topic: Understand Git and GitHub Basics
A developer has already created a branch and committed changes locally. The team now wants a way to review those changes on GitHub, discuss them, and approve them before merging into main. Which concept best explains this step?
Best answer: D
Explanation: This scenario goes beyond basic Git operations. The branch and commits already exist; the missing step is GitHub-based collaboration for review and approval, which is handled by a pull request. Git provides core version control operations such as creating branches and making commits. GitHub builds on Git by adding collaboration features around those changes. In this scenario, the developer has already done the Git work locally, so the remaining need is not another Git operation. The team wants reviewers to examine the branch changes, leave comments, and approve them before merging into main, which is the purpose of a pull request on GitHub. An issue can track work, but it does not provide the review-and-merge workflow for code changes.
Topic: Understand Privacy, Security, and Administration
A GitHub organization has a repository that only organization members can currently see. The owner wants people outside the organization to view the repository without being added to any team. Which foundational GitHub concept best explains what must change?
Best answer: B
Explanation: This scenario is about who can see the repository at all, not which group someone belongs to inside the organization. That is controlled by repository visibility, such as private or public access. The core concept here is repository visibility. Visibility determines the audience that can see a repository, such as whether it is limited to specific users or available more broadly. In the scenario, the owner wants people outside the organization to view the repository without being added to a team, so the needed change is about the repository’s visibility setting, not team structure.
Team membership is used to organize people and grant access more efficiently within an organization, but it does not by itself make a repository visible to everyone outside the organization. Branch protection controls how changes reach important branches, and pull request review controls collaboration on proposed changes. Neither one changes who can see the repository in the first place.
Key takeaway: visibility answers “who can see it,” while team membership answers “who belongs to this group.”
Topic: Explore the GitHub Community
Your company uses GitHub Enterprise Cloud with internal repositories enabled. A platform team keeps shared automation scripts in a private repository in one organization. Teams across the company want to find the repository in GitHub and reuse its contents, but the code must stay unavailable to the public.
What is the best next step?
Best answer: A
Explanation: The team needs broader discoverability inside the company without exposing the repository publicly. Changing visibility to internal matches that goal because it supports finding and reusing the repository within the enterprise. Repository visibility controls who can find and access a repository. In this scenario, the current private setting limits discoverability to people who already have access, which works against collaboration and reuse across the company. Making the repository internal is the GitHub setting designed for sharing within the enterprise while still keeping the repository off the public internet.
A template repository can help people create new repositories from an existing one, but it does not solve the visibility problem by itself. Discussions help communication, and sharing copied files bypasses GitHub’s collaboration features. The key point is to first choose the visibility setting that makes the repository discoverable to the intended internal audience.
Topic: Apply Modern Development Practices
A new contributor spots a typo in a repository README.md and wants to fix it directly from a web browser on a locked-down laptop. They do not need to run the app, install dependencies, or use AI suggestions. Which GitHub tool is the best fit?
Best answer: D
Explanation: github.dev is the best choice for lightweight editing in the browser. The scenario is specifically about a quick file change without setup, runtime access, or AI assistance, which matches github.dev rather than automation, coding assistance, or a full cloud environment. The key concept is choosing the GitHub tool that matches the job. Here, the user only needs to make a small edit to a repository file from the browser. github.dev is intended for lightweight, web-based editing, so it fits a quick documentation fix especially well.
By contrast:
When the need is simply “open the repo in the browser and edit a file,” github.dev is the most appropriate tool.
Topic: Manage Projects with GitHub
A team wants one place in GitHub to track work across several repositories, organize items by status, switch between board and table layouts, and see overall progress for a release. Which foundational GitHub concept best matches this need?
Best answer: B
Explanation: GitHub Projects is the feature used to organize and track work at a higher level. It can bring together items such as issues and pull requests, then show them in layouts like boards or tables for planning and progress tracking. The key clue is the need for a single tracking space across multiple repositories with flexible layouts and release progress visibility. GitHub Projects fits that scenario because it is built for planning and tracking work, not just recording one task or reviewing one code change. A project can include items from issues and pull requests, and teams can organize them with fields such as status, priority, or release.
This makes Projects the best match when the goal is to:
Issues are individual work items, pull requests are for proposing code changes, and discussions are for open-ended conversations rather than structured tracking.
Topic: Collaborate Using GitHub
A student team stores its documentation in a GitHub repository. One member updates the README.md on a branch, and the team wants to review the exact changes, leave comments on specific lines, and approve the update before it is added to main.
Which GitHub feature is the best choice?
Best answer: B
Explanation: A pull request is the GitHub collaboration surface for proposed code or documentation changes. It lets reviewers see the diff, comment on specific lines, and approve the branch before merging it into main. Pull requests are built for reviewing and discussing changes before they become part of a repository. In this scenario, the team already has a branch with README edits and wants conversation tied directly to the changed lines, plus an approval step before merging. That matches the purpose of a pull request.
A pull request typically supports:
An issue or discussion can talk about ideas, but they do not center the conversation on a proposed set of repository changes in the same way. The key clue is the need to review and approve specific documentation edits before merging.
Topic: Work with GitHub Repositories
A repository maintainer wants security researchers to know how to privately report vulnerabilities, which versions are supported, and what response process to expect. Which GitHub repository concept best fits this need?
Best answer: C
Explanation: The SECURITY file is used to communicate security reporting instructions for a repository. It helps contributors and researchers report vulnerabilities through the right channel instead of using normal collaboration tools like issues. The core concept is the repository SECURITY file. In GitHub repositories, this file is meant to provide security-specific guidance such as where to report vulnerabilities privately, which releases are supported, and what maintainers expect during disclosure. That makes it the right fit when the goal is secure reporting guidance rather than general project information.
A README explains the project, a CONTRIBUTING file explains how to participate, and CODEOWNERS identifies who reviews or owns paths in the repo. Those files support collaboration, but they do not primarily communicate vulnerability reporting instructions. The key takeaway is that security reporting guidance belongs in the SECURITY file.
Topic: Understand Git and GitHub Basics
Rina initialized a repository on her laptop, created a branch, and made several commits while offline. After reconnecting, she wants teammates to review her changes, leave comments, and approve them before the changes reach main. Which action depends on GitHub’s hosted collaboration features rather than local Git alone?
Best answer: B
Explanation: Git handles local version-control tasks such as creating branches, recording commits, and viewing history on your machine. GitHub adds hosted collaboration features, so asking teammates to review and approve changes is done through a pull request in the remote repository. The core distinction is that Git is the version-control system, while GitHub is a hosted platform built around sharing and collaborating on Git repositories. In this scenario, Rina already used Git locally by creating a branch and making commits offline. The moment she needs teammates to review, comment, and approve her work before it is merged, she is using a GitHub collaboration workflow.
A pull request is the GitHub feature that supports that process:
By contrast, local branching, local commits, and local history viewing are core Git activities that do not require GitHub. The key takeaway is that Git manages changes locally, while GitHub enables team collaboration around those changes.
Topic: Understand Privacy, Security, and Administration
A maintainer of a GitHub repository wants a new volunteer to help label issues, assign them, and close duplicate issues. The volunteer does not need to push code, merge pull requests, or change repository settings. Which access level is the safest choice?
Best answer: D
Explanation: The safest choice is the role that gives only the permissions needed for the task. Because the volunteer only needs to manage issues, Triage follows least-necessary access and avoids the extra risk that comes with broader repository control. Least-necessary access means giving someone only the permissions required to do their job. In this scenario, the volunteer needs issue-management capabilities, not code contribution or administrative control. The Triage role is designed for managing issues and pull request metadata without allowing code pushes or repository setting changes.
Granting broader access than necessary increases risk. Roles like Write, Maintain, or Admin can allow actions the volunteer does not need, such as pushing code, merging changes, or changing repository configuration. Using the narrowest suitable role reduces the chance of accidental or unauthorized changes while still letting the person contribute effectively.
The key takeaway is to match the GitHub role to the actual task, not to grant convenience-based admin access.
Topic: Explore the GitHub Community
A beginner contributor finds a public open-source repository on GitHub. They want notifications only about one pull request that updates the project README. They do not want notifications about the maintainer’s other activity or the whole repository.
Which GitHub action best fits this need?
Best answer: D
Explanation: Subscribing is the GitHub action used to receive notifications for one specific issue or pull request. Following is different because it tracks a user’s public activity more broadly, not updates to a single conversation. On GitHub, following and subscribing serve different purposes. Following a user lets you see that person’s public activity, such as repositories they create or contribute to. Subscribing is narrower: it sends notifications for updates to one specific issue or pull request.
In this scenario, the contributor wants updates only for one README pull request and does not want broader maintainer or repository notifications. That makes subscribing the right choice.
Watching is too broad because it applies to repository activity, while starring is mainly for bookmarking or showing interest.
Topic: Apply Modern Development Practices
Mina notices a broken link in README.md while viewing her team’s repository in a browser. She only needs to fix that Markdown file and open a pull request. She does not need a terminal, extensions, or to run the application. What should she do next?
Best answer: D
Explanation: github.dev is the right fit for a quick browser-based documentation edit when no local setup, terminal, or app execution is needed. In this case, Mina can make the small Markdown change directly, commit it on a branch, and open a pull request. The key concept is choosing the lightest GitHub tool that still meets the task. For a small edit to README.md, github.dev is enough because it provides fast, in-browser editing without creating a full cloud development environment.
A Codespace is more appropriate when you need to run, build, debug, or use a fuller development setup.
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?
Best answer: A
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: Collaborate Using GitHub
A team uses GitHub issues to track work and requires review before changes reach main. Priya is assigned issue #42, creates a branch, updates the files, commits her changes, and pushes the branch to GitHub. The team also wants issue #42 to close automatically after the change is accepted.
What should Priya do next?
#42 describing the completed changesmain directly and then comment on issue #42main and reference issue #42Best answer: D
Explanation: A pull request is more appropriate when code or file changes are ready to be reviewed and merged. In this case, Priya already made the changes on a branch, and the team wants both review and automatic issue closure, which a linked pull request supports. Issues are used to track work, questions, or bugs, but they do not themselves propose branch changes for merge. Once Priya has finished the work on her branch, the next GitHub Flow step is to open a pull request into main.
A pull request helps the team:
#42If the pull request references the issue, such as with a closing keyword, GitHub can automatically close the issue after the pull request is merged. A comment on the issue can describe progress, but it does not replace the review-and-merge process. The key distinction is that issues track the work, while pull requests propose and review the change itself.
Topic: Work with GitHub Repositories
A public repository is getting many first-time contributions. The maintainers want one standard place to explain how to submit issues, follow coding conventions, and prepare pull requests. Which repository file is intended for this purpose?
Best answer: A
Explanation: A CONTRIBUTING file is used to guide people who want to help with a repository. It typically explains contribution rules, workflows, and expectations such as issue reporting, coding style, and pull request steps. The core concept is the purpose of key repository files. When maintainers want to tell contributors how to participate in a project, the correct file is CONTRIBUTING. It helps set expectations for submitting issues, proposing changes, following coding standards, and opening pull requests, which makes collaboration more consistent and easier for new contributors.
Other common files serve different roles: README introduces the project, LICENSE explains usage rights, and CODEOWNERS identifies who reviews or owns parts of the codebase. If the goal is contributor guidance rather than project overview, legal terms, or ownership, CONTRIBUTING is the best fit.
Topic: Understand Git and GitHub Basics
A startup wants its main GitHub repository to be owned by the company instead of by one developer’s login. Several team members need access, and permissions should continue even if an employee leaves. Which GitHub concept best fits this need?
Best answer: C
Explanation: A GitHub organization is designed for shared ownership and team-based access. It keeps repositories under the company rather than tying them to one individual’s personal account. The core concept is repository ownership scope. When a repository should belong to a company or team, not to one person, a GitHub organization is the best fit. Organizations support multiple members, team-based permissions, and continuity if an employee leaves.
A personal account is centered on one user. An enterprise account is typically used to manage multiple organizations and broader administrative policies at a larger scale. A fork is just a copy of a repository for separate work; it does not solve shared company ownership.
For this scenario, the requirement is shared ownership with managed access, which matches an organization.
Topic: Understand Privacy, Security, and Administration
An organization has a private GitHub repository for onboarding docs. Team members can currently push changes directly to main, but the repository admin wants changes to reach main only after a pull request review and to prevent direct pushes. Which GitHub feature best meets this requirement?
mainBest answer: A
Explanation: This is a change-control requirement, not an access-visibility requirement. Branch protection on main is the GitHub feature used to require pull request reviews and prevent direct pushes to that branch. Branch protection is used when a team wants to control how changes reach an important branch such as main. In this scenario, the repository is already private, so visibility is not the issue. The requirement is to stop direct pushes and require review first, which maps directly to branch protection rules.
With branch protection, a repository admin can configure rules such as:
Changing visibility only affects who can see the repository, not how changes are merged. The key takeaway is to use repository visibility for access scope and branch protection for change control.
Topic: Explore the GitHub Community
A maintainer runs a popular public open-source GitHub repository. Several users say the project is valuable and ask for a GitHub-based way to help fund ongoing maintenance. The maintainer wants to accept community financial support without changing how people report issues or contribute code.
What is the best next step?
Best answer: C
Explanation: When the goal is community financial support for an open-source project on GitHub, GitHub Sponsors is the intended solution. It lets maintainers receive support without changing repository visibility or replacing normal contribution tools like issues and pull requests. This scenario is about funding open-source maintenance, not changing collaboration workflow. GitHub Sponsors is the GitHub feature built specifically to let users financially support maintainers and open-source projects. That matches the stated need: a GitHub-native way to help fund ongoing work while keeping the repository public and keeping issues and code contributions unchanged.
In contrast, collaboration features such as Discussions help conversation, not funding. Repository visibility settings control who can access the code, not how supporters contribute money. Stars and forks can increase visibility or enable contribution, but they do not provide financial support.
The key takeaway is to choose GitHub Sponsors when the community wants to support a project financially on GitHub.
Topic: Apply Modern Development Practices
A developer is using GitHub Copilot in a repository and asks it to investigate a failing test, update the relevant files, and keep working through the task until it can propose a complete fix. Which Copilot capability concept best explains this behavior?
Best answer: B
Explanation: This scenario describes Copilot acting on a task across multiple steps, not just offering a one-time completion. That foundational capability is Agent Mode. Agent Mode is the Copilot concept for more autonomous, multi-step assistance. In this scenario, Copilot is not just suggesting a line of code; it is investigating the problem, considering repository context, and continuing through the task to prepare a fuller fix. That matches Agent Mode.
Multi-model support is about choosing among different underlying AI models for different needs. Copilot agents is a broader concept about agent-based AI help, but the stem specifically focuses on the mode where Copilot iterates through a task. GitHub Actions automates workflows such as build and test runs, but it is not the Copilot capability being described here.
The key takeaway is to distinguish autonomous task execution behavior from model choice or workflow automation.
Topic: Manage Projects with GitHub
Your team already has issues in two repositories: web-app and api. The team lead wants one place to track all work, sort items by assignee, view status, and add a custom Target release field. What is the best next step in GitHub?
Best answer: C
Explanation: GitHub Projects is the right tool for organizing and tracking work across repositories. A table layout fits this need because the team wants sortable tracking plus a custom Target release field in one shared workspace. GitHub Projects is designed for planning and tracking work items such as issues in a central workspace. In this scenario, the team needs cross-repository tracking, sortable views, visible status, and a custom field, which maps directly to a project rather than to a discussion, milestone, or labels alone.
Target release.A milestone is useful for grouping work, but it does not replace a shared project view across multiple repositories.
Topic: Collaborate Using GitHub
A student project stores index.html, CSS, and Markdown documentation in a GitHub repository. The team wants to publish that content as a simple website directly from the repository and have updates appear when the site content changes. Which GitHub feature best fits this need?
Best answer: B
Explanation: GitHub Pages is the GitHub feature for publishing static web content from a repository. It is intended for sites such as project pages, documentation, and simple websites backed by repository files. GitHub Pages is used when repository content should be published as a static website. In this scenario, the team already has web-ready files like HTML, CSS, and Markdown in a repository, so GitHub Pages is the direct fit. It connects a site to repository content and serves that content as a web page.
A wiki is for collaborative documentation editing inside GitHub, a Gist is for sharing small code or text snippets, and Discussions is for conversations. Those features support collaboration, but they are not the primary way to publish a static site from a repository.
The key idea is that GitHub Pages turns repository content into a browsable website.
| Need | GitHub concept |
|---|---|
| Store code and project collaboration | Repository |
| Record a snapshot of changes | Commit |
| Isolate work before merge | Branch |
| Propose and review changes | Pull request |
| Report bugs or track tasks | Issue |
| Contribute without write access | Fork and pull request |
| Publish versioned software | Release and tag |
| Automate checks and workflows | GitHub Actions |
| Limit repository visibility | Private or internal repository |
| Protect account login | Two-factor authentication |