Tough GH-900 GitHub Foundations Sample Questions and Answers

An engineering team at scrumtuous.com is updating its Git guidelines to keep commit history readable in terminals and hosting tools. What character limit should they use for the subject line of each commit message to follow widely accepted conventions?

• ❏ A. 60 characters

• ❏ B. 72 characters

• ❏ C. 50 characters

• ❏ D. 90 characters

An engineer at mcnz.com is deciding whether to open a repository in GitHub.dev or launch a GitHub Codespace. They plan to compile and run the service and they also need terminal access for debugging and scripts. In which situation should they choose GitHub Codespaces instead of GitHub.dev?

• ❏ A. Choose GitHub.dev for heavy builds and use Codespaces only to browse files

• ❏ B. Use GitHub Codespaces when you must build and run the app and need a terminal for tools and tests

• ❏ C. Prefer GitHub.dev for testing and building code while reserving Codespaces for navigation tasks

• ❏ D. Use Google Cloud Shell Editor instead of either option for compiling and running the project

A new engineer at mcnz.com opens the Insights tab on a GitHub repository and wants to understand what it displays. What does Repository Insights provide?

• ❏ A. A consolidated security overview for the repository

• ❏ B. Secret scanning and code scanning alerts

• ❏ C. Analytics about the repository such as traffic trends code frequency and contributor activity

• ❏ D. Cloud Monitoring

Priya is an intern at a regional travel startup who has just begun using GitHub to manage code reviews and bug triage. She wants to understand how slash commands can speed up routine tasks inside issues and pull requests. What do GitHub slash commands enable her to do?

• ❏ A. Use keyboard shortcuts to move around pages and open panels throughout the GitHub interface

• ❏ B. Construct advanced search queries that filter and sort issues and repositories

• ❏ C. Use forward slash entries in comments to carry out actions like assign, close or label without navigating away

• ❏ D. Run code level build or test commands inside repositories to enhance code quality

The product team at Crestline Robotics is moving from GitHub Projects Classic to the new GitHub Projects to plan their roadmap. Which statement best reflects a key difference between the new Projects and Projects Classic?

• ❏ A. GitHub Projects Classic is the only version that supports code scanning and secret scanning, while the new GitHub Projects do not

• ❏ B. The new GitHub Projects limit you to tracking open issues and do not support including pull requests

• ❏ C. The new GitHub Projects offer a flexible table like interface with custom fields and two way synchronization with issues that were not present in Projects Classic

• ❏ D. GitHub Projects Classic is the only version that integrates with GitHub Actions workflows for project automation

Maya maintains an open source library on GitHub for Koru Labs and plans to keep separate README files in multiple supported locations. She wants the README that appears by default on the repository home page to be the one she prefers. In which repository location should she place that README so GitHub will select it ahead of the others?

• ❏ A. In the repository root directory

• ❏ B. In the .github directory

• ❏ C. Inside the .git directory

• ❏ D. In the docs directory

In the BrightForge Robotics GitHub organization, a few trusted members are assigned the Organization Moderator role to help keep discussions healthy. Beyond the capabilities of standard members, which actions can these moderators perform across the organization and its public repositories? (Choose 3)

• ❏ A. Hide comments in public repositories owned by the organization

• ❏ B. Approve and install GitHub Apps for the entire organization

• ❏ C. Configure interaction limits at the organization level and at the repository level

• ❏ D. Block and unblock non member contributors from the organization

An engineer at mcnz.com published a public gist using a GitHub Free account and later wants to hide it from public view. Can they change its visibility to secret after it has already been created?

• ❏ A. Yes, GitHub administrators can perform the change

• ❏ B. No, changing a public gist to secret requires a paid plan

• ❏ C. No, once a gist is public it cannot be turned into a secret gist

• ❏ D. Yes, but only the gist owner can make it secret

Samira is viewing a repository on GitHub with a non US keyboard and pressing the period key does not launch the web editor in github.dev. What can Samira do to open the repository in github.dev anyway?

• ❏ A. Open the repository in Cloud Shell Editor

• ❏ B. Use a private browsing window

• ❏ C. Manually replace github.com with github.dev in the address bar

• ❏ D. Update the browser to the latest version

At mcnz.com your team needs to search a GitHub repository to list every issue where a teammate is mentioned in the body or in a comment. Which search qualifier should you pair with the person’s username to filter for those mentions?

• ❏ A. Use the mentioned search qualifier followed by the username such as mentioned:alex

• ❏ B. Use the mentions search qualifier followed by the username such as mentions:alex

• ❏ C. Use the author search qualifier followed by the username such as author:alex

• ❏ D. Use the commenter search qualifier followed by the username such as commenter:alex

• ❏ E. Open the person’s profile and read their activity feed

You can find more of my GitHub practice exams on Udemy and certificationexams.pro.

A developer at Riverbend Labs wants to keep up with announcements and new public work from several nonprofits on GitHub. Which action should the developer take to consistently see their activity in the GitHub interface?

• ❏ A. Watch several of the organization’s repositories

• ❏ B. Subscribe to the organization’s newsletter on example.com

• ❏ C. Use the Follow feature on the organization’s GitHub profile

• ❏ D. Attend community meetups or conferences

ByteRidge Studio is setting up a new GitHub organization for its engineering group and is choosing plan tiers that apply to organization accounts. About 40 contributors will join within 90 days and leadership wants to shortlist the valid plan names for organizations. Which plan names are available for GitHub organization accounts? (Choose 3)

• ❏ A. GitHub Advanced Security

• ❏ B. Team

• ❏ C. Pro

• ❏ D. Free

• ❏ E. Enterprise

• ❏ F. Personal

A team at scrumtuous.com is automating repository tasks and wants to avoid storing a basic username and password in scripts. What is a key advantage of choosing a GitHub personal access token for this automation?

• ❏ A. It is a second factor that you enter after your password during sign in

• ❏ B. You can integrate GitHub Enterprise Server with your corporate directory and centrally manage repository access

• ❏ C. It lets scripts and tools authenticate to GitHub through the API or command line and you create it in settings with scopes that can be limited to a repository or an organization

• ❏ D. You can keep the account password in Google Cloud Secret Manager and reference it from your automation

