Free Microsoft GH-900 Practice Test Questions MCQs

Explanation:
GitHub Discussions is a collaborative communication forum for a project. While it serves as a space for open conversation, ideas, and Q&A, its functionality is distinct from project planning tools like Issues. The platform allows for the seamless transition of ideas that mature in a conversation. Therefore, when a conversation in a Discussion post solidifies into a specific task, bug report, or feature request, the platform provides a direct pathway to convert that community feedback into a structured, trackable item on your project board or roadmap, without losing the context of the original conversation.

Correct Option:

C. Create an issue from the discussion
This is a key integration feature between GitHub Discussions and Issues. It allows maintainers and collaborators to take a conversation that has evolved into a defined task or bug report and promote it to a formal Issue. When you create an issue from a discussion, GitHub automatically links the two, preserving the conversation history and providing traceability. This helps in transitioning community feedback directly into the actionable workflow of a project, ensuring that valuable ideas are not lost in a long thread and can be properly tracked, assigned, and prioritized.

Incorrect Option:

A. Duplicate the discussion
GitHub Discussions does not have a native feature to create an exact copy or "duplicate" a discussion post. While users can reference or link to other discussions, the platform is designed to keep conversations as single, unique threads to avoid fragmentation and confusion. Duplicating a discussion would split the conversation and make it difficult for community members to follow the context and find answers. The collaborative workflow relies on centralized, singular threads for each topic.

Incorrect Option:

B. Archive the discussion
The ability to archive a discussion is an administrative or moderation action typically reserved for repository admins or maintainers, not a standard action for a general user. Archiving is used to lock a conversation that is outdated, resolved, or no longer relevant, preventing further comments. Since this action affects the entire community's ability to contribute to that thread, it is a privileged permission and not an option available to every user interacting with a discussion post.

Incorrect Option:

D. Add the discussion to README
The README file is the primary landing page documentation for a repository, controlled by specific files (like README.md) in the codebase. While you can certainly link to a discussion from the README by manually editing the Markdown file, there is no one-click user interface option within a discussion post to directly "add it to the README." This action would require editing the repository's documentation files, which is a distinct process from interacting with a discussion thread.

Reference:
GitHub Docs: Managing discussions for your community / Creating an issue from a discussion

Explanation:
GitHub Discussions provides a structured way to organize conversations within a repository. To help communities get started quickly, GitHub automatically creates a set of default categories when Discussions are first enabled. These default categories are designed to cover the most common types of conversations, such as general help, ideas, and community updates. While repository administrators can later customize these categories to fit their specific needs, there is a standard set that comes pre-configured and available for immediate use.

Correct Option:

C. Show and tell
Show and tell is one of the default categories automatically created when you enable GitHub Discussions. This category is specifically designed for members to share their projects, demos, or accomplishments related to the repository. It provides a space for community members to showcase what they have built, fostering engagement and inspiration within the community. As a default category, it comes pre-configured with a specific description and purpose, helping to organize conversations effectively from the start.

Incorrect Option:

A. Bug report
While bug reports are essential for software development, they are typically managed through GitHub Issues, not Discussions. The default Discussions categories focus on open-ended conversations, Q&A, and community sharing. Bug reports require structured tracking, assignment, and prioritization, which is better suited to the Issues workflow. Repository administrators could potentially create a custom category for bug discussions, but it is not one of the pre-configured default categories.

Incorrect Option:

B. Daily check-in
Daily check-ins are too specific and informal to be included as a default category in GitHub Discussions. The default categories are designed to be broadly applicable across different types of projects and communities. While some teams might use Discussions for daily stand-ups or progress updates, this is not a built-in default option. Such a category would need to be created manually by an administrator if the team wishes to use Discussions for this purpose.

Incorrect Option:

D. Security concern
Security concerns require careful handling, often involving private disclosure and coordinated response. GitHub provides specific tools for this, such as private vulnerability reporting and security advisories. Making "Security concern" a public default discussion category would be inappropriate as it could expose sensitive information. Security issues should follow responsible disclosure processes, not be posted in public discussions. Therefore, this is intentionally not a default category.

Reference:
GitHub Docs: Configuring Discussions / About Discussions / Default categories

