Try 50 free GitHub Foundations GH-900 questions across the exam domains, with explanations, then continue with full IT Mastery practice.
This free full-length GitHub Foundations GH-900 practice exam includes 50 original IT Mastery questions across the exam domains.
These questions are for self-assessment. They are not official exam questions and do not imply affiliation with the exam sponsor.
Count note: this page uses the full-length practice count maintained in the Mastery exam catalog. Some certification vendors publish total questions, scored questions, duration, or unscored/pretest-item rules differently; always confirm exam-day rules with the sponsor.
Need concept review first? Read the GitHub Foundations GH-900 Cheat Sheet on Tech Exam Lexicon, then return here for timed mocks and full IT Mastery practice.
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
| Domain | Weight |
|---|---|
| Understand Git and Github Basics | 30% |
| Work with Github Repositories | 15% |
| Collaborate Using Github | 15% |
| Apply Modern Development Practices | 15% |
| Manage Projects with Github | 10% |
| Understand Privacy, Security, and Administration | 10% |
| Explore the Github Community | 5% |
Use this as one diagnostic run. IT Mastery gives you timed mocks, topic drills, analytics, code-reading practice where relevant, and full practice.
Topic: Collaborate Using Github
A team is tracking a bug in a GitHub issue. During troubleshooting, one developer writes detailed setup and recovery steps that new contributors will need to reuse, and the instructions will likely change over time. The repository’s wiki is already enabled.
What is the best next step?
Options:
A. Put the guide in a personal Gist and ask the team to use that link.
B. Add the full guide as a new comment on the issue.
C. Create a wiki page for the shared guide and link it from the issue.
D. Create an empty pull request so the team can discuss the steps there.
Best answer: C
Explanation: Use the project wiki when information is meant to become ongoing, shared documentation for the repository. Issue comments are better for conversation tied to one issue, not for maintaining a reusable guide over time.
The core concept is choosing the right GitHub collaboration space for the job. In this scenario, the setup and recovery steps are not just part of the bug discussion; they are reusable project documentation that multiple contributors will need later and may update over time. That makes the repository wiki the best fit.
A good rule is:
A pull request is for proposing changes, and a personal Gist is not the best home for repository-specific team documentation.
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?
Options:
A. Create an issue requesting a dependency inventory
B. Review closed pull requests for dependency changes
C. Open the repository’s dependency insights view
D. Check repository stars and traffic metrics
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 startup wants its GitHub repositories to be owned by the company instead of by one employee. The team also wants to manage access for multiple members and keep the repositories with the company if an employee leaves. Which GitHub concept best explains this scenario?
Options:
A. Personal account
B. Forked repository
C. Organization account
D. GitHub Project
Best answer: C
Explanation: This scenario describes an organization account because the repositories need shared company ownership and managed access for multiple people. A personal account belongs to one individual, while the other choices do not define account ownership.
A personal GitHub account belongs to one user, but an organization account is meant for shared work owned by a team or company. In this scenario, the key clues are company ownership, multiple members, and keeping repositories with the business even if one person leaves. That matches an organization account, which supports member management, teams, and shared repository ownership.
A good way to separate the two is:
The closest distractor is a personal account, but that would make one individual the owner instead of the company.
Topic: Understand Privacy, Security, and Administration
Amira uses a password and SMS-based two-factor authentication for her GitHub account. Her team recently received a phishing message that linked to a fake GitHub sign-in page. She wants the best next step to further reduce the chance of account takeover on her own account. What should she do?
Options:
A. Protect the repository’s default branch
B. Clone the repository again with GitHub Desktop
C. Add a passkey to her GitHub account
D. Open a discussion about the phishing message
Best answer: C
Explanation: Adding a passkey is the best next step because it strengthens sign-in at the account level and is designed to resist phishing. Repository settings, discussions, and recloning code do not directly improve how Amira authenticates to GitHub.
Account takeover risk is reduced most directly by strengthening how the user signs in, not by changing repository workflows. In this scenario, the account already has SMS-based 2FA, but a passkey provides a stronger, phishing-resistant sign-in method for GitHub. Because passkeys rely on device-based authentication instead of a reusable password flow, they better protect against fake sign-in pages and stolen credentials.
Branch protection and team communication still matter, but they do not directly stop someone from taking over the GitHub account.
Topic: Understand Git and Github Basics
A new team member is contributing to a GitHub repository for the first time. She wants to work on her laptop, clone the repository, create a branch, review changed files visually, and commit and push changes without using Git commands. Which option is the best fit?
Options:
A. Use GitHub Desktop
B. Use a repository discussion thread
C. Use github.dev only
D. Use GitHub Mobile
Best answer: A
Explanation: GitHub Desktop is the right choice when a beginner wants a graphical interface for everyday Git work on a local computer. It supports the exact tasks in the scenario: cloning, branching, reviewing changes, committing, and pushing without relying on the command line.
The core concept is choosing the GitHub tool that matches a beginner-friendly graphical Git workflow. GitHub Desktop is built for common local repository tasks on a computer, including cloning a repository, creating branches, viewing file changes, making commits, and pushing changes back to GitHub.
In this scenario, the user specifically wants to:
That makes GitHub Desktop the best fit. A browser editor can help with lightweight edits, and GitHub Mobile is useful for staying connected, but neither is primarily meant to replace a beginner’s local graphical Git workflow. The key takeaway is that GitHub Desktop helps new users use Git visually on their computer.
github.dev only is useful for quick browser-based edits, but it is not the main tool for managing a local graphical Git workflow.Topic: Explore the Github Community
A small team built a reusable set of Markdown issue templates in a private GitHub repository. Other developers have asked to see how the templates evolve, reuse them in their own projects, and suggest improvements. Which next step best supports transparent public collaboration on GitHub?
Options:
A. Post occasional ZIP files in a discussion thread instead of sharing the repository.
B. Keep the repository private and ask people to email change requests.
C. Make the repository public and add a README, LICENSE, and CONTRIBUTING file.
D. Set up GitHub Sponsors first and wait to open the repository later.
Best answer: C
Explanation: Public collaboration on GitHub works best when the repository itself is visible and prepared for outside participation. Making the repo public, then providing basic project guidance, improves transparency, enables reuse, and gives contributors a clear path to participate.
The core idea is that open, public repositories let people see the project history, understand its purpose, and contribute through normal GitHub workflows such as issues and pull requests. Adding a README explains the project, a LICENSE clarifies reuse, and a CONTRIBUTING file tells newcomers how to participate.
This combination supports the three goals in the scenario:
Private sharing, files posted outside the repository, or delaying access all reduce the community benefits that GitHub public collaboration is designed to provide.
Topic: Apply Modern Development Practices
A documentation contributor needs to fix a typo in README.md in a public repository. They are using a locked-down browser-only device, cannot install software, and do not need a terminal or to run the app. What is the best next step?
Options:
A. Create a GitHub Codespace for the repository and make the change there.
B. Add a GitHub Actions workflow to update the README automatically.
C. Open the repository in github.dev, edit the file in the browser, and submit a pull request.
D. Clone the repository with Git to a local machine and edit the file locally.
Best answer: C
Explanation: The best fit is github.dev because the contributor only needs a quick browser-based edit and cannot install local tools. The scenario does not require a terminal, runtime, or full cloud development environment.
This scenario is about choosing the right GitHub development surface. github.dev is designed for lightweight editing directly in the browser, which matches a small Markdown change on a device where software installation is blocked. It lets the contributor make the edit and continue the normal collaboration flow by creating a pull request.
GitHub Codespaces is better when someone needs a fuller cloud development environment, such as a terminal, dependencies, or the ability to run and test code. Cloning locally is not practical here because the device cannot install tools. GitHub Actions automates workflows, but it is not the right first tool for a one-time manual typo fix.
The key takeaway is to pick the lightest GitHub tool that still meets the work requirement.
Topic: Manage Projects with Github
A product team tracks work in a GitHub Project. Each work item already has a Status field, and most items are assigned to the current iteration. In the next weekly review, the team lead wants GitHub data to support a high-level discussion about productivity and where work is getting delayed. What is the best next step?
Options:
A. Open a repository discussion and skip looking at the project data first.
B. Ask each contributor to run git log and report how many commits they made.
C. Enable branch protection on main so the project can measure team productivity.
D. Review the project’s insights to see progress and bottlenecks by status or iteration.
Best answer: D
Explanation: The best next step is to use GitHub Project insights because the goal is a high-level productivity discussion based on project data. Insights help the team review progress trends and spot where items are getting stuck without reducing productivity to commit counts alone.
When a team already tracks work in a GitHub Project with fields like status and iteration, the most useful next action is to review the project’s insights or charts. That keeps the discussion focused on work progress, flow, and bottlenecks across the project instead of on raw coding activity.
High-level productivity discussions usually work best when the team looks at patterns such as:
Counting commits is a Git activity metric, not a project progress view, and it can miss planning, review, documentation, or issue-triage work. Branch protection improves safety, not productivity reporting. A discussion can be useful after reviewing the data, but it should not replace the project data that the team lead specifically wants to use.
Topic: Apply Modern Development Practices
A team already uses issues to track work in a repository. They now want every pull request to automatically run unit tests and show the result before anyone reviews the code. What is the best next step?
Options:
A. Ask reviewers to run tests locally and comment the results
B. Open a GitHub Discussion for contributors to post test results
C. Add a GitHub Actions workflow for pull request testing
D. Create a GitHub Project to track pull requests being tested
Best answer: C
Explanation: GitHub Actions is the GitHub feature used to automate work in a repository based on events like pull requests. Because the team wants tests to run automatically and display results on each pull request, an Actions workflow is the best next step.
GitHub Actions is designed for automation inside a repository. A workflow can start when a pull request is opened or updated, run the project’s tests, and report the result back to the pull request as a status check. That matches the team’s goal of automatic, visible testing before review begins.
GitHub Projects is for planning and tracking work, not executing tests. GitHub Discussions is for conversations and community questions, not automated validation. Asking people to run tests manually can work as a temporary process, but it does not provide consistent automation or built-in status reporting. The key distinction is that Actions performs automated workflows, while Projects and Discussions organize or communicate work.
Topic: Work with Github Repositories
A student team creates a public GitHub repository for a beginner app project. New contributors say the repository is hard to scan because the root contains many mixed files.
Repository root:
about.md
bugfix.py
draft-notes.txt
image2-final.png
intro.md
script_old.py
test1.py
test2.py
usage.md
Which action would best improve repository readability for people browsing it on GitHub?
Options:
A. Turn on GitHub Discussions for contributor questions
B. Keep all files in the root and rely on commit messages
C. Group related files into folders and use descriptive file names
D. Enable branch protection for the default branch
Best answer: C
Explanation: Repository readability improves when related files are organized into clear folders and named consistently. On GitHub, contributors often judge structure from the file tree first, so better organization makes the project easier to navigate.
The core concept is repository file organization. When many unrelated files are placed in the root with vague names, the repository becomes harder to browse, especially for new contributors viewing it on GitHub. Grouping files into folders such as docs, src, tests, or images and using descriptive names helps people quickly understand what each file is for and where to find it.
A readable repository structure reduces confusion, makes maintenance easier, and improves the first impression of the project. In this scenario, the problem is not collaboration settings or branch safety; it is that the file layout is cluttered. The best fix is to improve the structure of the repository itself.
Topic: Work with Github Repositories
A team has just made a repository public for a small open-source tool. Right now, the repository contains only code files. They want new visitors to quickly understand the project and know the preferred way to contribute changes. What should the team do next?
Options:
A. Add a README.md and CONTRIBUTING.md file
B. Enable branch protection on the default branch
C. Publish the repository with GitHub Pages
D. Create a GitHub Project for future tasks
Best answer: A
Explanation: The best next step is to add a README.md and CONTRIBUTING.md. A README helps people find and understand the repository, while CONTRIBUTING gives contributors a clear process to follow.
Repository maintenance should make a project easier to understand, use, and contribute to. For a newly public repository with only code files, the first gap is documentation. A README.md tells visitors what the project is, why it exists, and how to get started. A CONTRIBUTING.md sets expectations for how to report issues or submit changes.
These files help in two important ways:
Branch protection, Projects, and Pages can all be useful, but they do not solve the immediate onboarding problem for new visitors and contributors.
Topic: Collaborate Using Github
A beginner team is using GitHub for a private app repository. A tester finds that the login page fails on mobile devices. The team wants to record the bug, label it bug, assign it to a teammate, discuss progress, and later connect the code fix when a pull request is opened.
Which GitHub feature should they use first?
Options:
A. Add a draft item to GitHub Projects
B. Create an issue
C. Start a discussion
D. Open a pull request
Best answer: B
Explanation: Use an issue when the goal is to track a bug or planned work in GitHub. Issues are designed for actionable items such as bugs, tasks, and questions, and they support labels, assignees, and links to later pull requests.
The core concept is that issues are GitHub’s built-in work-tracking item for bugs, tasks, questions, and planned work. In this scenario, the team needs to record a bug, assign responsibility, label it, discuss it, and later connect the code change. That matches an issue directly.
An issue works well because it can:
bugA discussion is better for broad conversation, a pull request is for proposing code changes, and a Projects draft item helps organize work but is not the main bug-tracking record here.
Topic: Understand Git and Github Basics
A team wants its README, issue descriptions, and pull request comments to support headings, bullet lists, links, and code blocks while still being simple to write and easy to read as plain text. Which foundational GitHub concept explains this?
Options:
A. Markdown
B. A branch
C. GitHub Pages
D. A commit
Best answer: A
Explanation: Markdown is a lightweight text formatting syntax used across GitHub for files like README and for content in issues and pull requests. It lets users add structure such as headings, lists, links, and code blocks without needing full HTML.
The core concept is Markdown. On GitHub, Markdown is used to format text so it stays easy to write in plain text while also displaying clearly in places like repository documentation, issues, and pull requests. That makes it ideal when a team wants simple syntax for readable content.
Common Markdown formatting includes:
A branch or commit tracks code changes, but neither is a text-formatting method. GitHub Pages is for publishing a website, not for the basic formatting syntax used inside GitHub content.
README.Topic: Manage Projects with Github
A student team uses one GitHub repository for a class app. They already create issues for tasks and open pull requests for code changes, but during weekly meetings they struggle to see what is planned, in progress, and waiting for review in one place. What should they do next?
Options:
A. Create a GitHub Project and use a view to organize issues and pull requests by status
B. Move all task details into the repository README
C. Put the pull requests in a Wiki page and update it manually
D. Start a GitHub Discussion for each task instead of using issues
Best answer: A
Explanation: GitHub Projects is the best next step when a team already has issues and pull requests but needs a clearer way to organize and track them. A project view helps show workflow status in one place without replacing the existing work items.
The core concept is using GitHub Projects to manage work across issues and pull requests. In this scenario, the team already uses the right collaboration artifacts: issues for tasks and pull requests for proposed changes. Their problem is visibility and organization during the workflow, so the next step is to place those items into a project and use a view such as a board or table to group them by status.
A project view helps teams:
A README, Discussion, or Wiki can share information, but they do not provide the same workflow-focused tracking experience for active work items. The key takeaway is to use a project view when the team needs structured tracking of issues and pull requests.
Topic: Understand Git and Github Basics
Rina has write access to her team’s private GitHub repository. She needs to update several files from her laptop, but she is brand new to Git and wants a graphical workflow for cloning, committing, and pushing changes instead of using the command line. What is the best next step?
Options:
A. Use GitHub Mobile to manage the repository from her phone.
B. Open a discussion so a maintainer can make the changes.
C. Change the repository visibility to public before editing.
D. Install GitHub Desktop and clone the repository there.
Best answer: D
Explanation: GitHub Desktop is designed for beginners who want to work with Git repositories through a graphical interface on a computer. In this scenario, Rina wants local file changes and basic Git actions without command-line Git, so GitHub Desktop is the best fit.
The key concept is choosing the GitHub tool that matches the user’s task and comfort level. GitHub Desktop is useful when a beginner wants to work with a repository locally and perform common Git actions through menus and buttons instead of terminal commands. In this case, Rina wants to clone a repository to her laptop, edit several files, then commit and push changes, which is exactly the kind of workflow GitHub Desktop supports well.
GitHub Desktop is a better fit here because it helps with:
Changing repository visibility does not help with editing, and a discussion is for conversation rather than making the change. GitHub Mobile is helpful for lightweight GitHub activity, but not as the main local graphical Git workflow on a laptop.
Topic: Collaborate Using Github
Priya wants to share a 20-line Bash script on GitHub with a link that others can copy and revisit later. The script is not part of any project, and her team does not want it added to the repository or the repository wiki as official documentation. What is the best next step?
Options:
A. Publish the script on the repository wiki.
B. Add the script as a new file in the repository.
C. Create a Gist for the script.
D. Open an issue and paste the script into the issue body.
Best answer: C
Explanation: A Gist is the best fit for a small standalone snippet that should be shared on GitHub without becoming part of a repository or its documentation. Repository files belong to the project itself, and wiki pages are for project-related reference content.
The key distinction is scope. A repository file becomes part of the project’s tracked content, and a wiki page becomes part of the project’s documentation space. In this scenario, the script is intentionally separate from the project and should still be easy to share with a link and revisit later, which is exactly what a Gist is for.
A Gist works well when you need to share:
The closest distractor is the wiki option, but a wiki is tied to repository documentation rather than standalone snippet sharing.
Topic: Understand Git and Github Basics
Maya updates a repository’s README.md on her laptop. She already used Git to create a branch and commit the change locally. Her team uses GitHub and requires review before anything is merged into main.
What is the best next step?
Options:
A. Open a GitHub issue to move the commit into main
B. Merge the branch into main locally and send the updated files to the team
C. Change the repository visibility so reviewers can see the branch
D. Push the branch to GitHub and open a pull request
Best answer: D
Explanation: The work on Maya’s laptop was handled by Git: creating a branch and making a commit. Because the team requires review before merging, the next step is to use GitHub’s collaboration feature by pushing the branch and opening a pull request.
Git and GitHub serve different roles. Git handles version-control tasks such as creating branches and recording commits in a local repository. GitHub adds hosted collaboration features such as pull requests, reviews, and shared repository access.
In this scenario, Maya has already finished the Git part locally. Since the team requires review before changes reach main, she should publish her branch to GitHub and create a pull request so others can review and approve it.
An issue can discuss work, but it does not submit code changes for merge review.
Topic: Manage Projects with Github
A beginner team is tracking work in a GitHub Project with a board-style view using To do, In progress, and Done columns. During planning, the team lead says, “I need to review all items in rows and sort them by assignee and target date.” What is the best next step?
Options:
A. Convert the issues to pull requests first
B. Add more status columns to the board
C. Add a table-style view to the project
D. Track the work in repository discussions instead
Best answer: C
Explanation: GitHub Projects supports different layouts for the same tracked work. A board-style view is useful for moving items across status columns, while a table-style view is better when the team needs a list they can review by fields such as assignee and date.
The key concept is choosing the project layout that matches the team’s immediate task. A board-style view helps visualize workflow stages like To do, In progress, and Done. A table-style view presents items as rows with fields as columns, which is better for scanning, sorting, and comparing structured details such as assignee or target date.
In this scenario, the team is already using a project and now needs a spreadsheet-like perspective. The best next step is to add or switch to a table-style view within the project so the same work items can be reviewed in that format.
Adding more board columns changes status organization, but it does not provide the row-and-column view the team requested.
Topic: Understand Privacy, Security, and Administration
A company wants GitHub access to be fully tied to its corporate identity provider. Employees must use company-managed GitHub accounts, and access should be removed centrally when someone leaves. The company does not want to depend on employees’ personal GitHub accounts.
What is the best next step?
Options:
A. Make all repositories private and protect the default branch
B. Require employees to join the organization with personal accounts
C. Adopt Enterprise Managed Users for enterprise-controlled accounts
D. Create teams for each department and assign repository access
Best answer: C
Explanation: The requirement is about centrally managed identity and account lifecycle, not just repository security or permissions. Enterprise Managed Users fits this by letting the enterprise manage GitHub user accounts through its identity system instead of depending on personal accounts.
Enterprise Managed Users is a GitHub enterprise identity model for organizations that want user accounts to be controlled by the company. In this scenario, the key facts are centralized identity, company-managed accounts, and automatic removal of access when employment ends. That points to enterprise-managed user identities rather than personal GitHub accounts invited into an organization.
Repository privacy, branch protection, and teams are still useful, but they solve different problems:
The closest distractors deal with access management inside GitHub, but the real need here is enterprise control of the user accounts themselves.
Topic: Work with Github Repositories
A team notices that when a pull request changes files in .github/workflows/ or docs/security/, GitHub automatically requests review from specific team members before the changes are merged. Which foundational GitHub concept explains this behavior?
Options:
A. A repository README file
B. Project board automation
C. A CODEOWNERS file
D. Branch protection on the default branch
Best answer: C
Explanation: This scenario is explained by a CODEOWNERS file. It lets a repository define who should review changes to specific files or folders, which is why important files may need review through a pull request.
CODEOWNERS is the GitHub feature used to associate repository paths with specific users or teams. When a pull request includes changes to those matching files, GitHub can automatically request review from the listed owners. This is especially useful for important files such as workflow files, security documents, or other sensitive repository content.
That helps teams make sure the right people review changes before they are merged. Branch protection can require pull requests or approvals, but it does not by itself assign reviewers based on which files changed. The key idea here is file-specific review responsibility.
Topic: Understand Git and Github Basics
A small team already uses a GitHub repository for its marketing website. The team is now starting a separate internal tool with different contributors, its own README, issues, and release history. They want to collaborate on it in GitHub without mixing it with the website codebase.
What is the best action?
Options:
A. Add the internal tool in a new folder in the website repository
B. Create a new branch in the website repository
C. Post the tool’s files in a GitHub Gist
D. Create a new repository for the internal tool
Best answer: D
Explanation: A new repository is appropriate when a new project needs its own codebase, history, documentation, and collaboration tracking. In this scenario, the internal tool is separate from the website and should not share the same repository structure.
A GitHub repository is the main container for a project’s files, commit history, issues, and collaboration. When a team starts a distinct project that will have its own contributors, documentation, work tracking, and release lifecycle, creating a new repository is the clearest choice. That keeps the project organized and avoids mixing unrelated code and history with another product.
A branch is better for temporary or parallel work inside the same project, not for launching a separate shared codebase. A folder inside the existing repository would combine two different projects under one history and workflow. A Gist is useful for sharing small snippets, not for managing a full team project.
The key signal here is that the internal tool is a separate project, so it should have its own repository.
Topic: Understand Privacy, Security, and Administration
A company uses GitHub Enterprise with managed user accounts. An organization administrator decides whether GitHub Copilot Chat and code completion are available to members across the organization. No developer is writing prompts or accepting suggestions yet. Which concept best explains this scenario?
Options:
A. Organization-wide Copilot policy management
B. Branch protection for the default branch
C. Individual developer use of GitHub Copilot features
D. Repository visibility configuration
Best answer: A
Explanation: The scenario is about an administrator controlling whether Copilot features are available across an organization. That is policy management at the organization level, not an individual developer using Copilot during coding.
The core concept is the difference between governing access to Copilot and using Copilot. In the scenario, an organization administrator is deciding whether members can use Copilot Chat and code completion at all. That is an organization-wide policy decision within GitHub administration.
Individual Copilot feature usage happens later, when a developer actually uses suggestions, chat, or other Copilot assistance while working. Branch protection and repository visibility are also admin controls, but they manage code change safety and who can see a repository, not whether Copilot features are enabled for organization members.
The key takeaway is that availability settings managed by admins are policy management, while prompts and suggestions are feature usage.
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?
Options:
A. LICENSE
B. CODEOWNERS
C. CONTRIBUTING
D. README
Best answer: C
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: Apply Modern Development Practices
A team uses a GitHub repository for a beginner project. They want basic tests to run automatically whenever a pull request is opened so reviewers can quickly see whether the changes pass. What is the best next step?
Options:
A. Create a GitHub Discussion so reviewers can post test results.
B. Open the repository in Codespaces for every reviewer.
C. Publish the repository with GitHub Pages first.
D. Use GitHub Actions to automate checks for pull requests.
Best answer: D
Explanation: GitHub Actions is the correct choice because it automates work when events happen in a repository, such as opening a pull request. At GH-900 level, you need to recognize this capability and when to use it, not write the workflow YAML from memory.
GitHub Actions is GitHub’s automation feature for repository events and common development tasks. In this scenario, the team wants tests to run automatically when a pull request is opened, which matches the purpose of Actions: trigger automated checks, builds, or other tasks based on events in GitHub.
A beginner should recognize this process:
The key GH-900 skill is understanding what Actions does and when to use it. You are not being tested on the exact YAML syntax needed to define the workflow.
Topic: Understand Git and Github Basics
A contributor notices that a project’s config.yml now enables a feature that was previously off. They want to see the sequence of saved changes to that file, who made each change, and the messages describing why. Which Git or GitHub concept best fits this need?
Options:
A. Issue tracking
B. Commit history
C. Repository visibility
D. Branch protection
Best answer: B
Explanation: Commit history is the record of saved snapshots in a repository. It is the right place to review what changed over time, who changed it, and the messages attached to those changes.
The core concept here is commit history. A commit is a saved snapshot of changes in a repository, and the history of commits lets you look back through those snapshots in order. When someone needs to understand how a file changed, when it changed, who changed it, and the reason recorded with the change, reviewing commit history is the most direct fit.
This is especially useful for tracing project changes over time:
By contrast, other GitHub features may support collaboration or protection, but they do not serve as the repository’s chronological record of file changes.
Topic: Apply Modern Development Practices
A documentation contributor needs to fix a typo in README.md in a private GitHub repository. They are using a locked-down laptop with only a browser. The repository’s main branch requires pull requests, and this change does not need builds, extensions, or local dependencies. What is the best next step?
Options:
A. Remove branch protection and edit main directly.
B. Use github.dev, edit on a branch, then open a pull request.
C. Start a discussion about the typo instead of editing.
D. Run git init locally, then push a new repository.
Best answer: B
Explanation: A small browser-based documentation fix is a good fit for github.dev. Because main is protected, the change should still be made on a branch and reviewed through a pull request.
This scenario calls for a lightweight editing tool plus the normal GitHub review flow. github.dev is designed for quick browser-based edits, so it fits a simple README.md typo fix when no full development environment is needed. The protected main branch means the contributor should not edit directly on main; they should make the change on a branch and open a pull request.
Using Git commands to create a new local repository does not solve the browser-only constraint and confuses local Git setup with working in an existing GitHub repository. Starting a discussion is useful for conversation, not for making a straightforward file correction. The key takeaway is to combine the right lightweight editor with the required review process, rather than switching tools or settings unnecessarily.
main.Topic: Understand Git and Github Basics
A developer wants to test a new feature in a repository without affecting the stable work used by the rest of the team. They create a separate line of work, make changes there, and merge it later only if the experiment succeeds. Which Git concept explains this scenario?
Options:
A. An issue
B. A branch
C. A pull request
D. A commit
Best answer: B
Explanation: This scenario describes using a branch. In Git, branches let people experiment safely in a separate line of development without changing the main work until the changes are ready.
Version control supports experimentation by letting work happen in isolated lines of development. In Git, that separate line is a branch. A developer can create a branch, make and test changes there, and then merge the branch into the main line if the experiment succeeds.
This is useful because it protects the stable version of the repository while still allowing new ideas, fixes, or features to be explored. A commit only records a snapshot of changes, a pull request is used to review and propose merging changes, and an issue is used to track work or report problems.
The key idea is that branches enable safe experimentation without disrupting the main codebase.
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?
Options:
A. GitHub Gist
B. GitHub Pages
C. Repository wiki
D. GitHub Discussions
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.
Topic: Understand Git and Github Basics
A new contributor edits README.md and CONTRIBUTING.md on a branch in a GitHub repository. Before opening a pull request, they want to save the current state of those edits as part of the repository’s history. What should they do next?
Options:
A. Open an issue describing the edits
B. Create a commit for the changes on the branch
C. Start a discussion about the updated files
D. Add the branch to a GitHub Project
Best answer: B
Explanation: A commit is the Git concept used to save a recorded snapshot of changes in repository history. In this scenario, the contributor has already made edits, so the next step is to create a commit before moving on to collaboration steps like a pull request.
The core concept is that a commit captures the current state of selected file changes at a point in time. That snapshot becomes part of the repository’s history, which lets others review what changed over time. In GitHub Flow, you typically make changes on a branch, create one or more commits to record those changes, and then open a pull request to propose merging them.
An issue, discussion, or project item can help with planning or communication, but they do not store file changes as repository history. If the goal is to save edits so they are tracked as part of the branch’s history, a commit is the correct next step.
Topic: Work with Github Repositories
A team reorganizes a repository so that application code is in src, documentation is in docs, tests are in tests, and the root README.md explains each folder. New contributors can now find files much faster. Which foundational GitHub concept best explains this improvement?
Options:
A. Issue tracking
B. Branch protection
C. Clear repository structure
D. Repository visibility
Best answer: C
Explanation: This scenario is about organizing repository files so people can quickly understand where code, docs, and tests belong. That is a repository structure concept, not a collaboration, security, or access-setting feature.
Repository readability improves when files are grouped logically and named clearly. In GitHub, a well-organized repository often uses folders such as src, docs, and tests, plus a root README.md that explains the layout. This helps contributors locate files faster, understand project purpose, and reduce confusion when browsing the repository.
Good file organization supports beginners and collaborators because they can scan the repository and immediately tell where to look for code, documentation, and tests. Features like branch protection, issues, and visibility matter for other parts of repository management, but they do not directly explain why the file layout itself became easier to read.
The key takeaway is that clear repository structure improves navigation and readability.
Topic: Collaborate Using Github
A repository team keeps repeating the same setup and troubleshooting steps in issue comments. They want one easy-to-find place inside the repository for shared project guidance that can be updated over time and is not tied to a single issue.
Which GitHub concept best fits this need?
Options:
A. Pull request description
B. Gist
C. Repository wiki
D. Issue comment
Best answer: C
Explanation: A project wiki is the better fit when information should be maintained as reusable repository documentation instead of being buried in one issue thread. Wikis help teams organize evolving guidance that many contributors may need later.
The core idea is choosing the right GitHub collaboration surface for persistent project knowledge. An issue comment works best for conversation about a specific task or problem, but it becomes hard to find and reuse when the same instructions are needed across many issues. A repository wiki is meant for longer-lived documentation such as setup steps, troubleshooting guides, and team reference material.
In this scenario, the team needs content that is:
That makes a wiki the best fit. A gist or pull request description can hold text, but neither is intended to serve as the repository’s ongoing reference space.
Topic: Understand Git and Github Basics
A new contributor is asked to add a short FAQ section to a team’s repository. The repository follows GitHub Flow, and main is the stable branch. In github.dev, the branch selector still shows main.
What should the contributor do next?
Options:
A. Edit main directly because the change is small, then merge it later if needed.
B. Save the edit on main and open a pull request from main to main.
C. Open a discussion first because branch choice does not matter for documentation changes.
D. Create and switch to a new branch such as docs-faq-update, make the edit, then open a pull request.
Best answer: D
Explanation: In GitHub Flow, work should start on a separate branch, even for a small documentation update. Choosing a descriptive branch and switching off main is the correct next step before editing and opening a pull request.
The core concept is branch selection in a beginner workflow. In GitHub Flow, main represents the stable version of the project, so contributors make changes on a separate branch and then propose them through a pull request. A clear branch name, such as docs-faq-update, helps others understand the purpose of the work.
A simple flow is:
mainmainThis keeps the stable branch clean and makes review easier. Editing main directly skips the normal review path, and a pull request from main to main would not represent a separate line of work.
main directly fails because GitHub Flow expects changes to begin on a separate branch, even when the update is small.main against itself.Topic: Understand Git and Github Basics
A new public repository has no setup instructions. New contributors should see the steps as soon as they open the repository, and they need to copy commands instead of reading screenshots. What should the maintainer do next?
Options:
A. Add the setup steps to README.md using Markdown and code blocks
B. Create an issue that contains only terminal screenshots
C. Upload a PDF with screenshots of each setup step
D. Keep the instructions in a separate document outside GitHub
Best answer: A
Explanation: Use Markdown in README.md when instructions should be visible in the repository, easy to update, and easy to copy. That keeps the guidance with the project instead of hiding it in attachments or external files.
The best beginner GitHub choice is to document setup directly in README.md with Markdown. GitHub renders the README on the repository home page, so contributors see it immediately without opening another tool or downloading a file. Markdown is well suited for communication like setup steps because it supports headings, lists, links, and fenced code blocks for commands.
Keeping instructions in the repository also makes them part of normal version control. As setup changes, the team can update the same file through commits and pull requests. That creates a single source of truth and avoids outdated copies. Screenshots can be helpful as supplements, but they are poor for searchable, copyable command instructions.
Topic: Understand Git and Github Basics
You updated a documentation file in a GitHub repository, committed the change on a new branch, and pushed that branch to GitHub. Your team wants to review the change in one place and merge it into main only after approval. What is the best next step?
Options:
A. Run git merge locally and push the result to main
B. Change the repository visibility to public
C. Open a pull request from your branch into main
D. Start a GitHub Discussion about the change
Best answer: C
Explanation: This scenario needs a GitHub collaboration feature, not just another Git command. After the branch is already pushed, a pull request is the standard GitHub way to request review and merge changes into main.
Git handles version-control operations such as committing, branching, and merging. GitHub adds collaboration features on top of Git, including pull requests for review and merge workflows. In this scenario, the change already exists on a branch in GitHub, and the team needs review, discussion, and approval before merging. That means the next action is to create a pull request.
A local merge is only a Git operation and bypasses the review process described in the stem. A discussion is useful for broader conversations, but it is not the normal artifact for proposing branch changes to be merged. Repository visibility controls who can see the repo, not how a specific code or documentation change gets reviewed.
Key takeaway: use Git for change creation, and use GitHub features like pull requests when the scenario requires team review and merge coordination.
Topic: Manage Projects with Github
A team tracks work in a GitHub Project that contains linked issues and pull requests. The project manager wants a built-in view of progress, such as how many items are Todo, In Progress, and Done, to understand team productivity. Which GitHub concept best matches this need?
Options:
A. Branch protection
B. Security insights
C. Project insights
D. Repository stars
Best answer: C
Explanation: This scenario is about measuring work progress inside a GitHub Project. Project insights are used to view project status and productivity, not community popularity, security posture, or branch change rules.
Project insights help teams understand how work is moving through a GitHub Project. In this scenario, the manager wants progress information based on project item status like Todo, In Progress, and Done, which is a project-tracking need. That fits project insights because they focus on project progress and productivity.
Repository stars show interest in a repository from the community, not delivery progress. Security insights focus on security-related information, not project workflow status. Branch protection controls how branches can be changed, which is a repository governance feature rather than a reporting view.
The key takeaway is that project insights are for tracking work progress, while stars and security insights measure very different things.
Topic: Apply Modern Development Practices
A documentation contributor notices a typo in a repository README.md while using a locked-down shared laptop. They only need to make a quick browser-based text edit and commit the change, without setting up a full development environment or running the code. Which GitHub concept best fits this scenario?
Options:
A. GitHub Codespaces
B. GitHub Copilot
C. GitHub Actions
D. github.dev
Best answer: D
Explanation: This scenario is about lightweight editing, not automation, AI assistance, or full environment setup. github.dev fits because it lets someone quickly edit repository files in the browser.
The key requirement is a fast, browser-based edit for a small documentation change. github.dev is designed for lightweight editing directly from a GitHub repository, which makes it a good fit when someone only needs to update text like a README and does not need to build, run, or configure the project.
By contrast, GitHub Codespaces is for a fuller cloud development environment, GitHub Copilot is for AI coding assistance, and GitHub Actions is for workflow automation. When the main need is simply editing a file quickly in the browser, github.dev is the best match.
Topic: Manage Projects with Github
A team tracks repository issues in a GitHub Project. When an issue is closed, team members manually move the project item to Done, but they often forget and progress reports become inaccurate. What is the best next step to standardize this process?
Options:
A. Enable branch protection on the repository default branch
B. Create a project workflow that moves closed items to Done
C. Add a done label to issues after they are closed
D. Start a discussion reminding contributors to move items manually
Best answer: B
Explanation: GitHub Projects workflows are designed to automate project item changes based on conditions such as issue updates. If closed issues should always appear in Done, the most direct step is to configure a workflow that moves them automatically.
The core concept is project workflow automation in GitHub Projects. When a team wants project items to move in a consistent way, the best solution is to define a workflow rule instead of relying on people to remember manual updates. In this case, the trigger is simple: when the linked issue is closed, the project item should move to Done.
This helps by:
Labels, reminders, and other repository settings can support teamwork, but they do not automatically move project items in the same reliable way. For this requirement, automation in the project itself is the right fit.
Topic: Collaborate Using Github
Rina helps maintain two repositories in her organization. She wants GitHub to alert her when she is mentioned, assigned an issue, or requested to review a pull request so she does not have to manually check each repository. Which GitHub feature best meets this need?
Options:
A. Repository Insights
B. GitHub Projects
C. GitHub notifications
D. GitHub Discussions
Best answer: C
Explanation: GitHub notifications help users stay aware of activity that matters to them without constantly revisiting repositories. They surface events like mentions, assignments, subscriptions, and pull request review requests in one place.
The core purpose of GitHub notifications is to keep users informed about relevant activity across repositories. In this scenario, Rina wants alerts when work directly involves her, such as being mentioned, assigned an issue, or asked to review a pull request. Notifications are the GitHub feature built for that job.
They help users follow activity by collecting updates tied to their work and subscriptions, which makes it easier to respond quickly without manually checking each repository. By contrast, discussions are for conversations, projects are for planning and tracking work, and insights are for repository metrics and trends.
When the goal is staying informed about activity, notifications are the right fit.
Topic: Apply Modern Development Practices
A documentation contributor notices a typo in a repository README while reviewing a pull request on a shared computer. They need to make a quick change entirely in the browser and commit it, but they do not need terminal access or a full development environment. Which GitHub tool should they use next?
Options:
A. Open the repository in github.dev
B. Use GitHub Copilot as the primary editing workspace
C. Set up a GitHub Actions workflow for the repository
D. Create a GitHub Codespace for the repository
Best answer: A
Explanation: This scenario calls for lightweight browser editing, so github.dev is the best fit. It lets a contributor quickly open and edit repository files without starting a full Codespace or configuring automation.
The key concept is choosing the GitHub tool that matches the amount of development environment you actually need. Here, the contributor only needs to fix a typo in a file and commit the change from a browser. github.dev fits that workflow because it provides fast, lightweight editing for repository content without the overhead of a full cloud-based machine.
A Codespace is better when you need a complete development environment, such as terminals, dependencies, builds, or debugging. GitHub Actions is for automating workflows, not for manually editing a file. GitHub Copilot can assist with writing, but it is not itself the editing workspace.
When the task is small and browser-only, github.dev is usually the right next step.
Topic: Explore the Github Community
Rina usually works only in her company’s private GitHub repositories. She finds a broken example in the README of a public repository used by many teams. The public repository includes a CONTRIBUTING.md file, and Rina does not have write access.
What is the best next step if she wants to participate in the project as an open-source contributor?
Options:
A. Open a discussion in her private team repository instead of contributing to the public project.
B. Fork the public repository, make the fix, and open a pull request that follows CONTRIBUTING.md.
C. Change her company’s private repository to public and post the fix there.
D. Commit the fix locally with Git and wait for the maintainers to pull it from her computer.
Best answer: B
Explanation: The open-source action is to contribute in the public project’s repository, not only inside a private team space. Because Rina lacks write access, the typical next step is to fork the repository and submit a pull request that follows the project’s contribution guidance.
Open source on GitHub means participating in a repository that is shared with the broader community, often a public repository maintained by people outside your private team. In this scenario, Rina wants to improve a public project and does not have direct write access, so she should use the normal contributor path: fork the repository, make the change in her copy, and open a pull request back to the original project.
CONTRIBUTING.md is important because it explains how that project wants outside contributors to work. Making a private team repository public, keeping the change only on a local machine, or discussing it only inside a private workspace does not actually contribute the fix to the open-source project. The key sign of open-source participation here is contributing back to the public repository through the project’s community workflow.
CONTRIBUTING.md helps Rina use the project’s expected open-source process.Topic: Understand Git and Github Basics
A new contributor wants to work on a repository without using Git commands. They want a graphical app to clone the repository, switch branches, review changed files, commit, and push changes from their computer. Which concept best fits this scenario?
Options:
A. Markdown
B. GitHub Desktop
C. GitHub Discussions
D. GitHub Mobile
Best answer: B
Explanation: This scenario describes a beginner who wants to perform common Git tasks through a graphical interface instead of the command line. GitHub Desktop is designed for that local workflow, including cloning, branching, committing, and pushing.
GitHub Desktop is a desktop application that helps beginners use Git and GitHub with a graphical workflow. In this scenario, the person wants to work with a local repository, manage branches, review file changes, create commits, and push updates without typing Git commands. That is exactly the kind of task GitHub Desktop supports.
GitHub Mobile is for quick activity on the go, not full local Git work. Markdown is a formatting language for text files such as README files. Discussions are for community conversations, not for managing a local Git workflow.
The key clue is the need for a graphical tool for everyday Git actions on a computer.
Topic: Understand Git and Github Basics
A new contributor needs to update setup steps in README.md using GitHub’s web editor. The repository note says:
Default branch: main
Current branch selected: feature/login
Branch naming guide:
- docs/<topic> for documentation changes
- feature/<topic> for code changes
Use a pull request for all changes.
No edits have been made yet. What is the best next step?
Options:
A. Commit the README.md update directly to main
B. Open a discussion to ask whether branches are required for docs
C. Edit README.md on feature/login and open a pull request
D. Switch to main, create docs/setup-steps, and edit there
Best answer: D
Explanation: The contributor should start from the default branch and create a new branch that matches the documented naming pattern. Using a separate docs/... branch keeps the README change isolated from unrelated login work and supports the stated pull-request workflow.
Branch selection matters because it determines what existing work your change is based on, and branch naming helps others quickly understand the purpose of that work. Here, the selected branch is feature/login, which is meant for code changes and already represents a different task. Since no edits have been made, the clean beginner workflow is to switch to main, create a new branch for the documentation update, and then make the README change there.
This approach helps by:
Editing on the existing feature branch would mix tasks, while committing directly to main would skip the stated branch-based review flow.
main ignores the repository note that says to use a pull request for all changes.Topic: Understand Privacy, Security, and Administration
A company creates a GitHub repository for its unreleased product roadmap. The repository is currently public, but the project should be visible only to the intended audience instead of everyone on the internet. Which foundational GitHub concept explains what needs to be changed?
Options:
A. Branch protection
B. Repository visibility
C. Team permissions
D. Pull requests
Best answer: B
Explanation: This scenario is about controlling who can view the repository at all. In GitHub, that is handled by repository visibility, not by collaboration or branch management features.
The core concept is repository visibility. Visibility determines who can see a repository, such as whether it is public to everyone or restricted to a narrower audience. In this scenario, the problem is not how changes are reviewed or who can push to a branch; it is that the repository is visible more broadly than intended. Changing the repository’s visibility is the foundational GitHub action that aligns access with the project’s audience.
A close distractor is team permissions, but permissions mainly control what approved users can do after they already have access. Visibility decides whether the repository can be seen in the first place.
Topic: Work with Github Repositories
A maintainer uses GitHub’s web editor to add a CONTRIBUTING.md file to a repository. When they save, GitHub asks for a short message and creates a recorded snapshot so others can review the exact file change later. Which concept best explains that recorded change?
Options:
A. Commit
B. Issue
C. Branch
D. Pull request
Best answer: A
Explanation: The scenario describes saving file changes with a message and creating a recorded snapshot in the repository history. That is a commit, which captures added, changed, or deleted files at a point in time.
A commit is Git’s basic unit for recording changes in a repository. When someone adds or edits a file on GitHub and saves it with a message, GitHub creates a commit that stores that snapshot in the repository history. This lets collaborators see what changed, when it changed, and the message describing the update.
A few related concepts are easy to confuse here:
So the key idea in the scenario is the recorded snapshot of the file change, which is a commit.
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. Pull request
B. Discussion
C. Issue
D. Commit
Best answer: A
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 repository maintainer notices that new bug reports often omit reproduction steps, and pull requests often omit testing details. The team wants contributors to see a standard set of prompts whenever they open an issue or a pull request on GitHub. What should the maintainer do next?
Options:
A. Create labels for bugs, features, and documentation
B. Add issue templates and pull request templates to the repository
C. Enable branch protection on the default branch
D. Assign a CODEOWNERS file to reviewers
Best answer: B
Explanation: Issue and pull request templates are the GitHub feature designed to standardize contributor input. They guide users with predefined fields or prompts so reports and proposed changes arrive with the details maintainers need.
The core concept is using repository templates to make contributions more consistent. If contributors keep leaving out important information, the best next step is to add issue templates for items like bug reports and feature requests, and a pull request template for details such as testing, related issues, and summary of changes.
These templates help by:
Labels, branch protection, and CODEOWNERS all support repository workflows, but they do not prompt contributors to enter standardized information when creating issues or pull requests.
Topic: Understand Privacy, Security, and Administration
A company uses GitHub Enterprise Managed Users. The security team wants every member of one organization to follow the same GitHub Copilot usage settings, and they do not want to depend on each user updating personal preferences.
What should the organization admin do next?
Options:
A. Add Copilot instructions to the repository README
B. Ask each user to change their own Copilot settings
C. Configure a GitHub Copilot policy at the organization level
D. Enable branch protection on the default branch
Best answer: C
Explanation: When a requirement must be applied consistently to all members, an organization-wide policy is the right control. It gives admins centralized enforcement instead of depending on each user to configure settings correctly.
The core idea is centralized administration. If the goal is to make one Copilot setting or rule apply across an organization, the admin should use an organization-wide Copilot policy rather than sending instructions to each user.
This is the better process because it:
Documentation in a repository can explain expectations, but it does not enforce member settings. Branch protection is also useful, but it controls changes to branches, not Copilot behavior. The key takeaway is to use organization policy when the same rule must be managed centrally for many users.
Topic: Apply Modern Development Practices
A student team stores its web app in a GitHub repository. They want the repository to automatically run a build and test process whenever a pull request is opened, and automatically deploy the app after changes are merged into main. Which GitHub feature best fits this need?
Options:
A. GitHub Discussions
B. GitHub Actions
C. GitHub Codespaces
D. GitHub Projects
Best answer: B
Explanation: GitHub Actions is the GitHub feature used for workflow automation. In this scenario, the team wants build, test, and deployment steps to run automatically when pull requests and merges occur, which is exactly what Actions provides.
GitHub Actions lets you automate repository tasks in response to events such as opening a pull request or pushing changes to a branch. At a foundational level, its common uses include building code, running tests, and deploying applications or sites.
In this scenario, the team wants automation tied to repository activity:
mainThat matches GitHub Actions because it executes workflows automatically when those events happen. A tool for planning work, team conversation, or cloud development environments would not perform this kind of repository automation. The key takeaway is that GitHub Actions is GitHub’s built-in automation feature for common CI/CD-style tasks.
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 new repository for each change
B. Open issues for both tasks and wait to edit files later
C. Commit both changes directly to main
D. Create a separate branch for each task from main
Best answer: D
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: Understand Git and Github Basics
A new maintainer joins a repository months after a bug fix was merged. In the commit history, they see messages such as Handle null profile image during upload instead of vague messages like update stuff, so they can quickly understand why each change was made. Which foundational Git concept best explains this benefit?
Options:
A. Branch protection
B. Issue labels
C. Repository visibility
D. Descriptive commit messages
Best answer: D
Explanation: Descriptive commit messages help explain the intent of a change in the project history. That context makes it easier for future maintainers to understand what was changed and why without first reading every file difference.
The core concept is using clear, descriptive commit messages to preserve context in commit history. A commit is a saved snapshot of changes, and its message should summarize the purpose of that snapshot. When maintainers review history later, a message like Handle null profile image during upload communicates intent much faster than a vague message such as misc fixes. This improves traceability, speeds up troubleshooting, and helps people understand the reason behind past work.
A good commit message usually does two things:
By contrast, controls such as visibility, labels, or branch rules support other repository tasks, but they do not directly explain the meaning of a specific past 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 for concept review before another timed run.