At mcnz.com you are the release coordinator for a GitHub project that is approaching the maximum item capacity and you want to avoid any disruption to work. When issues or pull requests are closed as done or not planned you want them to leave the project automatically so the project stays under the cap. Which GitHub capability should you use to have these items archived without manual steps?

• ❏ A. Move the milestone of the affected issues and pull requests to a later iteration

• ❏ B. Apply project filters to show only open items while you continue working

• ❏ C. Set up the project’s built-in workflow to auto archive items that meet a completion or not planned state

• ❏ D. Google Cloud Functions

Maya from Alpine Labs wants to begin a new project and needs an empty repository under her GitHub account that is not a fork or a clone. What should she do?

• ❏ A. Run git checkout -b new_app in an existing local repository to make a new remote repository automatically

• ❏ B. Open the GitHub website then click the plus icon in the upper right and choose New repository and complete the form and create it

• ❏ C. Copy the URL of another repository and run git clone to create the project folder

• ❏ D. Use Google Cloud Source Repositories to host the project

Riverton Robotics wants engineers to keep receiving updates about specific issues and pull requests while minimizing noise from unrelated activity on GitHub. How should the team tailor subscriptions so notifications reflect only the activity they care about?

• ❏ A. Click the “Watch” button on a repository to follow everything that happens there

• ❏ B. Enable automatic watching for all public repositories you can access

• ❏ C. Choose the notification categories you want and unsubscribe from individual conversations or repositories you no longer wish to follow

• ❏ D. Google Cloud Pub/Sub

An engineer at scrumtuous.com is coaching a cohort on Git basics and asks them to identify the two high level status categories that Git uses to classify files in a repository. Which file states represent these overarching categories? (Choose 2)

• ❏ A. Modified

• ❏ B. Tracked

• ❏ C. Cloud Source Repositories

• ❏ D. Staged

• ❏ E. Untracked

Sofia uses a laptop keyboard layout that does not let her use the dot key shortcut to launch the web editor. How else can she open a GitHub repository in the github.dev editor?

• ❏ A. Use the Extensions view

• ❏ B. Open Cloud Shell Editor and clone the repository

• ❏ C. Change the browser URL from github.com to github.dev

• ❏ D. Press Alt plus Up Arrow

A product team at scrumtuous.com uses GitHub Enterprise Cloud and they want stronger security features along with compliance tooling and more control over releases. Which GitHub capability should they buy to gain these enhanced controls?

• ❏ A. GitHub Connect

• ❏ B. GitHub Advanced Security

• ❏ C. GitHub Packages

• ❏ D. GitHub Actions

Rivertown Robotics organizes work with GitHub Projects and wants a quick view that shows how many items each person is assigned right now. In Insights, which chart type should they create to get a point in time breakdown by assignee?

• ❏ A. historical chart

• ❏ B. current chart

• ❏ C. bar chart

• ❏ D. project chart

You can find more of my GitHub practice exams on Udemy and certificationexams.pro.

Your team at scrumtuous.com plans to merge work from the feature-auth branch into main by opening a pull request in GitHub. Which branch should be selected as the base branch and which should be chosen as the compare branch?

• ❏ A. develop is the base branch and feature-auth is the compare branch

• ❏ B. main is the base branch and feature-auth is the compare branch

• ❏ C. main is the base branch and main is the compare branch

• ❏ D. feature-auth is the base branch and main is the compare branch

At Brightwave Studios, Nia has completed a feature in her own branch within a collaborative GitHub repository. What should she do next to ensure the team integrates the work safely, and what does that workflow allow the group to do when her changes are combined into the default branch?

• ❏ A. Create a new independent repository for her feature so each teammate has a separate copy

• ❏ B. Force push the branch directly to the default branch to skip any review

• ❏ C. Open a pull request from her feature branch so teammates can review discuss and request changes before merging into the default branch

• ❏ D. Move the branch to Cloud Source Repositories to enable automatic merge without human approval

A product team at scrumtuous.com needs to integrate with GitHub and must choose between a GitHub App and an OAuth app. What is the key difference in how these two options grant access and permissions to repositories and organization data?

• ❏ A. Only verified organizations can publish GitHub Apps to GitHub Marketplace

• ❏ B. GitHub Apps provide fine grained permissions and can request only the scopes they need

• ❏ C. OAuth apps are required if you plan to charge for an app on GitHub Marketplace

• ❏ D. OAuth apps let you define repository level permissions that are more granular than GitHub Apps

A new engineering team at mcnz.com is learning how source control tools connect with collaboration services. What is the correct relationship between Git and GitHub?

• ❏ A. GitHub is a distributed version control system and Git is a hosted website that depends on GitHub

• ❏ B. On Google Cloud teams should replace both Git and GitHub with Cloud Source Repositories

• ❏ C. Git is a distributed version control system and GitHub is a service that hosts Git repositories and adds collaboration features

• ❏ D. Git is a cloud file storage tool and GitHub is the platform that powers Git

As a maintainer on several community repositories, Maya finds it hard to track alerts and tags across many projects. She needs to review only conversations where she was explicitly mentioned so she can respond before a minor release this afternoon. How can Maya quickly filter GitHub notifications so that only items generated by mentions are displayed?

• ❏ A. Create a custom filter in Dependabot to show items where she is tagged

• ❏ B. Apply the filter query reason:mention in her GitHub notifications inbox

• ❏ C. Rely on the default inbox view which only includes mention notifications

• ❏ D. Filter the notifications inbox using the query is:mention

An engineer at scrumtuous.com opens a new GitHub Codespace for a repository and wants to know which operating system the remote development container uses by default. Which operating system does the codespace run by default?

• ❏ A. Windows

• ❏ B. macOS

• ❏ C. Ubuntu Linux

• ❏ D. Debian

A nonprofit called Cedar Works maintains a personal GitHub account for a project lead and an organization account for the team, and after a 60 day pilot they want to standardize on plan names that exist for both account types so billing remains simple. Which GitHub pricing plans are available across both personal and organization accounts?

• ❏ A. Enterprise

• ❏ B. Pro

• ❏ C. Free

• ❏ D. Team

• ❏ E. Personal

Priya maintains a repository and frequently reviews pull requests and she wants a fast way to post a friendly approval message like Looks good to me and approved without retyping it every time. Which GitHub feature should she use to send the same acknowledgment efficiently?

