Microsoft GH-900 GitHub Foundations Exam Practice Test

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. "

Organization owners on GitHub have control over how GitHub Actions can be used within their organization. They can enforce restrictions to ensure security and compliance with organizational policies.

Allow Actions That Use Self-Hosted Runners:

Option A is correct because organization owners can configure the usage of self-hosted runners, allowing greater control over the environment where actions are run.

Allow Specified Actions:

Option C is correct because organization owners can allow only specific actions to run, adding a layer of security by limiting actions to those that have been vetted.

Allow Actions by Marketplace Verified Creators:

Option D is correct because organization owners can choose to allow actions created by GitHub Marketplace verified creators, ensuring that only trusted actions are used.

Incorrect Options:

Option B is incorrect because GitHub Actions are not designed to be run directly from a Codespace; Codespaces are for development environments.

Option E is a valid choice, but since the prompt asks for only three answers, it is not included in this response.

GitHub provides several pre-defined repository roles that determine the level of access and permissions a user has within a repository. The roles that are included by default are:

Triage : Allows users to manage issues and pull requests without write access to the code.

Maintain : Provides more extensive access, including managing settings, but without full administrative control.

Write : Grants permission to push changes and manage issues and pull requests.

Roles like " Security " and " Delete " are not standard pre-defined roles, and " View " is generally referred to as " Read " in GitHub ' s permission structure.

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

A gist on GitHub is essentially a Git repository, albeit a simplified one, designed for sharing snippets of code, notes, or other text content. Gists support version control and can be public or secret.

Gist as a Git Repository:

Option B is correct because each gist is a Git repository, meaning you can clone it, commit changes, and even fork it, just like any other Git repository.

Incorrect Options:

Option A is incorrect because a gist is not an app; it’s a feature of GitHub that provides a simplified repository.

Option C is incorrect because while a gist may contain Markdown documents, it is fundamentally a repository that can hold various file types.

Option D is incorrect because GitHub Pages is a separate service for hosting websites, not related to gists.

GitHub Sponsors allows developers and organizations to financially support open-source contributors directly on the GitHub platform.

Setting Up a Sponsored Developer Profile:

Option D is correct because before a contributor can receive funding through GitHub Sponsors, they need

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

When creating an issue in GitHub, the issue form captures the information needed to describe the work, bug, question, or request. The title identifies the issue in lists, search results, notifications, and project views. The description provides context, details, steps to reproduce, expected behavior, screenshots, or other supporting information. Repository visibility is configured in repository settings, not when opening an issue. Branch name and commit message are related to Git changes and commits, not issue creation. GitHub issues are designed for tracking work and discussion, so the key information belongs in the issue title and description. A clear title and useful description make it easier for maintainers and collaborators to triage, assign, prioritize, and resolve the issue efficiently.

GitHub Projects is a flexible and powerful tool for project management that allows users to manage their work with ease. One of the key characteristics of GitHub Projects is the ability to create and customize multiple views. This feature enables teams to tailor the project management experience to their specific workflow needs, offering various ways to visualize tasks, issues, and work items.

Custom Views: You can set up different views like Kanban boards, tables, or timelines, and apply filters to show only what is relevant for a particular aspect of the project. This customization allows teams to organize their work in a way that best suits their processes, making it a highly adaptable project management tool.

Other options, such as visualizing commit history (which would fall under the ' Insights ' feature), importing Gantt charts (which GitHub Projects does not natively support), or enforcing required fields (which might relate to form-based tools but not to GitHub Projects specifically), do not align with the key characteristics of GitHub Projects.

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

The primary purpose of creating a security policy in a GitHub repository is to guide users and contributors on how to report security vulnerabilities in a responsible and secure manner. This policy outlines the preferred method of communication, timelines, and any other pertinent information related to handling security issues.

Security Policy:

Option C is correct because a security policy provides guidelines for responsibly disclosing security vulnerabilities. This helps maintainers respond to and address security concerns promptly and securely, thereby protecting the project and its users.

Incorrect Options:

Option A is incorrect because ensuring peer code review is a best practice for code quality, but it is not the primary purpose of a security policy.

Option B is incorrect because push protection for secrets is managed through repository settings, not the security policy.

Option D is incorrect because customizing Dependabot configuration is related to dependency management, not directly to security policies.