Explanation:
A GitHub repository serves as the foundational element of any project on the platform. It is a cloud-based container that holds all project files and folders, along with each file's complete revision history. More than just storage, its purpose is to enable collaboration through features like version control, which allows multiple people to work on code simultaneously, track every change, and manage contributions from various team members in an organized and efficient manner.

Correct Option:

D. To provide a collaborative space where developers can share and manage code files, track changes, and store revision history
This option comprehensively defines a GitHub repository's purpose. It correctly identifies it as a space for collaboration, which is the core of GitHub's value. It also accurately lists the key functions enabled by Git: sharing and managing code, meticulously tracking changes over time, and preserving a complete revision history. This allows teams to work together efficiently, understand project evolution, and maintain a reliable record of all contributions and modifications.

Incorrect Option:

A. To provide a folder that stores project files, including documentation, on your local machine
This describes a standard folder on a personal computer, not a GitHub repository. While a local folder holds files, it lacks version control, collaboration features, and remote accessibility. A GitHub repository is hosted in the cloud, and its power comes from managing changes and teamwork, which a basic local folder cannot do.

Incorrect Option:

B. To provide a version control system designed for small projects, offering simple tools for organizing files on your laptop
This confuses Git with a GitHub repository. Git is the version control system that can be used locally. A GitHub repository is a remote, cloud-hosted space that stores a Git project. It is not limited to small projects or simple file organization; it scales for projects of all sizes and provides advanced collaboration tools beyond basic version control.

Incorrect Option:

C. To provide a cloud-based hosting service for project documentation, providing a secure and centralized location for file storage
This description is too narrow. While a repository can host documentation and files, its primary purpose is code hosting and development. Calling it a "file storage" service reduces it to something like Dropbox, ignoring its essential version control and collaboration functionality. The repository is designed for active development, not just passive file storage.

Reference:
GitHub Docs: Getting started with your GitHub account / Understanding the GitHub flow / Introduction to repositories

Explanation:
GitHub provides a set of default labels to help organize and prioritize issues and pull requests within a repository. These labels serve as visual indicators that convey specific information about the state or purpose of an item. One of these default labels is specifically designed to signal that a maintainer or project owner is seeking community assistance. It acts as a call to action for contributors, indicating that the issue or pull request is ready for someone to pick up and work on.

Correct Option:

C. Help wanted
The "help wanted" label is a standard default label available in every GitHub repository. When applied to an issue or pull request, it clearly communicates that the maintainers do not have the immediate capacity to address it themselves or that they are specifically looking for community contributions to resolve it. This label is often used by new contributors to find suitable tasks to start with, as it signals that help is both needed and welcome from the broader community.

Incorrect Option:

A. Enhancement
The "enhancement" label is a default label used to indicate that an issue or pull request is related to a new feature or an improvement to existing functionality. While it describes the nature of the work, it does not convey any information about whether the maintainers need assistance with it. An enhancement could be actively being worked on by a maintainer or waiting for community help, but the label itself only categorizes the type of change.

Incorrect Option:

B. Question
The "question" label is a default label typically used to indicate that an issue or discussion requires further clarification or answers. It is often applied to issues that are not bug reports or feature requests but rather inquiries from users. This label signals that the item needs a response or explanation, not that it represents a task where a maintainer needs implementation assistance from contributors.

Incorrect Option:

D. Documentation
The "documentation" label is a default label used to indicate that an issue or pull request relates to improvements, additions, or fixes to the project's documentation. Like "enhancement," it describes the topic of the work but does not indicate that the maintainer is specifically seeking help. Documentation tasks could be handled by maintainers or contributors, but the label alone does not signal a need for community assistance.

Reference:
GitHub Docs: Issues / Using labels and milestones to track work / About labels

Explanation:
Understanding the relationship between commits, branches, and pull requests is fundamental to GitHub collaboration. A pull request is not a separate entity where commits live; rather, it is a request to merge changes from one branch into another. The commits themselves exist on the branch. When you create a pull request, you are essentially saying, "Here is a branch with some commits; please review and merge these changes into the target branch."

Correct Option:

A. Commits are made on a branch that can have a linked pull request.
This option correctly describes the relationship between commits and pull requests. Developers make commits to a branch as they work on a feature or fix. Once the branch is ready for review, they open a pull request to propose merging that branch into another (like main). The pull request then displays all the commits on that branch, allowing reviewers to see the individual changes. The branch exists independently, and the pull request simply links to it for review and merging.

Incorrect Option:

B. Commits can only be made after a pull request is created.
This is incorrect and reverses the logical workflow. Commits are made during development, and a pull request is typically created after commits have been pushed to a branch. While you can push additional commits to a branch after opening a pull request, commits are certainly not limited to the period after pull request creation. Development happens on branches, with or without an open pull request.

Incorrect Option:

C. Commits can only be made before a pull request is created.
This is also incorrect. After opening a pull request, developers often need to make additional commits to address review feedback, fix bugs, or add tests. These new commits pushed to the same branch automatically appear in the existing pull request. This is a common and valuable part of the collaboration process, allowing iterative improvement based on reviewer comments.

Incorrect Option:

D. Commits are made on a pull request that can have a linked branch.
This option incorrectly suggests that commits are made directly on a pull request, with the branch being secondary. In reality, the branch is the primary container for commits, and the pull request is simply a request to merge that branch. The relationship is that a pull request is linked to a branch, not the other way around.

Reference:
GitHub Docs: Pull requests / Proposing changes to your work with pull requests / About pull requests

Explanation:
A gist is a simple and efficient way to share code snippets, notes, or any other text-based content using GitHub. Despite its simplicity, it is fundamentally powered by Git, which means every gist is automatically versioned and has a commit history. This allows users to track changes, revert to previous versions, and even clone gists locally. Gists can be either public (discoverable) or secret (private but shareable).

Correct Option:

B. Git repository
A gist is essentially a lightweight, simplified Git repository. It functions as a single file or a collection of files that are version-controlled using Git. Each time you edit a gist and save changes, a new commit is created, preserving the revision history. You can even clone a gist using standard Git commands, make changes locally, and push them back, just like with a regular repository. This Git-powered foundation distinguishes gists from simple pastebin services.

Incorrect Option:

A. GitHub app
A GitHub app is a tool that extends GitHub's functionality by integrating with repositories and acting on behalf of a user or organization. Examples include automation tools, CI/CD integrations, and project management bots. A gist has no relation to this; it is simply a content-sharing feature within GitHub, not an application that performs actions or requires installation.

C. Markdown document
While gists can certainly contain Markdown content and will render it nicely when viewed, a gist itself is not inherently a Markdown document. A gist can hold any type of text file, including code in various programming languages, plain text, configuration files, or Markdown. The format is determined by the file extension, but the underlying container remains a version-controlled Git repository.

D. GitHub Pages site
GitHub Pages is a static site hosting service that takes files from a repository and publishes them as a website. While you could technically use a gist to store files for a simple site, it is not designed for this purpose. Gists lack the configuration options, custom domain support, and build processes that GitHub Pages provides. A gist is simply a code snippet sharing tool, not a website hosting platform.

Reference:
GitHub Docs: Gists / Creating and managing gists / About gists

Explanation:
A gist is a simple and efficient way to share code snippets, notes, or any other text-based content using GitHub. Despite its simplicity, it is fundamentally powered by Git, which means every gist is automatically versioned and has a commit history. This allows users to track changes, revert to previous versions, and even clone gists locally. Gists can be either public (discoverable) or secret (private but shareable).

Correct Option:

B. Git repository
A gist is essentially a lightweight, simplified Git repository. It functions as a single file or a collection of files that are version-controlled using Git. Each time you edit a gist and save changes, a new commit is created, preserving the revision history. You can even clone a gist using standard Git commands, make changes locally, and push them back, just like with a regular repository. This Git-powered foundation distinguishes gists from simple pastebin services.

Incorrect Option:

A. GitHub app
A GitHub app is a tool that extends GitHub's functionality by integrating with repositories and acting on behalf of a user or organization. Examples include automation tools, CI/CD integrations, and project management bots. A gist has no relation to this; it is simply a content-sharing feature within GitHub, not an application that performs actions or requires installation.

