Try 10 focused GitHub Foundations GH-900 questions on Repositories, 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 | Work with Github Repositories |
| Blueprint weight | 15% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Work with Github Repositories 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: Work with Github Repositories
A maintainer wants to understand activity in a GitHub repository by reviewing information such as traffic trends, contributor activity, and overall repository engagement over time. Which GitHub concept best fits this need?
Options:
A. GitHub Projects
B. Branch protection
C. Repository insights
D. GitHub Discussions
Best answer: C
Explanation: Repository insights are used to review repository activity and maintenance data. They help maintainers understand patterns such as traffic, engagement, and contribution trends without relying only on issues or pull requests.
The core concept is repository insights. In GitHub, insights help maintainers examine how a repository is being used and maintained by showing activity-oriented information such as traffic and contribution patterns. That makes insights useful when the goal is to understand repository activity over time rather than to plan work, discuss ideas, or protect branches.
A maintainer would use insights when they want to answer questions like whether interest in the repository is increasing, whether contributors are active, or how the repository is being engaged with overall. By contrast, collaboration tools like discussions and projects support communication or tracking work, not activity analysis.
Topic: Work with Github Repositories
A student team publishes a public GitHub repository for a class project. Visitors keep asking what the project does, how to run it, and where to start. The team wants one file that appears with the repository and explains this basic information to new users.
Which file should they create or update?
Options:
A. LICENSE
B. CONTRIBUTING.md
C. SECURITY.md
D. README.md
Best answer: D
Explanation: A README.md is meant to introduce the repository to anyone who visits it. It commonly explains what the project is, how to get started, and any basic usage or setup steps.
The core purpose of a README.md file is to explain the repository. For a new or public repository, it is usually the first place visitors look to understand the project’s goal, how to install or run it, and where to begin. That makes it the best file for giving a quick overview to users, contributors, or classmates.
A good README often includes:
Other special files have narrower purposes, so they do not replace a README as the main explanation of the repository.
Topic: Work with Github Repositories
A new contributor notices that a public repository’s README.md has an outdated setup command. The contributor can suggest changes, and the repository accepts documentation fixes through normal review. What is the best action in GitHub?
Options:
A. Edit README.md in a branch and open a pull request
B. Open an issue describing the outdated command
C. Add a comment to the repository home page
D. Start a discussion about improving the setup instructions
Best answer: A
Explanation: When the needed outcome is a concrete file update, the best GitHub action is to change the file and submit it for review with a pull request. Issues and discussions are better for tracking work or having conversations, not for applying the file change itself.
This scenario is about correcting content that already exists in a repository file. Because the problem is a specific documentation error in README.md, the most direct GitHub workflow is to edit the file on a branch and open a pull request. That approach proposes the actual change, preserves review history, and lets maintainers approve it before it is merged.
Issues are mainly for reporting, tracking, or requesting work. Discussions are for broader conversation, questions, or idea sharing. If you already know the exact file that should be updated, proposing the file change is usually the better choice than only describing it. The key distinction is whether you need to change repository content now or just talk about possible future work.
README.md fix.Topic: Work with Github Repositories
A team keeps production-ready code in the main branch of a repository. One developer needs to update the README, while another wants to try a UI change that might take several days. They want to keep unfinished work organized and separate from main and from each other. What should they do next?
Options:
A. Create a separate branch for each task from main
B. Open issues for both tasks and wait to edit files later
C. Create a new repository for each change
D. Commit both changes directly to main
Best answer: A
Explanation: Branches organize work by giving each change its own line of development inside the same repository. In this scenario, separate branches keep the README update and UI experiment isolated until each is ready to be reviewed and merged.
A branch is an independent line of work within a repository. When a team wants to make multiple changes at the same time, creating a separate branch for each task keeps work organized and prevents unfinished changes from affecting the stable main branch.
A simple beginner workflow is:
mainThis is better than committing directly to main, because branches separate in-progress work while still keeping everything in one repository.
main remove the separation the team wants and can expose unfinished work on the stable branch.Topic: Work with Github Repositories
A team stores deployment and security settings in a repository. They want changes to .github/workflows/deploy.yml and SECURITY.md to be reviewed by the right maintainers before merging, while ordinary documentation changes can follow the usual process. Which GitHub repository file best supports this requirement?
Options:
A. CODEOWNERS
B. LICENSE
C. CONTRIBUTING.md
D. README.md
Best answer: A
Explanation: The CODEOWNERS file identifies who should review changes to specific files or folders in pull requests. For important paths such as workflow or security files, it helps involve the correct maintainers before merge.
GitHub uses a CODEOWNERS file to associate repository paths with specific people or teams. When a pull request changes one of those paths, GitHub can automatically request review from the listed owners. This is useful for important files such as workflow definitions, deployment settings, or SECURITY.md, where an extra review helps prevent risky or unintended changes. If a team wants that review to be mandatory before merging, they commonly combine CODEOWNERS with branch protection rules. The key idea is that the review requirement is based on which files changed, not simply on whether a pull request exists.
README.md explains the project but does not assign reviewers for specific files.CONTRIBUTING.md tells contributors how to work in the repo, but it does not automatically route review requests.LICENSE defines usage rights and is unrelated to pull request review ownership.Topic: Work with Github Repositories
A team maintains a private GitHub repository named service-starter with a standard README, LICENSE, .gitignore, and starter workflow files. They need to create five new service repositories that all begin with that same starting content, but each service must have its own issues, branches, and commit history.
Which GitHub choice is best?
Options:
A. Create a new branch in service-starter for each service
B. Open one new empty repository and add all five services there
C. Use a fork of service-starter for each internal service
D. Create each service as a repository from the template
Best answer: D
Explanation: A repository template is the best fit when multiple new repositories should start from the same baseline files. It gives each service its own repository and independent work history while reusing the standard starter content.
The key concept is choosing between a template, a branch, and a separate repository based on how independent the work must be. Here, each service needs its own issues, branches, and commit history, which means each service should be its own repository. A repository template is designed for this exact setup: it lets you create new repositories that start with the same files and structure as the starter repository.
A branch would keep all services inside one repository, which does not meet the requirement for separate repository-level tracking. A single empty repository for all services also combines them into one place. A fork creates a relationship mainly used for contributing to another repository, not for creating several standard internal starter repos.
When many repos need the same starting layout, choose a template.
Topic: Work with Github Repositories
A student team created a GitHub repository for a small web app. New contributors say the repository is hard to scan because code, images, and notes are mixed together at the top level.
Repository root:
README.md
LICENSE
index.html
styles.css
app.js
logo.png
screenshot-home.png
meeting-notes.md
api-guide.md
What is the best next step to improve repository readability?
Options:
A. Keep all files in the root and describe locations only in issues
B. Enable GitHub Pages so contributors can browse the repository as a website
C. Rename every file so they all start with the repository name
D. Create clear folders for related files, such as src, docs, and images
Best answer: D
Explanation: The best next step is to organize related files into meaningful folders. A clear directory structure improves readability by reducing root-level clutter and helping contributors understand where code, documentation, and images belong.
Repository readability depends heavily on file organization. When many unrelated files are stored in the root, contributors must scan a long list before they can find the file they need. Creating folders such as src for application files, docs for documentation, and images for media makes the repository easier to navigate and maintain.
A good beginner setup usually follows this pattern:
README.md and LICENSE in the root.A README can help explain the layout, but it should support a sensible structure rather than replace one. Clear organization improves readability for both current collaborators and future contributors.
Topic: Work with Github Repositories
You need to update README.md in your team’s GitHub repository. The main branch is protected, and all changes to main must be reviewed before they are merged. You are working in the GitHub web interface.
What is the best next step?
Options:
A. Turn off branch protection on main and edit the file directly.
B. Post the updated text in a repository discussion and wait for someone else to add it.
C. Run git pull on your computer to update the file in GitHub.
D. Create a new branch, edit README.md, and open a pull request.
Best answer: D
Explanation: Because main is protected, the repository expects changes to go through review before they are merged. The right next action is to make the file change on a separate branch and submit it with a pull request.
A protected branch is designed to prevent direct changes to important branches such as main. In this scenario, the file can still be updated in GitHub, but the change should start on a new branch. After editing README.md, you open a pull request so the change can be reviewed and then merged into main according to the repository rules.
This is a common foundational GitHub workflow for changing files safely:
A discussion is for conversation, not for making tracked file changes, and disabling protection would bypass the stated review requirement.
git pull option confuses syncing changes from a repository with making and submitting a new file change to that repository.Topic: Work with Github Repositories
A team is preparing a new public GitHub repository before inviting outside contributors. They want researchers to know how to report suspected vulnerabilities privately and what information to include.
What should the team do next?
Options:
A. Open a pinned discussion for security questions
B. Add a SECURITY.md file with vulnerability reporting guidance
C. Add a CONTRIBUTING.md file with coding standards
D. Add a CODEOWNERS file for required reviewers
Best answer: B
Explanation: The right next step is to add a SECURITY.md file. Its purpose is to communicate how security issues should be reported, especially when the team wants reports handled privately instead of through public issues or discussions.
A SECURITY.md file is the repository file meant for security reporting guidance. In this scenario, the team wants outside contributors and researchers to know how to disclose vulnerabilities privately and what details to provide. That is exactly the role of SECURITY.md.
It typically helps by:
Other repository files have different purposes. CONTRIBUTING.md explains general contribution practices, and CODEOWNERS controls review responsibility. A discussion is also the wrong fit here because the team wants a private security reporting path, not a public conversation.
CONTRIBUTING.md is useful for normal contributions, but it does not specifically provide security disclosure guidance.CODEOWNERS helps route reviews, not explain how to report vulnerabilities.Topic: Work with Github Repositories
Your team’s repository has a README.md file with one broken Markdown link. You have permission to contribute, and the default branch is protected, so changes must go through a pull request. You are already in the GitHub web interface, and no code or multi-file changes are needed. What is the best next step?
Options:
A. Clone the repository locally and set up a full development environment first.
B. Edit README.md in the web interface, commit to a new branch, and open a pull request.
C. Open a discussion asking whether someone should fix the link.
D. Turn off branch protection and commit the change directly to the default branch.
Best answer: B
Explanation: For a small documentation-only change, GitHub’s web editor is usually the quickest appropriate tool. Because the default branch is protected, the change should still be proposed through a pull request instead of bypassing review controls.
The core idea is choosing the simplest GitHub workflow that fits the change. A one-line fix in README.md is a small documentation update, so editing the file directly in the GitHub web interface is appropriate when you do not need to run code, change several files, or use local tools.
Because the default branch is protected, you should not push directly to it or weaken its rules. The right flow is:
Using a discussion or issue can help coordinate work, but here the needed fix is already clear and small. Cloning the repository locally would work, but it adds unnecessary setup for this simple repository file change.
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.