The GitHub Command Palette provides quick keyboard-based access to navigation, commands, repositories, issues, pull requests, projects, and other GitHub areas. On GitHub.com, Windows and Linux users can open the Command Palette by pressing Ctrl+K. This shortcut helps users move faster through GitHub without relying only on menus or page navigation. Ctrl+S is commonly associated with saving in many applications, not opening the GitHub Command Palette. Shift+Enter is generally used for line breaks or text-entry behavior in many interfaces. Alt+P is not the standard GitHub.com shortcut for this feature. Knowing Command Palette shortcuts is useful for the GitHub Foundations exam because it tests productivity features available directly in the GitHub web interface.

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.

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

GitHub Desktop is a graphical interface that allows users to interact with GitHub repositories. It simplifies certain Git operations without the need for command-line usage.

GitHub Desktop Capabilities:

Option C is correct because GitHub Desktop allows users to add local repositories to their GitHub account, clone repositories from GitHub to their local machine, and manage repositories effectively.

Incorrect Options:

Option A is incorrect because GitHub Desktop does not support creating or managing issues directly; this is done through the GitHub web interface.

Option B is incorrect because reviewing and approving pull requests is also managed through the GitHub web interface.

Option D is incorrect because commenting on discussions is done on the GitHub platform, not through GitHub Desktop.

Option E is incorrect because GitHub Desktop does not integrate with office suite software.

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.

Git is a widely-used version control system that has several defining features:

Distributed Version Control:

Git is a distributed version control system, meaning that every developer has a full copy of the entire repository, including its history, on their local machine. This enables greater flexibility, as work can be done offline and each user has access to the full project history.

Open Source Software:

Git is open-source, meaning its source code is freely available for use, modification, and distribution. This fosters a large community of users and contributors who continuously improve the software.

Efficiency with Large Projects:

Git is designed to handle projects of any size with speed and efficiency. It can manage large codebases and many contributors without significant performance degradation, making it suitable for everything from small personal projects to large, complex software systems.

Incorrect Options:

Option B is incorrect because Git is not a sequential version control system, nor is it inherently tied to cloud-based services. GitHub, GitLab, and other platforms offer cloud hosting for Git repositories, but Git itself is a version control tool.

Option C is incorrect because Git is not limited to small projects; it is designed to scale efficiently, and the other features mentioned are only partial descriptions of Git ' s capabilities.

Option D is incorrect because Git is not a centralized version control system; it is distributed. Additionally, Git is open-source, not proprietary, and is used for projects of all sizes.

Markdown is a lightweight markup language with plain-text formatting syntax. It is designed to be easy to write and read in its raw form, and it can be converted into HTML and other formats. Markdown is commonly used for formatting readme files, writing messages in online discussion forums, and creating rich text documents.

Markup Language:

Option A is correct because Markdown is indeed a markup language. It is not a programming language, scripting language, version control system, or containerization solution.

Incorrect Options:

Option B is incorrect because Markdown is not a programming language; it does not involve control structures or variables.

Option C is incorrect because Markdown is not used for scripting or automation.

Option D is incorrect because Markdown does not manage version control.

Option E is incorrect because Markdown is not related to containerization technologies like Docker.

GitHub Mobile provides a streamlined experience for managing your GitHub notifications and participating in discussions, but it does not offer full functionality compared to the desktop or web interface.

Managing Notifications:

Option E is correct because GitHub Mobile allows users to manage notifications, keeping them up to date with their repositories, issues, pull requests, and other activities on GitHub.

Incorrect Options:

Option A is incorrect because GitHub Mobile cannot be used as a self-hosted runner.

Option B is incorrect because managing enterprise and organization settings is not supported in GitHub Mobile.

Option C is incorrect because GitHub Mobile does not offer a chat or voice calling feature.

Option D is incorrect because forking and cloning repositories are not actions available in GitHub Mobile.

A distributed version control system (DVCS) like Git is best described as a system that ensures each developer has their own local copy of the entire code repository, including the complete project history and metadata. This decentralized approach allows developers to work independently, with full access to the project ' s history and files, and later synchronize their changes with others. Unlike centralized systems, DVCS does not rely on a single central server, which provides greater flexibility and robustness in collaboration.

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

The GitHub Marketplace is the place where users can discover, browse, and install various tools and integrations that extend the functionality of GitHub. These tools can include CI/CD services, security checks, and other development utilities that enhance workflow automation and project management.

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

GitHub Copilot is described as an AI pair programmer that offers autocomplete-style suggestions. It is a tool integrated into development environments like Visual Studio Code that helps developers by providing code suggestions as they type. Copilot can suggest entire lines or blocks of code based on the context of what you’re writing, making it a valuable assistant in coding, but not a replacement for developers.

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

