GH-900 Practice Questions

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

Reference:

GitHub Documentation: Roles in an organization

GitHub Documentation: About outside collaborators

GitHub Documentation: Managing repository access for your organization

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

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.

Reference:

GitHub Docs: Searching Issues and Pull Requests

Commits and pull requests (PRs) are fundamental concepts in Git and GitHub workflows, particularly

in collaborative software development.

Commits:

Commits are individual changes or updates made to the codebase. Each commit is identified by a

unique SHA-1 hash and typically includes a commit message describing the changes.

Commits are made to a specific branch in the repository. The branch could be the main branch, or

more commonly, a feature branch created for specific work or a feature.

Pull Requests (PRs):

A pull request is a mechanism for developers to notify team members that a branch is ready to be

merged into another branch, usually the main branch.

PRs are used to review code, discuss changes, and make improvements before the branch is merged

into the target branch.

Relationship Between Commits and PRs:

Option A is correct because commits are made on a branch, and this branch can have a pull request

associated with it. The pull request tracks the branch’s commits and allows for code review before

merging into the target branch.

Commits can be added to the branch both before and after the pull request is created. Any new

commits pushed to the branch are automatically included in the pull request.

Incorrect Options:

Option B is incorrect because commits can be made both before and after a pull request is created.

Option C is incorrect because it suggests that commits can only be made before a pull request is

created, which is not true.

Option D is incorrect because commits are not made on a pull request; they are made on a branch.

The pull request links a branch to another branch (e.g., feature branch to the main branch).

Reference:

GitHub Documentation: About Pull Requests

GitHub Docs: Understanding the GitHub Flow

Git Documentation: Git Basics - Getting a Git Repository

GitHub provides repository admins with a feature called "Insights" where they can view various pre-

built visualizations and analytics related to the repository.

Insights:

Option C is correct because the "Insights" tab in a GitHub repository offers various pre-built

visualizations, including contributions, traffic, code frequency, dependency graphs, and more. This

helps admins and maintainers track the project's activity and health.

Other Options:

Option A (Settings) is incorrect because the Settings tab is where you configure repository settings,

permissions, and integrations, but it does not provide visualizations of repository data.

Option B (Issues) is incorrect because the Issues tab is used for tracking bugs, enhancements, and

other tasks but does not provide data visualizations.

Option D (Charts) is incorrect as there is no "Charts" tab or section in GitHub. The correct location for

data visualizations is under "Insights."

Reference:

GitHub Docs: Viewing Repository Insights

In GitHub, issues and pull requests (PRs) are essential tools for managing work and collaboration in a

project. Assigning individuals to these issues or PRs is a way to indicate responsibility for addressing

the issue or completing the PR.

Anyone with write permissions to the repository:

Users who have write permissions to a repository can be assigned to issues and pull requests. Write

permissions allow users to push changes to the repository, create branches, and modify issues and

pull requests. Assigning them to an issue or PR ensures they are recognized as responsible for the

task.

Anyone who has commented on the Issue or pull request:

GitHub allows you to assign issues or pull requests to users who have already engaged with the

discussion by commenting on it. This feature is particularly useful for quickly assigning tasks to those

who are already involved in the conversation.

Incorrect Options:

Option A is incorrect because having an enterprise GitHub account alone does not necessarily grant

the ability to be assigned to issues or PRs. Permission to assign is based on repository-specific roles

and permissions.

Option C is incorrect because not all personal GitHub accounts can be assigned to issues or PRs. The

user needs either write permissions to the repository or must have commented on the issue or PR.

Reference:

GitHub Docs: Assigning Issues and Pull Requests

GitHub Docs: Permission Levels for a Repository

This detailed explanation provides clarity on GitHub's assignment mechanics for issues and pull

requests, reflecting the platform's collaborative nature.

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.

Reference:

GitHub Docs: What is Innersource?

Innersource Commons: The Basics

When creating custom issue forms on GitHub, the definition files are stored in the

.github/ISSUE_TEMPLATE folder. This directory is used to define issue templates and forms that help

standardize the information collected when users open new issues in the repository. The .github

folder is a special directory used for various repository configurations and workflows.

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.

Reference:

GitHub Docs: GitHub Copilot for Business

Thank you for your visit.

The following two-factor authentication (2FA) methods can be used to secure a GitHub account:

A . Authenticator app: You can use an authenticator app (like Google Authenticator or Authy) to

generate time-based one-time passwords (TOTP) for logging in.

C . GitHub mobile: The GitHub mobile app can also be used to receive 2FA codes, adding

convenience for users who prefer to manage everything from their mobile devices.

D . Security keys: Physical security keys (such as YubiKeys) can be used as a strong form of 2FA,

requiring physical access to the key to authenticate.

Security questions and Single sign-on (SSO) are not considered 2FA methods in the context of GitHub

account security.