• ❏ A. GitHub Actions

• ❏ B. GitHub Discussions

• ❏ C. GitHub Saved Replies

• ❏ D. Pull request templates

A small engineering team at scrumtuous.com is starting a new app on GitHub and needs a place to keep the project’s code along with all files and the history of every change. Which GitHub element should they choose?

• ❏ A. GitHub Codespaces

• ❏ B. GitHub Discussions

• ❏ C. A place to keep a project’s source code, supporting files, and the full history of changes

• ❏ D. GitHub Packages

A freelance developer wants to choose between GitHub Copilot Individual and GitHub Copilot Business for coding assistance across different repositories and account types. Which statement best explains how these two plans differ?

• ❏ A. GitHub Copilot Individual works only with public repositories while GitHub Copilot Business supports both public and private repositories in an organization

• ❏ B. GitHub Copilot Individual is complimentary while GitHub Copilot Business requires a paid subscription

• ❏ C. GitHub Copilot Individual is intended for personal accounts while GitHub Copilot Business is managed for organizations and enterprises

• ❏ D. GitHub Copilot Business uses a model trained solely on your company’s private code while GitHub Copilot Individual uses a model trained only on public code

You want your GitHub profile to automatically show a personal introduction at the top of your profile page. What should you set up so that GitHub renders a README on your profile without any extra manual steps?

• ❏ A. Enable GitHub Pages on any repository

• ❏ B. Create a public repository named exactly the same as your GitHub username and add a README.md in the root

• ❏ C. Rename a README file to your username in any repository

• ❏ D. Create a repository named profile and put a README in it

An engineering team at NimbusWorks wants to deploy GitHub Copilot for developers who use a mix of editors on Windows and macOS, so which group of IDEs is compatible with GitHub Copilot?

• ❏ A. Eclipse, NetBeans, and Sublime Text

• ❏ B. Visual Studio Code, Xcode, and Android Studio

• ❏ C. Visual Studio Code, Visual Studio, Vim, and JetBrains IDEs

• ❏ D. Google Cloud Shell Editor, Atom, and Notepad++

BlueFin Analytics has release coordinators who must handle routine repository management like triaging issues, applying labels and milestones, and guiding pull request workflows, yet they must not be able to delete the repository or administer security and team access. Which GitHub permission level should they receive?

• ❏ A. Triage

• ❏ B. Write

• ❏ C. Maintain

• ❏ D. Read

When you search within pull requests on GitHub, what results will appear if you include the qualifier “review-requested:USERNAME”?

• ❏ A. Pull requests that were opened by that user

• ❏ B. Pull requests where that user has been invited to review

• ❏ C. Pull requests where that user has submitted a review or an approval

• ❏ D. Pull requests assigned to that user

Maya at Cedar Apps manages a private repository in her personal GitHub account and wants to grant a new contractor access so they can push commits and open pull requests. What is the correct way for Maya to invite the person to the repository?

• ❏ A. Send an email invite from her work email address

• ❏ B. Share the repository URL with the person so they can clone it

• ❏ C. Open the repository settings in GitHub and add the person as a collaborator to send an invitation

• ❏ D. Add the developer to a GitHub organization team that has access to the repository

The correct option is 50 characters which is the widely accepted limit for the subject line in a Git commit message.

This limit keeps the one line subject concise so it fits cleanly in terminals and in the compact views of hosting tools. It prevents unwanted wrapping or truncation and leaves space for automatic prefixes that some workflows add.

Detailed context belongs in the body which is typically wrapped at a longer width. Keeping the short summary separate improves scanability in logs and pull request lists.

60 characters exceeds the conventional subject limit and is more likely to wrap or be cut off in common views.

72 characters is the common wrapping width for the commit message body rather than the subject so using it for the subject would be against the usual convention.

90 characters is far too long for a subject line in typical tools and is likely to be truncated or wrapped in narrow displays.

Remember the pairing by linking the subject to the shorter limit and the body to the longer wrap. If two lengths appear think small for the subject and longer for the body.

The correct option is Use GitHub Codespaces when you must build and run the app and need a terminal for tools and tests.

Codespaces provides a full development environment in the cloud with a container, compute resources, and an integrated terminal. You can build and run the application, run tests and scripts, and use debugging tools. This matches the need to compile and run the service and to have terminal access for debugging and scripts.

GitHub.dev is a lightweight browser editor that is ideal for quick edits and code browsing. It does not provide a runtime or an integrated terminal, so you cannot compile, run, or debug the application there. That is why Codespaces is the appropriate choice for this scenario.

Choose GitHub.dev for heavy builds and use Codespaces only to browse files is incorrect because GitHub.dev is not suited for heavy builds or running code, while Codespaces is designed for those tasks rather than being limited to browsing.

Prefer GitHub.dev for testing and building code while reserving Codespaces for navigation tasks is incorrect because testing and building require a runtime and terminal which GitHub.dev does not provide, and Codespaces is the environment intended for building, testing, and debugging.

Use Google Cloud Shell Editor instead of either option for compiling and running the project is incorrect in this context because the decision is between GitHub.dev and GitHub Codespaces, and the GitHub platform solution that meets the requirements is Codespaces.

Scan the scenario for words like compile, run, debug, or terminal. These signal a need for Codespaces while quick edits or browsing point to github.dev.

The correct option is Analytics about the repository such as traffic trends code frequency and contributor activity.

The Insights tab focuses on repository analytics. It shows traffic data such as views and clones along with top content and referrers. It also provides graphs for code frequency that display additions and deletions over time. You can review contributor and commit activity to understand who is contributing and when work is happening. These graphs collectively match the description of analytics about traffic trends code frequency and contributor activity.

A consolidated security overview for the repository is not what the Insights tab provides. Security overview lives under the Security area and is designed to summarize security posture rather than show activity graphs and repository analytics.

Secret scanning and code scanning alerts belong to the Security tab. These alerts are part of GitHub Code Security features and they are not presented as Insights analytics about traffic or contributor activity.

Cloud Monitoring is a Google Cloud service and is unrelated to GitHub repository Insights. It does not describe what the Insights tab in a GitHub repository shows.

