GITHUB-FOUNDATIONS Practice Questions

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.

Reference:

Pro Git Book: What is Git?

Git Documentation: Distributed Version Control

GitHub Docs: Understanding the Git Workflow

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.

Saved replies in GitHub are a feature that allows users to create and save templates of commonly

used responses for issues and pull requests. This feature can significantly enhance productivity and

ensure consistent communication.

Saved Replies Are Tied to a User's Personal Account:

Option A is correct because saved replies are specific to a user's GitHub account, meaning they are

accessible to the user across all repositories they have access to.

Saved Replies Allow Reusable Responses:

Option C is correct because the primary purpose of saved replies is to allow users to create reusable

responses for issues and pull requests, saving time and ensuring consistency.

Incorrect Options:

Option B is incorrect because saved replies are not allocated at the enterprise level; they are specific

to individual user accounts.

Option D is incorrect because saved replies do not send auto notifications; they are manually

inserted by the user when responding to issues or pull requests.

Reference:

GitHub Docs: Using Saved Replies

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.

Reference:

GitHub Docs: GitHub Desktop Documentation

Cloning a repository in GitHub refers to creating a copy of the repository on your local machine. This

allows you to work on the project offline, make changes, and later push those changes back to the

remote repository. It does not involve creating a copy on GitHub.com (which would be forking),

retrieving updates (which would be pulling), or importing source code into a new repository (which is

done differently).

To locate an existing GitHub Action provided by a GitHub-approved vendor, you can use the following

methods:

Verification Badge:

Option C is correct because actions provided by GitHub-approved vendors will typically have a

verification badge. This badge indicates that the action is from a trusted source, giving users

confidence in its security and reliability.

Search the GitHub Marketplace:

Option F is correct because GitHub Marketplace is the official location to find and install actions,

including those provided by third-party vendors. You can search for actions by the vendor's name to

find the specific one you need.

Incorrect Options:

Option A is not necessary to locate an existing action; creating a workflow file is for implementing

the action, not locating it.

Option B is incorrect because searching the vendor’s website for a github.yaml index is not a

standard practice for finding actions.

Option D is incorrect because installing a GitHub App is unrelated to finding an existing action.

Option E is incorrect because adding a vendor as an allowed Actions Source is a configuration step for

using the action, not for locating it.

Reference:

GitHub Marketplace: Verified Actions

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

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

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.

Forking a gist is the most efficient way to create a public gist based on another user's gist while

maintaining the history of the original gist. When you fork a gist, you create a new gist in your own

account that retains a link to the original, allowing you to track changes and contribute back if

desired.

Forking a Gist:

Option A is correct because forking is a straightforward way to create your own copy of another

user's gist while preserving the history and making it easy to track updates.

Incorrect Options:

Option B is incorrect because creating a new gist and copying the content would not preserve the

history or link back to the original gist.

Option C is incorrect because cloning is typically associated with repositories, not gists, and is more

complex than forking for this purpose.

Option D is incorrect because requesting to be added to the existing gist is not a standard GitHub

feature.

Reference:

GitHub Docs: Forking Gists