Microsoft GH-900 GitHub Foundations Exam Practice Test

GitHub is a cloud-based platform that provides hosting for software development and version control using Git. It offers tools for collaboration, project management, and security to create a safe and productive environment for developers.

GitHub Overview:

Option B is correct because GitHub is primarily known as a cloud-based hosting service for Git repositories, offering a collaborative environment where developers can work together on projects, manage version control, and implement security practices.

Incorrect Options:

Option A is incorrect because GitHub is not proprietary in the sense of being closed off from version control standards; it is widely recognized as an open platform for collaboration.

Option C is incorrect because, while GitHub is accessible to new developers, it is designed for developers of all skill levels and not specifically tailored for beginners.

Option D is incorrect because GitHub is not a centralized version control system; it supports Git, which is distributed.

GitHub Sponsors is a program designed to provide a platform for developers and companies to financially support open-source projects and their maintainers.

Financial Support for Open Source Projects:

Option D is correct because the main purpose of GitHub Sponsors is to allow members of the developer community, including individuals and organizations, to financially support open-source projects and maintainers. This helps sustain open-source development by providing developers with the resources they need to continue their work.

Incorrect Options:

Option A is incorrect because GitHub Sponsors is not based on project popularity (e.g., stars); it is based on voluntary contributions.

Option B is incorrect because while GitHub provides the platform, the purpose of GitHub Sponsors is not for GitHub itself to fund projects, but to enable the broader community to do so.

Option C is incorrect because GitHub Sponsors is not a marketplace for purchasing software but a platform for supporting developers.

On GitHub, you can choose to receive ongoing updates about specific activities by subscribing to notifications for all activity in a repository. This allows you to stay informed about all changes, discussions, and updates related to a particular project. Additionally, GitHub provides the ability to customize notifications to suit your preferences.

=================

In a Git repository, a file can be in one of the following three valid states:

Committed: The file is saved in the local repository. It is part of the permanent history of the project.

Modified: The file has been changed but not yet staged or committed. It is in the working directory.

Staged: The file has been marked to be included in the next commit. It is in the staging area, ready to be committed.

These states represent the typical lifecycle of a file as it moves through the process of being edited, reviewed, and saved in Git.

=================

In Git, a branch is a fundamental concept that represents an independent line of development within a project. Here's a more detailed explanation:

Branch in Git:

Option C is correct because a branch in Git is essentially a separate, isolated copy of the project's codebase where you can make changes without affecting the main codebase. Branches allow developers to work on features, fixes, or experiments in parallel to the main project.

Other Options:

Option A is incorrect because while a branch does point to a specific commit (which represents a snapshot of the project), the description lacks the emphasis on the isolated and parallel development aspect that is critical to the understanding of branches.

Option B is incorrect because a branch is not a physical copy stored on disk; it is a logical reference within the repository.

Option D is incorrect because that description better fits the concept of a fork, not a branch. A fork is a new repository that is a copy of another repository, usually used to contribute back to the original ("upstream") repository.

When multiple README files exist in different locations within a GitHub repository, the README.md file located in the root directory of the repository will be displayed first by default. This file serves as the main documentation for the repository and is automatically rendered on the repository's home page.

Root Directory:

Option C is correct because the README.md file in the root directory is prioritized and displayed first on GitHub. This is the standard behavior for how GitHub presents documentation.

Incorrect Options:

Option A (.github) is incorrect because while a README.md file in the .github directory might be used for certain configurations, it is not the first to be displayed.

Option B (/src) is incorrect because the README.md in the src directory is not prioritized over the root.

Option D (/docs) is incorrect because documentation in the /docs folder is typically secondary to the root README.md.

To highlight a post at the top of the Discussions page on GitHub, you can Pin the discussion. Pinning a discussion ensures it remains prominently visible at the top of the list, making it easier for others to find and participate in that discussion. This is particularly useful for important announcements or frequently referenced topics.

=================

The qualifier mentions: is used in GitHub's search functionality to find issues that mention a certain user. For example, if you want to find all issues where a specific user is mentioned, you would use mentions:username. This helps in tracking where a user has been involved in discussions across issues or pull requests.

=================