Map keywords to the correct GitHub tab. Insights emphasizes activity graphs and repository analytics while Security contains secret scanning and code scanning alerts. Eliminate options that clearly belong to other products or platforms.

The correct option is Use forward slash entries in comments to carry out actions like assign, close or label without navigating away.

This feature lets you trigger repository actions from within an issue or pull request comment so you do not need to open panels or leave the discussion. You can type commands such as /assign @username, /close, /reopen, and /label bug and the platform applies the change when you post the comment. This speeds triage and review while keeping you focused on the conversation and it requires the appropriate permissions.

Use keyboard shortcuts to move around pages and open panels throughout the GitHub interface is about navigation and not about performing actions from a comment.

Construct advanced search queries that filter and sort issues and repositories refers to search syntax in the search bar and not to commands entered in comments.

Run code level build or test commands inside repositories to enhance code quality describes automated workflows and continuous integration rather than comment based commands in issues or pull requests.

Look for clues that mention typing a forward slash in a comment to perform repository actions. Eliminate options that focus on navigation, search, or build execution since those are different features.

The correct option is The new GitHub Projects offer a flexible table like interface with custom fields and two way synchronization with issues that were not present in Projects Classic.

This is correct because the new GitHub Projects provide a spreadsheet style table where you can define custom fields for your items and create multiple views with filters and sorting. Items in the new GitHub Projects are issues and pull requests that stay synchronized in both directions so updates in the project appear on the issue and updates on the issue appear in the project. Projects Classic used column based boards and did not offer arbitrary custom fields or the same depth of synchronization. Projects Classic is now considered legacy and the modern experience is the new GitHub Projects which means Classic features are less likely to be emphasized on newer exams.

GitHub Projects Classic is the only version that supports code scanning and secret scanning, while the new GitHub Projects do not is incorrect because code scanning and secret scanning are repository and organization security features that are independent of Projects and they are not limited by which project planning tool you use.

The new GitHub Projects limit you to tracking open issues and do not support including pull requests is incorrect because the new GitHub Projects support adding both issues and pull requests as items and they also support draft items.

GitHub Projects Classic is the only version that integrates with GitHub Actions workflows for project automation is incorrect because the new GitHub Projects have first class automation support and can integrate with GitHub Actions and APIs to update items and fields based on events.

Look for keywords that signal the modern offering such as custom fields, table or spreadsheet views, and two way sync with issues and pull requests. Beware of statements that mix unrelated security features with planning tools since those are usually distractors.

The correct option is In the .github directory. Placing the preferred README there ensures GitHub selects it ahead of other supported locations when rendering the repository home page.

GitHub recognizes multiple supported locations for a README and it will choose the one in that special directory when more than one README is present. Putting the preferred README there gives maintainers explicit control over which README appears by default.

In the repository root directory is not correct because although GitHub can display a README from the root, it will not be selected ahead of the preferred location when multiple README files exist.

Inside the .git directory is incorrect because that directory is internal to Git and is not rendered by GitHub, so a README placed there will not appear on the repository home page.

In the docs directory is not correct because while GitHub can use a README from a docs folder, it is not chosen ahead of the preferred location when more than one README is present.

When choices list several valid file locations, focus on which location the platform prioritizes by default. Look for wording about selection order or which placement gives you control over what is shown.

The correct options are Hide comments in public repositories owned by the organization, Configure interaction limits at the organization level and at the repository level, and Block and unblock non member contributors from the organization.

Organization moderators can hide comments on issues, pull requests, and discussions across repositories the organization owns, including public repositories. This allows them to remove disruptive or off topic content from view while preserving context for future review.

Moderators can also configure interaction limits for the entire organization and for individual repositories. This lets them temporarily restrict activity from certain users or from recently created accounts to slow down spam or harassment.

Finally, moderators can block and unblock non member contributors from the organization. This prevents abusive or disruptive users who are not members from interacting with any organization owned repositories and it can be reversed when appropriate.

The option Approve and install GitHub Apps for the entire organization is incorrect because only organization owners can approve and install Apps for the organization. Moderators focus on community health rather than administrative app management.

Match the action to the role focus. If the verbs relate to moderation such as hide, limit, or block then think moderator. If the action affects integrations, billing, or organization wide configuration then it usually belongs to owners.

The correct option is No, once a gist is public it cannot be turned into a secret gist.

GitHub sets gist visibility when you create it and a public gist cannot be converted back to secret later. If you want to hide the content you must delete the public gist and recreate it as a secret gist. This rule applies to all account types and it is a platform limitation rather than a permission issue.

Yes, GitHub administrators can perform the change is incorrect because neither GitHub staff nor organization administrators can change the visibility of an existing public gist. Visibility is fixed once the gist is published.

No, changing a public gist to secret requires a paid plan is incorrect because paid plans do not change this behavior. The limitation is the same on GitHub Free and on paid plans.

Yes, but only the gist owner can make it secret is incorrect because even the owner cannot change a public gist to secret after creation.

When options differ between a platform rule and a plan based permission, watch for absolute words like cannot or never that signal a hard product limitation that applies across all plans.

The correct option is Manually replace github.com with github.dev in the address bar.

If the period key does not work on a non US keyboard, you can still open the GitHub web editor by changing the domain in the URL from github.com to github.dev. This directly loads the repository in the lightweight editor and avoids any dependence on a specific keyboard layout or shortcut.

Open the repository in Cloud Shell Editor is not related to GitHub and would open a different editor in Google Cloud rather than the GitHub web editor, so it would not accomplish the goal.

Use a private browsing window does not affect how the GitHub web editor is launched and it does not resolve keyboard mapping issues, so it would not open the editor in the described scenario.

Update the browser to the latest version is unnecessary for this situation because the web editor can be opened by URL and the problem described is with a keyboard shortcut rather than browser compatibility.

If a keyboard shortcut fails on the exam, think of alternate entry paths such as changing the URL, using the command palette, or clicking a visible button in the interface.

The correct option is Use the mentions search qualifier followed by the username such as mentions:alex.

This qualifier returns issues and pull requests that include a reference to the specified user in the title, the body, or any comment. When you run it within a repository it lists every issue in that repository where the teammate is referenced.

Use the mentioned search qualifier followed by the username such as mentioned:alex is incorrect because that keyword does not exist in GitHub search and the valid form uses the plural word.

