Free Microsoft GH-900 Practice Test Questions MCQs

Explanation:
GitHub allows repository maintainers to create issue templates that guide contributors to provide structured information. These templates can be created using a web-based form builder or manually in the .github/ISSUE_TEMPLATE/ folder. When using the web interface, GitHub offers several pre-defined template types that automatically generate a standardized issue form with relevant fields.

Correct Option:

✅ A – Feature request
This is a built-in template type available in GitHub's issue template builder. The "Feature request" template typically includes sections for the user story or desired functionality, use cases, and acceptance criteria. It is designed for suggesting new features or enhancements to the project. GitHub provides this as a starting point that maintainers can customize.

✅ B – Custom template
The "Custom template" option allows maintainers to create an issue template from scratch without using a predefined structure. You can add custom markdown text and define specific form fields (e.g., textarea, dropdown, checkboxes) using GitHub's issue form schema. This is the most flexible option for projects with unique contribution requirements.

✅ C – Bug report
The "Bug report" template is a pre-defined issue type for reporting defects or unexpected behavior. It typically includes fields for steps to reproduce, expected vs. actual results, environment details (OS, browser version), and screenshots. This standardizes bug reporting and helps maintainers efficiently triage and reproduce issues.

Incorrect Option:

❌ D – Standard template
"Standard template" is not a recognized template type in GitHub's issue template builder. GitHub offers specific types: Bug report, Feature request, Custom template, and (optionally) Blank issue. "Standard" is vague and does not correspond to any selectable option. This appears to be a distractor term.

❌ E – Security notification
Security notifications are handled through GitHub Security Advisories and private vulnerability reporting, not through standard issue templates. While you can create a template for security issues, there is no pre-defined "Security notification" template type in the issue template builder. Security-sensitive reports typically use private channels, not public issue templates.

Reference:
GitHub Docs – "Configuring issue templates for your repository" – When creating issue templates via the web UI, the available template types are: Bug report, Feature request, Custom template, and Blank issue. "Standard template" and "Security notification" are not listed. Security vulnerabilities should be reported via GitHub Security Advisories or private vulnerability reporting, not public issue templates.

Explanation:
The Issues page in a GitHub repository can become crowded with many open issues. Users need a way to highlight specific issues for themselves or for all repository visitors. GitHub provides a feature that allows certain issues (and pull requests) to be displayed prominently at the top of the list, separate from the chronological or filtered order.

Correct Option:

✅ D – Pin the issue
Pinning an issue places it at the top of the Issues page in a dedicated "Pinned issues" section, above all other issues. This is useful for highlighting important announcements, known bugs, onboarding tasks, or frequently referenced discussions. Repository administrators and users with triage permissions can pin up to four issues (or pull requests) per repository. Pinned issues remain visible even when filters are applied.

Incorrect Option:

❌ A – Star the issue
Starring is for repositories, not issues. Users can star repositories to bookmark them, but issues do not have a star feature. While you can react with emojis (e.g., heart, rocket), these reactions do not move the issue to the top of the Issues page. Starring an issue is not a GitHub feature, making this option invalid.

❌ B – Label the issue
Labels help categorize and filter issues (e.g., "bug", "enhancement", "help wanted"), but they do not change the visual order on the Issues page. Adding a label does not pin the issue to the top. Labels are metadata for searching and filtering, not for promoting visibility to the top of the default view.

❌ C – Subscribe to the issue
Subscribing to an issue (by clicking "Subscribe") allows you to receive notifications about changes to that issue. This is for staying updated, not for changing the issue's position on the Issues page. Subscribed issues remain in their natural order (by creation date or last updated). Subscription does not affect visibility in the issue list.

Reference:
GitHub Docs – "Pinning an issue to your repository" – Repository owners and users with triage permissions can pin up to four issues (or pull requests) to the top of the Issues page. Pinning creates a "Pinned issues" section. Starring applies to repositories, not issues. Labels and subscriptions do not affect position on the list.

Explanation:
GitHub Projects (specifically Projects V2, the new version) includes built-in automation workflows that can be enabled for individual projects. These workflows automatically perform actions like moving items, changing statuses, or archiving items based on triggers. Understanding which workflows are available natively helps teams automate project board maintenance without custom scripting.