C. Markdown document
While gists can certainly contain Markdown content and will render it nicely when viewed, a gist itself is not inherently a Markdown document. A gist can hold any type of text file, including code in various programming languages, plain text, configuration files, or Markdown. The format is determined by the file extension, but the underlying container remains a version-controlled Git repository.

D. GitHub Pages site
GitHub Pages is a static site hosting service that takes files from a repository and publishes them as a website. While you could technically use a gist to store files for a simple site, it is not designed for this purpose. Gists lack the configuration options, custom domain support, and build processes that GitHub Pages provides. A gist is simply a code snippet sharing tool, not a website hosting platform.

Reference:
GitHub Docs: Gists / Creating and managing gists / About gists

Explanation:
A GitHub user profile serves as a public identity page that showcases a user's activity and contributions on the platform. By default, certain basic information is displayed to anyone visiting the profile. This includes details that users intentionally set up to introduce themselves to the community. This information helps other users identify and learn about the person behind the contributions.

Correct Option:

A. Personal biography and profile picture
A user's biography (bio) and profile picture are the most fundamental pieces of information displayed by default on a GitHub profile. The bio is a short description users can write about themselves, and the profile picture is an image they upload. Both are publicly visible to anyone viewing the profile and are designed to help personalize the user's presence on GitHub. This information is set by the user in their profile settings.

Incorrect Option:

B. Public Secure Shell Protocol (SSH) keys
SSH keys are sensitive credentials used for secure authentication between a user's local machine and GitHub. While users can add multiple SSH keys to their account, these keys are never displayed publicly on their profile. Even if a user has added SSH keys, they remain private for security reasons. Only the user can view and manage their own SSH keys in their account settings.

Incorrect Option:

C. A list of the user's private repositories
Private repositories are intentionally hidden from public view. Only the user and explicitly invited collaborators can access these repositories. By default, private repositories do not appear anywhere on a user's public profile. Users have control over what information about their private repositories is visible, and the repositories themselves remain completely confidential unless the user chooses to make them public.

Incorrect Option:

D. Email address and password
A user's password is never displayed or stored in readable form anywhere on GitHub for security reasons. While users can choose to make their email address public, it is not displayed by default. GitHub offers privacy settings that allow users to keep their email address hidden and use a noreply email address for activity tracking instead. Passwords are never visible to anyone, including the user themselves.

Reference:
GitHub Docs: Account and profile / Managing your profile / Personalizing your profile

Explanation:
GitHub provides analytics and reporting tools to help repository administrators and contributors understand project activity and health. These visualizations are automatically generated from repository data such as pull requests, issues, contributions, and traffic. They are organized in a dedicated tab within the repository that offers various charts and graphs. This section provides valuable insights without requiring any additional configuration or third-party tools.

Correct Option:

C. Insights
The Insights tab is the correct location for viewing pre-built visualizations from repository data. This tab contains several sub-sections including Pulse (a project summary), Contributors (graphs of contribution activity), Community (community health metrics), Traffic (views and clones data), and Dependency Graph. These visualizations are automatically generated from repository activity and provide administrators with valuable analytics about how the repository is being used and developed.

Incorrect Option:

A. Settings
The Settings tab is where administrators configure repository options such as branch protection rules, collaborator permissions, webhooks, and other administrative features. While essential for repository management, it does not contain any data visualizations or analytics. Settings is for configuration, not for viewing activity metrics or pre-built charts about repository usage.

Incorrect Option:

B. Issues
The Issues tab displays the list of issues for the repository, including open and closed items. While issues are a source of data that feeds into the analytics, the Issues tab itself only shows the individual issues and their details. It does not provide aggregated visualizations or charts about issue trends, resolution times, or other metrics derived from issue data.

Incorrect Option:

D. Charts
There is no "Charts" tab available in a standard GitHub repository. While the Insights section contains various charts and graphs, GitHub does not have a dedicated top-level tab named "Charts." The visualizations are organized under the Insights tab with specific names like "Graphs" or are integrated into the various Insight sub-pages. This option is a distractor that sounds plausible but does not exist in the GitHub interface.

Reference:
GitHub Docs: Repositories / Viewing activity and data for your repository / About repository graphs