Use the author search qualifier followed by the username such as author:alex is incorrect because it filters for items created by that user rather than items that include a reference to them.

Use the commenter search qualifier followed by the username such as commenter:alex is incorrect because it finds items where the user commented which does not include issues where others referenced them without their own comment.

Open the person’s profile and read their activity feed is incorrect because it is not a search qualifier and it is not a reliable or scoped way to list repository issues that reference a user.

When options look similar, focus on the exact qualifier name in the docs and match it to the question wording. If the task is about being mentioned then choose the qualifier that targets mentions rather than who authored or who commented.

You can find more of my GitHub practice exams on Udemy and certificationexams.pro.

The correct option is Use the Follow feature on the organization’s GitHub profile.

Using Follow adds an organization’s public activity to your personal feed on GitHub so you consistently see announcements and new repositories and releases from them in the interface. Your feed aggregates activity from all the organizations you follow which makes Follow the right choice when you want broad visibility across several nonprofits rather than only a few specific projects.

Watch several of the organization’s repositories limits you to updates from only the repositories you choose and it does not show activity that happens elsewhere in the organization or new repositories that are created.

Subscribe to the organization’s newsletter on example.com might provide updates outside GitHub but it will not surface activity inside the GitHub interface or your feed.

Attend community meetups or conferences can help you learn and connect with others but it does not provide a consistent in product activity feed on GitHub.

When a question asks for visibility across all of an organization’s public work in the GitHub interface, prefer Follow for organization wide activity and use Watch when you only need updates from specific repositories.

The correct options are Team, Free, and Enterprise.

Team is a paid plan designed for organization accounts and it adds collaboration and management features that groups need. It supports multiple maintainers and teams and it provides enhanced permissions and policy controls that are appropriate for a growing engineering organization.

Free is available for organizations and it provides the core features for repositories and collaborators. It suits small groups or those starting out and it allows an organization to get set up without immediate cost.

Enterprise is the top plan for organizations that need advanced security and compliance and centralized management. It supports enterprise account structures and it enables features for governance and support that larger companies require.

GitHub Advanced Security is not a plan. It is a set of security features offered as an add on to eligible plans and it requires specific licensing. Therefore it is not a selectable plan tier for an organization account.

Pro is a plan for individual users and it is not available as an organization plan. If a team needs organizational controls they must use Team or Enterprise rather than Pro.

Personal is not a GitHub plan name. It refers to the type of account for an individual and it is not a plan that an organization can choose.

Map plan names to the account type. Organizations choose from Free, Team, and Enterprise while Pro and terms like Personal indicate individual accounts and features like GitHub Advanced Security are add ons rather than plans.

The correct option is It lets scripts and tools authenticate to GitHub through the API or command line and you create it in settings with scopes that can be limited to a repository or an organization.

A personal access token supports noninteractive authentication for automation through the GitHub API and through Git over HTTPS. You create it in your account settings and can assign fine grained scopes so it only has the minimum access needed for a specific repository or an organization. This reduces risk compared to storing a basic password and it aligns with GitHub requirements because passwords are not accepted for API or Git operations.

It is a second factor that you enter after your password during sign in describes two factor authentication which is interactive and meant for human sign in. It is not a credential type that scripts can present automatically.

You can integrate GitHub Enterprise Server with your corporate directory and centrally manage repository access is about enterprise identity integration and access governance. That setup does not provide a secret for automation and it does not answer how scripts should authenticate to GitHub.

You can keep the account password in Google Cloud Secret Manager and reference it from your automation still relies on a basic password which GitHub does not accept for API or Git over HTTPS. A secret manager is useful for storage but the correct credential for automation should be a personal access token.

When a scenario mentions automation or scripts favor noninteractive credentials like tokens and look for clues such as scopes and limited access. Avoid answers that describe interactive sign in or general enterprise identity integration.

The correct choice is Set up the project’s built-in workflow to auto archive items that meet a completion or not planned state.

GitHub Projects provides a native automation through the built-in workflow that can auto archive items when they are completed or marked not planned. Archiving removes items from the project while keeping their issue or pull request history intact so it lowers the active item count and helps you stay under the project capacity. Because the built-in workflow runs automatically once configured there are no manual steps and it prevents disruption as the project grows.

Move the milestone of the affected issues and pull requests to a later iteration is incorrect because milestones schedule work and they do not control project automation or archiving. Changing a milestone would not remove items from the project and it would not help with item capacity.

Apply project filters to show only open items while you continue working is incorrect because filters only change the view. They do not archive or remove items so closed items would still count toward the project limit.

Google Cloud Functions is incorrect because it is an external service that would require custom integration and it is not a GitHub capability for projects.

When a question asks for automatic cleanup of completed work in GitHub Projects look for a native option like built-in workflows or auto archive rather than filters or external services.

The correct option is Open the GitHub website then click the plus icon in the upper right and choose New repository and complete the form and create it.

This creates a brand new empty GitHub repository that is owned by her account and is neither a fork nor a clone. She can choose the repository name and visibility and optionally initialize with a README or keep it empty. GitHub will then provide the remote URL that she can use to connect a local project or she can push an existing local repository to it.

Run git checkout -b new_app in an existing local repository to make a new remote repository automatically is incorrect because this command only creates a new local branch. It does not create a new repository on GitHub and it does not set up a remote.

Copy the URL of another repository and run git clone to create the project folder is incorrect because cloning copies an existing repository and sets the origin to that source. It does not create a new empty repository under her account and it is not independent of the original.

Use Google Cloud Source Repositories to host the project is incorrect because the question requires a repository under her GitHub account and this is a different hosting service. This service has been retired by Google and is less likely to appear on newer exams.

When a question asks for an empty repository under a specific GitHub account, prefer actions in the GitHub UI or API that create a repository and avoid commands that only make local branches or perform a clone.

The correct option is Choose the notification categories you want and unsubscribe from individual conversations or repositories you no longer wish to follow.

This option aligns with how GitHub notifications are designed to be customized. You can select specific categories such as issues, pull requests, discussions, releases, and security alerts, and you can fine tune delivery preferences so you only receive messages that matter. You can also unsubscribe from a single thread or stop watching a repository when it becomes noisy. This approach gives engineers precise control so they continue to get updates for the work they care about while unrelated activity is filtered out.