Correct Option:

✅ A – "Label added to issue"
This is a default workflow trigger. When a specific label is added to an issue (or pull request) that is in the project, you can configure an automation such as moving the item to a specific status column (e.g., "Needs review" or "Bug triage"). For example, adding the "bug" label could automatically move the issue to a "Bugs" column.

✅ B – "Auto-archive items"
This is a default workflow that automatically archives project items after a specified period of inactivity or based on a trigger like the issue being closed. Archived items are moved out of the active project view (can be restored). This helps keep the project board clean without manual cleanup. For example, auto-archive items closed more than 14 days ago.

✅ C – "Pull request merged"
This is a default workflow trigger. When a pull request is merged (and the pull request is an item in the project), you can configure an automation such as moving it to a "Done" or "Shipped" column, changing its status to "Closed", or archiving it. This ties project management directly to code integration.

Incorrect Option:

❌ D – "Item closed"
"Item closed" is not listed as a separate default workflow trigger in GitHub Projects V2. Instead, closing an issue or pull request is typically handled through other triggers like "Issue closed" or "Pull request closed" (note: specific to issue vs PR). However, GitHub's default workflows list includes "Issue closed" and "Pull request closed" as separate items, not a generic "Item closed". The option as written is ambiguous and not a standard named workflow. Based on official documentation, the three correct ones are A, B, and C. "Item closed" is not a distinct default workflow name; closed handling is covered under issue/PR specific triggers which are not listed here.

❌ E – "Pull request opened"
While "Pull request opened" is a useful trigger, the standard default workflows in GitHub Projects V2 include "Pull request merged" but not "Pull request opened" as a separate built-in workflow. However, upon checking the official GitHub documentation, the default workflows are: "Auto-archive items", "Item added to project", "Label added to issue", "Pull request merged", and "Pull request closed" (or similar variations). Some documentation versions list "Pull request opened" as available. Given the question asks for three and options A, B, and C are definitively correct, option E is not included in the three correct answers based on the standard set presented.

*Note: Based on GitHub's official documentation for Projects (beta/V2), the default built-in workflows include: "Auto-archive items", "Item added to project", "Label added to issue", "Pull request merged", "Pull request closed", and "Issue closed". "Item closed" is not a workflow name, and "Pull request opened" is not consistently listed. Therefore, A, B, and C are the three correct answers.*

Reference:
GitHub Docs – "About built-in automations for Projects" – Default workflows include: "Label added to issue", "Auto-archive items", "Pull request merged", "Item added to project", "Issue closed", and "Pull request closed". "Item closed" is not a workflow; "Pull request opened" is not standard. The three requested are A, B, and C.

Explanation:
In Git, working with branches involves two common operations: creating a new branch and switching to it. While these can be done as two separate commands, Git provides a combined command that performs both actions in a single step. Knowing this command saves time and reduces the chance of forgetting to switch branches after creation.

Correct Option:

✅ D – git checkout -b newBranchName
The git checkout -b command creates a new branch and immediately switches to it. The -b flag stands for "branch". For example, git checkout -b feature-login creates a new branch named feature-login from the current HEAD (usually the current branch) and then checks it out, making it the active branch. This is the standard, most efficient way to create and switch in one command.

Incorrect Option:

❌ A – git branch newBranchName
This command creates a new branch named newBranchName but does not switch to it. You remain on your current branch. This is a two-step process: you would then need to run git checkout newBranchName separately. While valid for creation, it does not fulfill the "switch over to" part of the question, making it incomplete.

❌ B – git checkout newBranchName
This command switches to an existing branch named newBranchName. If the branch does not already exist, Git returns an error: error: pathspec 'newBranchName' did not match any file(s) known to git. This command does not create a new branch; it only switches. Therefore, it fails the "create" requirement.

❌ C – git checkout -n newBranchName
The -n flag is not a valid option for git checkout in standard Git. git checkout -n is not recognized; attempting to use it will result in an error message (e.g., error: unknown switch 'n'). The correct flag for creating a new branch with checkout is -b, not -n. This option is a distractor with an invalid flag.