GitHub ' s community is centered around enabling developers to collaborate and innovate together. The platform provides tools and environments that foster open communication, sharing of ideas, and collective problem-solving.

Facilitating Collaboration and Creativity:

Option C is correct because GitHub is designed to be a collaborative platform where developers can work together on projects, share code, and contribute to open source initiatives, all in an environment that encourages creativity.

Incorrect Options:

Option A is incorrect because GitHub is inclusive of developers of all skill levels, not just experienced ones.

Option B is incorrect because GitHub is not about creating a competitive environment; rather, it focuses on collaboration.

Option D is incorrect because while code quality is important, enforcing strict code quality standards is not the primary goal of the GitHub community.

GitHub Actions are automated workflows that can be triggered by various events on GitHub. Some common events that trigger workflows include pushes to a repository, creation of issues, and comments on discussion posts.

Triggering GitHub Actions:

Option D (Pushing to a GitHub repository) is correct because this is one of the most common triggers for CI/CD workflows.

Option F (Creating an Issue) is correct because issues are commonly used as triggers for workflows, such as automatically assigning a label or notifying a team.

Option A (Adding a comment to a discussion post) is correct because actions can be triggered by activity on discussion posts, including comments.

Incorrect Options:

Option B (Creating a new repository) is incorrect because this action typically does not trigger workflows within a specific repository.

Option C (Committing a change to a local git repository) is incorrect because GitHub Actions are triggered by events on the GitHub platform, not by local commits.

Option E (Disabling a GitHub runner) is incorrect because it is related to the environment where actions are executed, not a trigger for workflows.

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 .

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 GitHub Actions workflows, actions can be referenced from various sources depending on the needs of the workflow.

Any Public Repository:

Option A is correct. Actions can be referenced from any public GitHub repository, allowing the reuse of shared actions across multiple projects.

The Same Repository as Your Workflow File:

Option B is correct. Actions stored in the same repository as the workflow file can be referenced directly, which is common for custom actions specific to that project.

A Published Docker Container Image on Docker Hub:

Option E is correct. Workflows can reference actions that are provided as Docker container images hosted on Docker Hub, allowing integration of complex tools and environments.

Incorrect Options:

Option C (GitHub Packages) is incorrect as it is more commonly used for storing and managing dependencies, not actions.

Option D (An enterprise marketplace) is incorrect because GitHub Actions are not directly referenced from an enterprise marketplace but rather from public repositories or Docker images.

As a GitHub user, you can configure two-factor authentication (2FA) to secure your account by navigating to Settings - > Password and Authentication - > 2FA. This section in the GitHub user inter face allows you to set up and manage your 2FA methods, which provide an additional layer of security beyond just your password.

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

A centralized version control system stores the main project history in one central location, usually a server. Developers connect to that server to check out files, make changes, and submit updates. This differs from Git, which is distributed and allows every developer to have a full local copy of the repository history. In a centralized model, collaboration depends heavily on the availability of the central server. If the server is unavailable, developers may be limited in what they can do. GitHub Foundations emphasizes this distinction because GitHub is built around Git, a distributed version control system. Option C correctly describes centralized version control because the central server holds the authoritative project history.

The feature you can use to merge proposed changes in a repository on GitHub is Pull requests. Pull requests are a core feature of GitHub, allowing developers to propose changes to a codebase, review code, discuss the changes, and eventually merge them into the main branch. This collaborative workflow ensures that code is reviewed and vetted before becoming part of the project.

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

GitHub provides a powerful search syntax to filter and find specific issues across repositories in an organization.

Search Query Syntax:

Option A is correct because the query org:Avocado is:issue label:guacamole " 404 error " is the best way to search for all issues within the " Avocado " organization that contain the text " 404 error " and are labeled with " guacamole " . This query is precise and leverages GitHub’s advanced search capabilities.

Incorrect Options:

Option B is incorrect because it requires manual filtering in a specific repository rather than searching across the entire organization.

Option C is incorrect because selecting " Issues " in the filter by section is redundant when using the query is:issue .

Option D is incorrect because accessing organization settings to look for repository labels is not relevant to searching for issues.

The primary benefits of using GitHub issues templates include:

A. To automatically label or assign newly created issues : Issue templates can be configured to automatically apply labels or assign users when the issue is created, helping to streamline triage and management processes.

B. To provide an easy-to-fill-out form for creating new issues : Templates provide a standardized format for submitting issues, ensuring that all necessary information is captured and reducing the need for follow-up questions.

Coercing existing issues into a standard format or automatically creating new branches when issues are created are not functions provided by GitHub issues templates.

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

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.