Click the “Watch” button on a repository to follow everything that happens there is too broad for minimizing noise because it subscribes you to all activity in that repository which will include many events unrelated to your interests.

Enable automatic watching for all public repositories you can access would dramatically increase noise since it auto subscribes you to a large number of repositories and does not target the specific issues or pull requests you want to follow.

Google Cloud Pub/Sub is not a GitHub notification control and it cannot manage your watch or unsubscribe settings for GitHub issues and pull requests.

When a question asks you to minimize noise, favor options that mention unsubscribe, customize, or following specific conversations rather than broad watching of entire repositories.

The correct options are Tracked and Untracked.

Tracked files are those that Git already knows about through the last commit or the index. Git records their state and can include them in commits and status reports. Untracked files are new to the working directory and are not yet in the index or any commit, so Git ignores them until you add them.

When you run git add, a file moves from Untracked to Tracked. These two categories are the overarching statuses that organize all other file states.

Modified is not a high level category because it describes a specific condition of a file within Tracked. It refers to a file that has changes in the working directory relative to the index or the last commit.

Staged is also not a high level category because it reflects that a file is in the index and ready to be committed within Tracked. It is one step in the lifecycle of a file that Git already knows about.

Cloud Source Repositories is a hosted service for Git repositories rather than a Git file status category. It has been retired by Google which makes it even less likely to appear as a correct answer on newer exams.

Identify the two high level categories by asking whether Git already knows about the file or not. Then eliminate detailed lifecycle states that describe specific steps of change or preparation.

The correct option is Change the browser URL from github.com to github.dev.

This method opens the repository directly in the web-based editor in the browser and it works from repository, file, commit, and pull request views. It does not require installing anything and it avoids the need for a keyboard shortcut when the period key is not available.

Use the Extensions view is incorrect because this view manages extensions inside an editor session and it does not launch the browser editor from a repository page.

Open Cloud Shell Editor and clone the repository is incorrect because that is a different cloud editor from another service and it requires cloning into a separate environment rather than opening the GitHub web editor for the current repository.

Press Alt plus Up Arrow is incorrect because this is not a GitHub action to open the browser editor and it is typically a navigation shortcut inside editors instead.

When a shortcut is unavailable, look for a simple URL change or menu path that performs the same action. Domain swaps are common clues for opening web editors quickly.

The correct option is GitHub Advanced Security. It provides the stronger security features, compliance tooling, and controls that help teams govern what gets merged and released.

This capability delivers code scanning with CodeQL and other analyzers, secret scanning with push protection, dependency review, and an organization wide security overview. These features enable policy enforcement that can block pull requests when issues are found and provide reporting that supports compliance needs, which together give teams more control over their release process.

GitHub Connect links GitHub Enterprise Server with GitHub Enterprise Cloud to share features and data, yet it is not a suite of security and compliance controls and it does not add release gating.

GitHub Packages is a package registry for publishing and consuming packages and it does not provide code or secret scanning, compliance reporting, or controls over releases.

GitHub Actions is workflow automation for CI and CD and while checks can be orchestrated with it, it is not the purchased security capability that offers the comprehensive scanning, compliance tooling, and governance the scenario requires.

Match the scenario keywords to product capabilities. When you see needs like code scanning, secret scanning, dependency review, and compliance reporting on Enterprise Cloud, map them to GitHub Advanced Security and rule out options that describe integration, CI, or package registries.

The correct option is current chart.

In GitHub Projects Insights this choice provides a snapshot of your project at a single moment. You can group by Assignee and count items to see how many tasks each person has right now.

historical chart is focused on trends across time and is meant for showing how counts change rather than a point in time snapshot, so it does not satisfy the need for a current breakdown by assignee.

bar chart is a visual style that can be used with different underlying time bases and does not by itself determine whether the view is current or historical, so it does not ensure a point in time breakdown.

project chart is not a specific Insights chart type in GitHub Projects, so it does not match the requirement.

Look for time cues in the question. If you see right now or snapshot choose a current option. If you see trend or over time choose a historical option.

You can find more of my GitHub practice exams on Udemy and certificationexams.pro.

The correct option is main is the base branch and feature-auth is the compare branch.

In GitHub a pull request targets a base branch that will receive the changes and compares a source branch that contains the commits. You want to merge work from feature-auth into main so main must be the base and feature-auth must be the compare.

develop is the base branch and feature-auth is the compare branch is wrong because the scenario specifies merging into main and the base must be the destination branch not develop.

main is the base branch and main is the compare branch is wrong because comparing a branch to itself produces no changes and it ignores the feature-auth branch stated in the scenario.

feature-auth is the base branch and main is the compare branch is wrong because it reverses the direction of the merge since the base should be the target and the compare should be the source.

Translate the phrase merge X into Y into pull request fields by choosing Y as the base and X as the compare and verify the diff shows the expected commits.

The correct option is Open a pull request from her feature branch so teammates can review discuss and request changes before merging into the default branch.

This workflow creates a focused place for discussion and code review and it enables required approvals and automated checks to run before any merge. It keeps an auditable record of what was proposed and why and it lets the team choose how to merge so they can squash or rebase or create a merge commit. When the changes are combined into the default branch the team benefits from verified status checks and documented approvals which reduces risk and preserves a clear history.

Create a new independent repository for her feature so each teammate has a separate copy is wrong because splitting work into separate repositories fragments history and makes collaboration and review harder. A feature branch in the same repository is the standard collaborative approach.

Force push the branch directly to the default branch to skip any review is unsafe because it bypasses review and automated checks and can rewrite history. Many teams protect the default branch to prevent this.

Move the branch to Cloud Source Repositories to enable automatic merge without human approval is incorrect because it is not a GitHub workflow and automatic merging without human approval is not a safe practice. Cloud Source Repositories has been shut down which makes this option even less plausible on current exams.

Look for keywords like review, approval, and default branch which usually point to a pull request workflow rather than pushing directly or creating a new repository.

The correct option is GitHub Apps provide fine grained permissions and can request only the scopes they need.

GitHub Apps are installed on specific organizations or users and on selected repositories. During installation you can choose exactly which repositories the app may access and you can grant read or write permissions for distinct resource types such as issues or pull requests. The app then uses short lived installation tokens that include only the granted repositories and permissions, which enforces least privilege.