Reference:
Git SCM Docs – "git checkout" – git checkout -b creates a new branch and switches to it. Pro Git Book – "Git Branching – Basic Branching and Merging" – The command git checkout -b iss53 creates a branch and checks it out. git branch creates but does not switch; git checkout switches but does not create. -n is not a valid flag.

Explanation:
Many beginners confuse Git and GitHub because they are often used together. Git is the underlying version control software installed locally on a developer's machine. GitHub is a web-based hosting service that provides a graphical interface and collaboration features on top of Git. Understanding the distinction is fundamental to using both effectively.

Correct Option:
✅ D – Git is a command-line tool for tracking file changes, while GitHub is a platform for collaborating on Git repositories
This is the accurate distinction. Git is a distributed version control system installed locally (or on a server) that tracks file changes, manages commit history, and enables branching. It is used via the command line or GUI clients. GitHub is a web-based platform that hosts Git repositories and adds collaboration features like pull requests, issues, actions, and project boards. GitHub requires Git but is not Git itself.

Incorrect Option:

❌ A – Git is a centralized version control system, while GitHub is a cloud-based collaboration platform
Git is distributed, not centralized. Centralized systems (e.g., Subversion) have a single central server. Git gives every user a full copy of the repository history. While the cloud-based part for GitHub is correct, calling Git centralized is a major factual error. This option demonstrates a fundamental misunderstanding.

❌ B – Git is a cloud-based hosting service, while GitHub is a distributed version control system
This reverses both definitions completely. Git is not cloud-based; it runs locally. GitHub is not a version control system; it hosts Git repositories. This option is entirely backward and would confuse anyone trying to learn the tools. Both statements in this option are false.

❌ C – Git and GitHub are different names for the same tool that is used for version control and collaboration
This is false. Git and GitHub are distinct tools. Git was created by Linus Torvalds in 2005. GitHub was founded in 2008 as a company providing Git hosting. Other Git hosts include GitLab, Bitbucket, and AWS CodeCommit. They are not interchangeable names for the same tool. This option erases the distinction entirely.

Reference:
Git SCM Docs – "About Git" – Git is a free and open source distributed version control system. GitHub Docs – "About GitHub" – GitHub is a code hosting platform for version control and collaboration based on Git. The two are complementary but separate: Git is the tool; GitHub is a hosting service.

Explanation:
GitHub automatically closes issues when a pull request is merged if the pull request description contains specific keywords followed by the issue number. These keywords create a bidirectional link between the pull request and the issue. Understanding which keywords are recognized helps automate issue tracking and reduces manual closure steps.

Correct Option:

✅ A – fix
The keyword "fix" (along with its variants "fixes" and "fixed") is recognized by GitHub to link a pull request to an issue. For example, writing "fixes #123" in the pull request description will automatically close issue #123 when the pull request is merged. "Fix" is one of the standard closing keywords.

✅ B – closed
The keyword "close" (including "closes" and "closed") is recognized by GitHub. For example, "closes #456" will close the referenced issue upon pull request merge. "Closed" is the past tense but still functions correctly. GitHub's documentation explicitly lists "close" and "closes" among the default closing keywords.

✅ E – resolves
"Resolves" is a recognized closing keyword. For example, writing "resolves #789" in a pull request description will automatically link to issue #789 and close it when the pull request is merged. This keyword is commonly used in teams that prefer "resolves" over "fixes" for feature work or general task completion.

Incorrect Option:

❌ C – merge
"Merge" is not a recognized keyword for linking or closing issues. Typing "merge #123" in a pull request description will not close issue #123. GitHub's closing keyword list includes "fix," "close," "resolve," and their variants, but not "merge." This is a common misconception, as merging a PR does not automatically close issues without proper keywords.

❌ D – connects
"Connects" is not a standard GitHub closing keyword. While you can use it to mention an issue (e.g., "connects to #123"), it will not close the issue when the pull request is merged. Some project management tools like ZenHub use custom keywords, but natively, GitHub does not recognize "connects" as an auto-closing keyword.