In GitHub, when viewing the list of projects for an organization, a user can identify a GitHub Projects template by selecting the Templates tab. This tab specifically lists available templates that can be used to create new projects based on predefined structures and workflows.

=================

Pull requests are created to propose changes from one branch to another. These branches must be different; otherwise, there would be no changes to propose. Typically, pull requests are made from a feature or topic branch to a main branch (such as main or master), allowing for code review and integration before the changes are merged.

=================

On GitHub, certain actions automatically subscribe you to conversations so that you receive notifications about further activity in that thread.

Opening a Pull Request or Issue:

Option C is correct because when you open a pull request or issue, you are automatically subscribed to the conversation and will receive notifications for any updates.

Commenting on a Thread:

Option D is correct because commenting on an issue or pull request automatically subscribes you to that thread, ensuring you are notified of further comments or changes.

Being Assigned to an Issue or Pull Request:

Option E is correct because when you are assigned to an issue or pull request, you are automatically subscribed to notifications related to it.

Incorrect Options:

Option A is incorrect because pushing a commit to the default branch does not automatically subscribe you to conversations.

Option B is incorrect because being added as a repo admin does not automatically subscribe you to specific conversations unless you engage with them.

When using GitHub Codespaces, you can customize several aspects of the development environment:

Shell: You can choose the default shell to be used in the Codespace, such as Bash, Zsh, or PowerShell.

Name: Users can customize the name of their Codespace for easier identification.

Default editor: You can choose which editor to use within the Codespace, such as Visual Studio Code or others that may be supported.

Branch protections and the operating system are not customizable for an individual Codespace within GitHub, making the options Shell, Name, and Default editor the correct answers.

=================

The Codespaces lifecycle on GitHub includes several key steps:

Create: This is the step where a new Codespace is initiated.

Rebuild: A Codespace can be rebuilt to ensure that the environment is up-to-date with the latest code or configurations.

Delete: Once a Codespace is no longer needed, it can be deleted to free up resources.

Committing, cloning, or installing are typical Git operations but are not considered part of the specific lifecycle steps for a GitHub Codespace.

=================

GitHub Projects supports various layouts to help teams organize and visualize their work. The available layouts include:

B. Kanban: This is a visual task management tool where tasks are represented as cards and moved across columns that represent different stages of work.

C. Board: This layout is similar to Kanban but can be more flexible, allowing users to set up boards in various ways to suit their workflow needs.

D. Table: The Table layout allows you to view your tasks in a spreadsheet-like format, making it easy to manage and edit large amounts of data at once.

Roadmap and Backlog are not standard layouts provided by GitHub Projects. While these terms might be relevant in other project management contexts, GitHub Projects specifically offers Kanban, Board, and Table layouts.

=================

The CODEOWNERS file in a GitHub repository is used to define individuals or teams that are responsible for specific parts of the codebase. When changes are made to files or directories that match the patterns specified in the CODEOWNERS file, GitHub automatically requests reviews from the listed code owners.

Setting Reviewers Automatically:

Option D is correct because the primary purpose of a CODEOWNERS file is to automatically set reviewers for pull requests that affect the specified files or directories. This ensures that the appropriate team members are notified and review the changes before they are merged.

Incorrect Options:

Option A is incorrect because the CODEOWNERS file does not restrict who can edit specific files; it only influences who is required to review changes.

Option B is partially related but not fully accurate because while CODEOWNERS does require certain reviews, it does not mandate peer review for all code changes.

Option C is incorrect because the CODEOWNERS file does not define access permissions for the repository; it deals with code review processes.

As mentioned in the answer to Question no. 66, GitHub Actions workflows can reference actions from a variety of sources:

Any Public Repository:

Option A is correct. Actions can be sourced from any public GitHub repository.

The Same Repository as Your Workflow File:

Option B is correct. Actions within the same repository as the workflow file can be referenced directly.

A Published Docker Container Image on Docker Hub:

Option E is correct. Workflows can also use actions provided as Docker container images from Docker Hub.

Incorrect Options:

Option C and D are not relevant for directly referencing actions in workflows.

Innersource is a development practice where an organization adopts open-source development methodologies within its own internal environment. The primary goal of innersource is to break down silos and encourage collaboration across different teams within the organization.

Sharing Code Between Teams:

Option B is correct because innersource involves sharing code between teams within the organization, similar to how open-source communities share code across the public domain. This practice fosters collaboration, improves code quality, and allows for reuse of code, reducing duplication of efforts.

Incorrect Options:

Option A is incorrect because adopting open-source code into the organization is related to using open-source software, not specifically to innersource practices.

Option C is incorrect because removing open-source code from the organization is contrary to the principles of both open source and innersource.

Option D is incorrect because making all repositories publicly accessible refers to open source, not innersource. Innersource typically involves keeping code internal to the organization.

GitHub Copilot for Business offers several features that are tailored to the needs of organizations, providing more control, security, and support compared to the individual version.

Organization-wide Policy Management:

Option B is correct because Copilot for Business allows organizations to manage policies across their entire user base, providing control over how Copilot is used within the organization.

Blocking Suggestions Matching Public Code:

Option C is correct because Copilot for Business includes enhanced security features, such as blocking code suggestions that match public code to prevent inadvertent use of unlicensed code.

Support for Organization or Enterprise GitHub Accounts:

Option E is correct because Copilot for Business supports integration with GitHub Enterprise accounts, offering additional administrative controls and integration capabilities.

Incorrect Options:

Option A (multi-line function suggestions) is a feature available in both individual and business versions, so it does not differentiate the business offering.

Option D (VPN proxy support via self-signed certificates) is not a primary differentiator of Copilot for Business.

Option F (plugs directly into the editor) is true for both individual and business versions, so it is not unique to Copilot for Business.

GitHub Enterprise Cloud with Enterprise Managed Users (EMU) integrates closely with an organization's identity provider (IdP), such as Azure Active Directory, to manage user accounts. The primary benefit of this setup is centralized control and streamlined management. It allows organizations to enforce policies, manage user permissions, and provision or deprovision accounts directly through their IdP, ensuring consistency and security across the organization. This approach is ideal for large enterprises that require tight control over their users and resources.

=================

From a discussion post on GitHub, a user can Create an issue from the discussion. This feature allows users to turn a discussion into an actionable item by creating an issue directly from the discussion thread. This is particularly useful when a conversation identifies a bug, task, or enhancement that needs to be tracked in the repository.

=================

GitHub supports various syntax formats that align with Markdown and HTML conventions. Here's a breakdown of the provided options:

Comment Syntax:

Option C is correct. The syntax is used in Markdown files to insert comments. These comments will not be rendered in the final output, making them useful for adding notes or instructions within the code or documentation.

Incorrect Options:

Option A (* This is a heading) is incorrect because an asterisk (*) denotes an unordered list item, not a heading. A heading in Markdown is typically created with one or more hash symbols (#).

Option B (This is a link) is incorrect because this is plain text and not the syntax for creating a link. The correct syntax would be [This is a link](URL).

Option D (This is bolded text) is incorrect because this is plain text, not the correct Markdown syntax for bold text, which should be **This is bolded text** or __This is bolded text__.

Option E (1. This is an ordered list) is incorrect as it does represent an ordered list item, but it was not the syntax format asked about in the question. The question specifically focuses on matching associated text with syntax, where only the comment option is correct.

In GitHub, an organization member is a user who has been added to an organization and is subject to the organization's base permissions and policies. An outside collaborator is a user who is not a member of the organization but has been granted access to one or more repositories within the organization.

Here’s the difference between an organization member and an outside collaborator:

Organization Members:

Members are subject to the organization's base permissions, which apply across all repositories within the organization. These permissions might include read, write, or admin access, depending on what has been set as the default.

Members consume paid licenses if the organization is on a paid plan.

Members are required to have two-factor authentication (2FA) if the organization enforces it.

Outside Collaborators:

Outside collaborators do not have organization-wide permissions. They only have access to specific repositories to which they have been granted permission. This means organization base permissions do not apply to them (making option A correct).

Outside collaborators do not consume paid licenses. They are only counted toward the license if they are made organization members.

Outside collaborators can be granted any level of permission, including the admin role on specific repositories.

Two-factor authentication (2FA) can be enforced for outside collaborators at the repository level, depending on the organization's security settings.

Given this information, option A is the correct answer: "Organization base permissions do not apply to outside collaborators."