By contrast, OAuth apps act on behalf of a user and receive a user token that carries broad scopes which map to high level capabilities. The token inherits the user’s repository access within those scopes and the app cannot independently request narrowly tailored permissions for individual resource types. This is why the GitHub App model is more fine grained for repository and organization data.

Only verified organizations can publish GitHub Apps to GitHub Marketplace is incorrect because verification status is not the distinguishing factor for how access and permissions are granted. Verification is a marketplace trust attribute and does not define the permission model.

OAuth apps are required if you plan to charge for an app on GitHub Marketplace is incorrect because pricing and billing are not what separates the access models. Charging is independent of whether you use a GitHub App or an OAuth app and does not determine the permission granularity.

OAuth apps let you define repository level permissions that are more granular than GitHub Apps is incorrect because OAuth relies on broad user scopes and inherited access, while GitHub Apps offer the more granular per permission and per repository model.

When comparing GitHub App and OAuth app choices, focus on who the token represents. If the app acts as itself with installation tokens and per repository permissions then it is a GitHub App. If it acts as a user with broad scopes then it is an OAuth app.

The correct option is Git is a distributed version control system and GitHub is a service that hosts Git repositories and adds collaboration features.

Git is a standalone distributed version control system that developers use locally and on servers that they manage. GitHub is a hosted platform that stores Git repositories and provides collaboration features such as pull requests, issues, code review, and access controls. Teams can use Git without GitHub and they can also use other hosting providers because Git is an open tool.

GitHub is a distributed version control system and Git is a hosted website that depends on GitHub is incorrect because GitHub is not a version control system and Git is not a website. Git is the tool and GitHub builds on Git rather than the other way around.

On Google Cloud teams should replace both Git and GitHub with Cloud Source Repositories is incorrect because Git is a version control tool and cannot be replaced by a hosting product. Cloud Source Repositories hosted Git repositories and did not replace Git or the collaboration features of GitHub. Google Cloud has retired Cloud Source Repositories which makes this option even less likely on newer exams.

Git is a cloud file storage tool and GitHub is the platform that powers Git is incorrect because Git is not cloud storage and GitHub does not power Git. Git existed independently before GitHub and continues to function without it.

When a question pairs a technology with a platform first identify the tool and the hosting service. If the tool can operate without the platform then the platform is hosting and collaboration rather than a replacement.

The correct option is Apply the filter query reason:mention in her GitHub notifications inbox.

GitHub notifications support query qualifiers that let you narrow the inbox by the reason each notification was generated. Using reason:mention shows only items created because someone explicitly mentioned her username, which is exactly what she needs to review before the release.

Create a custom filter in Dependabot to show items where she is tagged is incorrect because Dependabot focuses on dependency updates and alerts rather than the general notifications inbox, so it will not filter conversations based on mentions across repositories.

Rely on the default inbox view which only includes mention notifications is wrong because the default view includes many reasons such as assignments, reviews, team mentions and repository activity, and it does not restrict the list to mentions.

Filter the notifications inbox using the query is:mention is incorrect because is:mention is not a supported notifications qualifier and the correct family for this need is the reason qualifiers.

When a question asks for filtering by why a notification was generated, look for the reason qualifiers such as reason:mention rather than issue search style qualifiers.

The correct option is Ubuntu Linux.

GitHub Codespaces runs a development container on a GitHub hosted Linux virtual machine by default. The default image that GitHub provides is the Dev Containers universal image which is built on Ubuntu. This means a new codespace starts with an Ubuntu based container unless the repository configures a different image in a devcontainer.json file.

Windows is not the operating system for the container in GitHub Codespaces. A codespace does not run Windows as the container operating system on GitHub hosted infrastructure.

macOS is not offered as a container operating system in GitHub Codespaces. You cannot run a macOS container in this environment.

Debian is not the default even though it is related to Ubuntu. You can choose a Debian based image by configuring a devcontainer.json file but that is not the default.

When a question asks about the Codespaces operating system, think of the container that runs in the cloud and not your local machine. If no image is specified in devcontainer.json, expect the default to be Linux.

The correct option is Free.

Free is available for both personal accounts and organization accounts, which lets the nonprofit use the same plan name across both account types and keep billing straightforward.

Enterprise is an organization level offering and is not available to personal accounts, so it cannot satisfy the requirement to standardize across both account types.

Pro is only for personal accounts and does not exist for organizations, so it does not meet the goal.

Team is only for organization accounts and is not available for personal accounts, so it cannot be used across both account types.

Personal is not a current GitHub pricing plan and refers to an account type rather than a product plan, so it is not applicable. Older references that use similar wording are not part of the current product lineup.

When a question asks for a plan that works for both account types, confirm whether it is offered to individuals and organizations and quickly eliminate options that are exclusive to one side such as Pro or Team.

The correct option is GitHub Saved Replies because it lets Priya quickly insert a preset approval message into pull request reviews without retyping it each time.

This feature allows her to create reusable snippets for comments on issues and pull requests and she can insert them from the comment toolbar or with a keyboard shortcut. It is the most efficient built in way to post friendly acknowledgments consistently during code reviews.

GitHub Actions is designed for automated workflows and continuous integration and delivery and while an action could be scripted to post comments it is not the simple reviewer experience for pasting the same manual approval message during a review.

GitHub Discussions provides forum style conversations for a project community and it is not used for adding review comments on pull requests.

Pull request templates prefill the description when a new pull request is opened and they do not help a reviewer reuse stock comments in review threads.

When the question describes reusing the same review comment text, map it to saved replies and verify the context is a review or comment box rather than a template or an automation workflow.

The correct option is A place to keep a project’s source code, supporting files, and the full history of changes. This describes a GitHub repository which stores code and related files and preserves the complete commit history for collaboration and tracking.

A repository is the core unit of version control on GitHub. It records every commit and supports collaborative workflows so it is exactly what a team needs when starting a new app and wanting to keep all code and its change history in one place.

GitHub Codespaces is a cloud developer environment for writing and running code, yet it is not the system that stores a project’s files and version history.

GitHub Discussions is for community conversations and Q and A and it is not where source code and its history are kept.

GitHub Packages is a package registry for publishing and consuming packages and it does not serve as the repository that tracks code and changes.