❌ F – join
"Join" has no special meaning in GitHub's issue linking syntax. Using "join #123" in a pull request description does not create a link nor close the issue. This keyword is not documented anywhere in GitHub's help pages regarding issue or pull request cross-referencing.

Reference:
GitHub Docs – "Linking a pull request to an issue" – The default closing keywords are: close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved. These keywords, followed by an issue number in a PR description, automatically close the issue when the PR is merged. "Merge," "connects," and "join" are not recognized keywords.

Explanation:
GitHub provides special URL endpoints for viewing social interactions on a repository. To see a list of users who starred a repository, you can append a specific path to the repository's base URL. This is different from the "Watch" feature (notifications) and is a dedicated page that GitHub has historically made available for public repositories.

Correct Option:

✅ B – stargazers
Appending /stargazers to a repository URL (e.g., https://github.com/github/docs/stargazers) shows the list of users who have starred that repository. The term "stargazers" is GitHub's official name for users who star a repository. This page displays avatars, usernames, and optionally the order in which they starred. It is accessible for public repositories and some private repositories depending on visibility settings.

Incorrect Option:

❌ A – stars
/stars is not a valid endpoint for viewing stargazers. Attempting to access https://github.com/github/docs/stars typically results in a 404 Page Not Found error. While "stars" is the count displayed on the repository header, the correct path to view the list of users is /stargazers, not /stars. This is a common user mistake.

❌ C – starviewers
/starviewers is not a recognized GitHub URL path. This term is fabricated and does not correspond to any GitHub feature. GitHub uses "stargazers" as the standard terminology. Using this path will lead to a 404 error. No documentation or interface refers to "starviewers."

❌ D – starwatcher
/starwatcher (singular) is not a valid endpoint. GitHub uses the term "stargazers" (plural) for the collection of users who star a repository. "Watchers" or "watch" refer to a different feature: users who subscribe to repository notifications. This option confuses starring (bookmarking/appreciation) with watching (notification settings). The correct term is stargazers.

Reference:
GitHub Docs – "Viewing who starred a repository" – Navigate to the repository, click the "X stars" link, or append /stargazers to the repository URL. GitHub API also uses "stargazers" as the endpoint (e.g., GET /repos/{owner}/{repo}/stargazers). "Stars" is the count; "stargazers" are the users. "Watchers" refers to notification subscribers.

Explanation:
GitHub Projects (specifically the new Projects experience, also called Projects V2) includes an Insights feature that allows users to create charts based on project items. These charts help visualize progress, track work over time, and identify bottlenecks. GitHub offers specific chart types for different analytical needs, not all common chart types (like pie or Gantt) are available.

Correct Option:

✅ C – current charts
Current charts display a snapshot of the project's items at the present moment, grouped or filtered by field values (e.g., status, assignee, priority). Examples include a bar chart of open issues by assignee or a column chart of items by status. Current charts are static and reflect the project's state at the time of viewing, without time-based trends.

✅ E – historical charts
Historical charts show how a project metric has changed over time. They are created by selecting a "Historical" chart type and configuring an X-axis (usually a date field like "Created date" or "Closed date") and a Y-axis (e.g., item count). These charts help track progress, spot trends (e.g., increasing bug count), and measure velocity over days or weeks.

Incorrect Option:

❌ A – pie charts
Pie charts are not supported in GitHub Projects Insights. While pie charts are common in other analytics tools, GitHub's charting engine (which is based on column, bar, and line chart types) does not include pie charts. Current charts use bar or column representations, not pie. Circular representations are not available.

❌ B – Gantt charts
Gantt charts (timeline-based bar charts showing task dependencies and durations) are not natively available in GitHub Projects Insights. GitHub does not support date-based dependency visualization or critical path analysis. While third-party integrations or Power Ups might add Gantt charts, native Projects Insights only offers current and historical charts.

❌ D – forecast charts
Forecast charts are not a native chart type in GitHub Projects Insights. While historical charts can show past trends, GitHub does not provide predictive or forecasting algorithms (e.g., predicting completion dates based on past velocity). Any forecasting would require external tools or manual analysis. This is not a built-in option.

Reference:
GitHub Docs – "About Insights for Projects" – Insights allows creation of two chart types: current (snapshot of project data) and historical (trends over time). Pie charts, Gantt charts, and forecast charts are not listed as supported chart types. GitHub Projects does not include predictive analytics or dependency visualization natively.

Explanation:
GitHub Copilot is an AI pair programmer that provides code suggestions in real time within supported editors. To start using Copilot, users must complete both a subscription/activation step and an installation step in their development environment. Understanding these requirements ensures a smooth setup and avoids confusion about prerequisites like storing code on GitHub.

Correct Option:

✅ A – Install the Copilot extension for your supported IDE
Copilot integrates directly into development environments. Supported IDEs include Visual Studio Code, Visual Studio, JetBrains IDEs (IntelliJ, PyCharm, etc.), Neovim, and GitHub Codespaces. For each IDE, you must install the official GitHub Copilot extension or plugin from the respective marketplace. This extension enables the AI suggestions within your coding interface.

✅ B – Sign up for a Copilot edition and enable it for your account
Copilot requires a paid subscription (monthly or yearly) or a free trial. Users must sign up for a Copilot plan (Individual, Business, or Enterprise) on GitHub.com and enable it for their personal account. For organizations, an admin must assign seats to members. Without an active subscription, the extension will not function even if installed.

Incorrect Option:

❌ C – Sign and submit the legal disclaimer
GitHub Copilot does not require any legal disclaimer signature or submission. Standard terms of service and subscription agreement are accepted during signup via checkboxes. There is no separate "legal disclaimer" document to sign. This option appears to confuse Copilot with other software requiring explicit legal agreements.

❌ D – Install the Copilot App on your GitHub organization, account or server
Copilot is not installed as a "GitHub App" on organizations or servers. It is a cloud-based AI service accessed via IDE extensions. While organization admins can manage Copilot subscriptions and seat assignments, no app installation occurs on the GitHub account or server side. This option misrepresents Copilot's architecture.

❌ E – Store your coding project(s) in GitHub
Copilot does not require your code to be stored on GitHub. It works with local projects, projects stored in other Git hosts (GitLab, Bitbucket), or even non-Git directories. Copilot analyzes the code open in your editor and provides suggestions based on its public training data, not based on remote storage location.

Reference:
GitHub Docs – "Getting started with GitHub Copilot" – Setup steps: (1) Subscribe to a Copilot plan (enable for your account), (2) Install the extension in your IDE, (3) Sign in with your GitHub account. No legal disclaimer, no GitHub App installation, and no requirement to store code on GitHub. These two steps (A and B) are universally required.

Explanation:
A pull request is a GitHub feature that proposes changes from one branch to another. Understanding the relationship between the source and target branches is fundamental. While many users create pull requests from a feature branch to main within the same repository, the branches must be distinct entities for a pull request to make sense.

Correct Option:

✅ D – Different
A pull request must be created between two different branches. The source branch (where changes were made) and the target branch (where changes will be merged) cannot be the same branch. Even if both branches have identical content, they must be distinct references. Attempting to create a pull request from a branch to itself is impossible in GitHub's interface, as there would be no changes to compare.

Incorrect Option:

❌ A – Authored by the same user
Pull requests can be created regardless of authorship. The user creating the pull request does not need to be the author of either branch. Branches can be created by any collaborator with write access, and pull requests can be opened by any user (including outside collaborators) across forks. Authorship is irrelevant to branch creation.

❌ B – Authored by different users
This is not a requirement. A single user can create both the source and target branches and open a pull request between them (e.g., a feature branch and main in a personal repository). Pull requests are not limited to cross-author scenarios. The necessary condition is that the branches are different, not that they have different authors.

❌ C – The same
This is false. A pull request cannot be created between the same branch. If you attempt to select the same branch as both source and target, the GitHub interface will disable the "Create pull request" button, show an error, or indicate that there are no changes to compare. The comparison requires two distinct branch references.

Reference:
GitHub Docs – "About pull requests" – Pull requests require two distinct branches: a head branch (source) and a base branch (target). GitHub compares the changes between these branches. The branches can be in the same repository or in different forks (cross-repository pull requests). They must be different; authorship is irrelevant.