Match the need to the capability. If the question emphasizes storing code with its full history then think of a repository rather than tools for editing, chatting, or distributing artifacts.

The correct option is GitHub Copilot Individual is intended for personal accounts while GitHub Copilot Business is managed for organizations and enterprises.

Copilot Individual is a personal subscription that attaches to a single GitHub user and is billed to that person. Copilot Business is administered by an organization or enterprise so it provides centralized seat assignment, policy controls, single sign on integration, and audit capabilities. Both plans deliver AI coding assistance in supported IDEs for code in public and private repositories when the user has access.

GitHub Copilot Individual works only with public repositories while GitHub Copilot Business supports both public and private repositories in an organization is incorrect. Both plans work with code from public and private repositories as long as the user has permission to access the code.

GitHub Copilot Individual is complimentary while GitHub Copilot Business requires a paid subscription is incorrect. Individual is a paid personal subscription for most users and Business is also a paid subscription that is billed and managed by an organization.

GitHub Copilot Business uses a model trained solely on your company’s private code while GitHub Copilot Individual uses a model trained only on public code is incorrect. Copilot Business does not create a model trained solely on your private code and GitHub states that prompts and suggestions from Business and Enterprise are not used to train the models. The underlying models are not per customer private code models.

When plans are compared, look for differences in who manages billing and policy rather than differences in raw coding capability. Repository visibility and IDE support are often the same while administration and compliance features differ.

You can find more of my GitHub practice exams on Udemy and certificationexams.pro.

The correct option is Create a public repository named exactly the same as your GitHub username and add a README.md in the root.

GitHub recognizes a public repository whose name exactly matches your username and automatically renders its root README at the top of your profile. The repository must be public and the README.md must be in the root of the default branch. After you push the file, the content appears on your profile without any further configuration.

The option Enable GitHub Pages on any repository is incorrect because Pages publishes a static site from a branch or folder and it does not control the profile header. Enabling it does not create or display a profile README.

The option Rename a README file to your username in any repository is incorrect because the feature depends on the repository name rather than the file name. Changing a filename alone will not make GitHub show it on your profile.

The option Create a repository named profile and put a README in it is incorrect because the repository must be named exactly your username. A repository named profile will be treated like any other repository and will not drive the profile README.

Look for naming conventions that trigger automatic behavior. The profile README appears only when the repository name exactly matches your username and the repository is public with the README in the root.

The correct option is Visual Studio Code, Visual Studio, Vim, and JetBrains IDEs.

This group matches the officially supported environments for GitHub Copilot and it works across Windows and macOS. GitHub provides first party extensions for Microsoft editors and JetBrains IDEs, and there is an official plugin for Vim that enables the same functionality. Together these cover the major cross platform IDEs and editors that developers commonly use.

Eclipse, NetBeans, and Sublime Text is incorrect because there are no official GitHub Copilot integrations for these editors, so this set does not meet the compatibility requirement.

Visual Studio Code, Xcode, and Android Studio is incorrect because the set contains an editor that is not supported by GitHub Copilot, which means the whole group does not satisfy the requirement even though some items are compatible.

Google Cloud Shell Editor, Atom, and Notepad++ is incorrect because these editors do not have official Copilot support. Atom has also been retired which makes it even less likely to appear as a valid option on newer exams.

Anchor on the officially supported list of editors. Eliminate any set that includes an editor with no first party Copilot extension and watch for retired products that are unlikely to be correct.

The correct option is Maintain because it allows release coordinators to triage issues, apply labels and milestones, and guide pull request workflows while withholding admin and destructive capabilities such as deleting the repository or administering security and team access.

This role is designed for people who manage a repository day to day. It enables full issue and pull request management including labeling, milestone management, and merging or coordinating merges. It also allows non sensitive repository management like releases and some settings while preventing actions reserved for administrators such as changing visibility, deleting or transferring the repository, or managing teams and security settings.

The Triage role focuses on managing issues and pull requests without write access and it cannot merge pull requests or perform broader repository management, so it does not meet the coordination and workflow needs described.

The Write role grants push access and permits merging pull requests, yet it does not include the wider non sensitive repository management capabilities that coordinators typically need, and it is not the role GitHub recommends for repository managers who must avoid admin powers.

The Read role is view only and cannot triage, label, milestone, or guide pull requests, so it clearly does not satisfy the requirements.

Map the scenario verbs to roles. If you see manage the repository but avoid admin or destructive actions then prefer Maintain. If the tasks are only triaging issues and pull requests without merging then choose Triage. Pushing code and merging point to Write while view only points to Read.

The correct option is Pull requests where that user has been invited to review.

When you search pull requests using the review requested qualifier with a specific username, GitHub returns pull requests where that person has been requested as a reviewer. It focuses on pending review requests and does not require that the person has taken any review action yet.

Pull requests that were opened by that user is incorrect because that is matched by the author qualifier which filters by who created the pull request rather than who has been asked to review it.

Pull requests where that user has submitted a review or an approval is incorrect because those results come from the reviewed by or approved by qualifiers which indicate the user has already acted rather than simply being requested.

Pull requests assigned to that user is incorrect because that is covered by the assignee qualifier which is about task ownership rather than review requests.

Match the qualifier to the relationship and watch the verb. review requested means invited to review while reviewed by and approved by mean the user acted, and author or assignee indicate ownership.

The correct option is Open the repository settings in GitHub and add the person as a collaborator to send an invitation.

In a personal repository, the proper way to grant write access is by adding the person as a collaborator from the repository settings, which triggers an invitation that the contractor must accept. Once accepted, the collaborator has the necessary permissions to push commits and create pull requests on the private repository.

Send an email invite from her work email address is wrong because GitHub access is not granted through email. Permissions must be assigned within GitHub using the repository invitation flow.

Share the repository URL with the person so they can clone it is incorrect because a private repository cannot be cloned or pushed to without explicit access. The URL alone does not grant any permissions.

Add the developer to a GitHub organization team that has access to the repository is not applicable because the repository is owned by a personal account. Teams are an organization feature and cannot be used to grant access to a personal repository.

Notice whether the repository is owned by a personal account or an organization. For personal repositories think collaborator invitation. For organization repositories think teams or outside collaborators.