Free GitHub Foundations Certification Practice Exam Simulator (GH-900)

A developer at a civic-tech nonprofit is contributing to a toolkit hosted on example.com and has completed a feature branch with several commits, and the team wants to review and discuss the work before it can be merged into the default branch. What is the main purpose of opening a pull request in this situation?

• ❏ A. Create an issue to track a defect or enhancement

• ❏ B. Fork the repository into your own account

• ❏ C. Submit a set of commits for review and potential merge into the target branch

• ❏ D. Set up a Cloud Build trigger for continuous integration

In the mcnz.com website repository, your team wants to kick off work directly from an issue by creating a new branch from the issue page. Which users are allowed to create a branch in this way?

• ❏ A. Users with triage permission to the repository

• ❏ B. Any user who has write access to the repository

• ❏ C. Only users with admin permissions

• ❏ D. Only repository owners

A developer team at example.com is building a continuous integration pipeline with GitHub Actions and wants to clarify workflow concepts. In this context, what does the term job refer to?

• ❏ A. An event that triggers a workflow run

• ❏ B. A GitHub-hosted virtual machine used to run workflow steps

• ❏ C. A defined group of steps that execute sequentially on the same runner

• ❏ D. A reusable workflow called by another workflow

Priya is editing a README on GitHub and needs to make only the middle portion of a single word bold for emphasis. She has the text GuideCoreReference and wants Core to appear bold within the word. Which example uses the correct Markdown syntax to accomplish this?

• ❏ A. Guide*Core*Reference

• ❏ B. GuideCoreReference

• ❏ C. GuideCoreReference

• ❏ D. Guide_Core_Reference

When you close a GitHub project board in your organization workspace, what becomes of the project and its contents?

• ❏ A. All values and insights for the board are erased

• ❏ B. The project is permanently deleted from the platform

• ❏ C. The project remains intact and can be reopened later

• ❏ D. The project is moved into a separate archive section

A new engineer joins your team to help with the upcoming release of your company’s logistics tracking platform. You cannot recall how your own repository access was granted, and you want to make sure your colleague receives the correct permissions in the organization’s code repository. What should you do?

• ❏ A. Create a new team with write access to the repository and add your colleague to it

• ❏ B. Add your teammate as a direct collaborator on the repository yourself

• ❏ C. Ask an organization owner to review which teams are linked to the repository and have the owner or a team maintainer add your colleague to the appropriate team

• ❏ D. Tell your colleague to open a GitHub Support ticket to request repository access

A team at scrumtuous.com is trying to review the Code frequency chart under Insights for a heavily used GitHub repository, but the graph that shows commits and line additions and deletions will not load. Which condition could cause those insights to be unavailable?

• ❏ A. The repository is private and you only have read access

• ❏ B. The commit count in the repository exceeds 10,000

• ❏ C. You are not watching the repository

• ❏ D. The README file is missing

A product team at HarborTech Studios is enabling issue templates through the repository settings for a new open source project on GitHub and they want to rely on the built in defaults rather than creating custom templates. Which choices represent the default issue templates that GitHub provides for repositories? (Choose 2)

• ❏ A. Report a security vulnerability

• ❏ B. Bug report

• ❏ C. Cloud Functions

• ❏ D. Enhancement request

• ❏ E. Feature request

Priya Sharma is revising a README in a GitHub repository for a networking tool. She needs to show an inline command that includes an asterisk character and she wants to avoid Markdown turning it into emphasis. How can she keep the asterisk visible while keeping the example inline?

• ❏ A. Insert two backslashes before the asterisk

• ❏ B. Enclose the command in triple backticks

• ❏ C. Prefix the asterisk with a backslash

• ❏ D. Precede the asterisk with a forward slash

A product design team at StudioNimbus on example.com wants to automate build and test steps using GitHub Actions. Which statement best describes the kinds of events that can initiate a workflow run?

• ❏ A. Workflows can be triggered by GitHub events or on a schedule but they cannot be started by outside systems

• ❏ B. Cloud Pub/Sub can run GitHub Actions directly without any GitHub event configuration

• ❏ C. A workflow can start from GitHub repository activity, from scheduled times, or from events that come from outside systems

• ❏ D. Only commits and pull requests within the repository can start a workflow

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

At CedarTrail Analytics you started a Q and A discussion in a repository and a teammate posted a reply that resolves your issue. You want future readers to locate the solution quickly when they view the thread. What action should you take?

• ❏ A. Pin the discussion to the repository

• ❏ B. Convert the discussion to an issue and link back

• ❏ C. Mark the comment as the answer to the discussion

• ❏ D. Lock the conversation

A security architect at Nimbus Labs wants every user to authenticate through their corporate identity provider so that access to GitHub Enterprise Cloud organization assets stays centrally governed. Which authentication configurations in GitHub Enterprise Cloud depend on an external IdP for user sign in and lifecycle management?

• ❏ A. SAML single sign on only

• ❏ B. SCIM user provisioning

• ❏ C. SAML single sign on paired with Enterprise Managed Users

• ❏ D. GitHub personal accounts with 2FA

A product team at scrumtuous.com is configuring a GitHub Projects workspace to plan features for the next 90 days. Which layouts can they use to visualize and manage items within the project? (Choose 3)

• ❏ A. Sprint layout

• ❏ B. Board layout

• ❏ C. Looker Studio

• ❏ D. Roadmap layout

• ❏ E. Project layout

• ❏ F. Table layout

A product manager at StackBuild needs to set expectations for an upcoming feature launch. Which phase in StackBuild’s release lifecycle is characterized by rapid iteration, evolving requirements, and the absence of service level agreements?

• ❏ A. Private preview

• ❏ B. Alpha

• ❏ C. General availability

• ❏ D. Beta

A maintainer at CivicCode Labs wants to make it easier for first time contributors to join the project by tagging issues that are simple to start with. Which GitHub label should they use for those beginner friendly tasks?

• ❏ A. help wanted

• ❏ B. good first issue

• ❏ C. duplicate

• ❏ D. bug

A maintainer at scrumtuous.com wants certain tickets to be more noticeable to contributors in a crowded GitHub repository. When they pin an issue, what effect does that have?

• ❏ A. Pinning is required before an issue can be closed

• ❏ B. Pinning converts the issue into a completed item that is removed from the open list

• ❏ C. Pinning promotes the issue to the top of the repository’s issues list so it is more visible

• ❏ D. Pinning moves the issue into GitHub Projects for planning

A development team at scrumtuous.com is choosing tools for managing source code. Which activity is not part of the primary objectives of a version control system?

• ❏ A. Track who changed each file and when, and review the full history of edits

• ❏ B. Automatically enforce industry compliance requirements during file edits

• ❏ C. Restore a previous revision of a single file or the entire repository

• ❏ D. Enable many contributors to work concurrently through branching and merging

A development group at example.com maintains about 120 repositories and wants a tool that can automatically write a pull request summary that calls out the most important changes, lists which files were affected, and points reviewers to areas that need attention. Which GitHub offering provides this capability?

• ❏ A. GitHub Copilot Business

• ❏ B. GitHub Advanced Security

• ❏ C. GitHub Copilot Enterprise

• ❏ D. GitHub Enterprise Cloud

Blue Harbor Analytics is rolling out mandatory two factor authentication for all developers who use GitHub. During the initial setup, which methods can serve as the second verification step when signing in?

• ❏ A. Email verification or a password reset link

• ❏ B. A TOTP authenticator app on a phone or computer or an SMS text message

• ❏ C. The GitHub website or the GitHub Desktop application

• ❏ D. A security key by itself without first enabling another method

A product team at mcnz.com organizes work in GitHub Projects and wants to analyze progress using the Insights view. Which users are permitted to access and use the Insights page for a given project?

• ❏ A. Users with read access to the project

• ❏ B. Anyone who can view the project regardless of role

• ❏ C. Users with write permission or admin permission for the project

• ❏ D. Only users with admin permission for the project

Priya is developing a feature branch in a GitHub repository named “RepoAlpha” and realizes the work depends on a bug tracked in a different repository named “RepoBeta”. Can she reference the issue from “RepoBeta” within her pull request in “RepoAlpha” so that reviewers have full context?

• ❏ A. GitHub Projects

• ❏ B. No, GitHub restricts links to issues in the same repository

• ❏ C. Yes, you can reference an issue from another repository in the pull request

• ❏ D. Yes, but only if you have write access on both repositories

Priya maintains a repository on GitHub Enterprise Cloud for a fintech startup and needs a single place in the repository that lists every library and package her code depends on across supported ecosystems. Which GitHub feature should she use to view that information?

• ❏ A. Code scanning alerts

• ❏ B. Dependency graph

• ❏ C. Network graph

• ❏ D. Dependency review

A developer at scrumtuous.com has made several edits in a local Git repository and wants to check which files are modified and which ones are staged before creating a commit. Which command should they run to view the current state of the working directory and the staging area?

• ❏ A. git log

• ❏ B. gcloud source repos list

• ❏ C. git status

• ❏ D. git add

At Blue Harbor Software, a developer creates a branch from an issue and then opens a pull request from that branch. What happens automatically when the pull request is created?

• ❏ A. The pull request description is automatically replaced with the issue description

• ❏ B. The issue is automatically closed

• ❏ C. The pull request is automatically linked to the issue

• ❏ D. A new GitHub Actions workflow file is created automatically

CodeHarbor operates a widely used open source collaboration platform and aims to help maintainers with tools, guidance, and security capabilities. Which of the following is not a responsibility that CodeHarbor assumes for projects hosted on its platform?

• ❏ A. Curated best practice guidance for development workflows

• ❏ B. Built in development features and hosted services

• ❏ C. Security scanning that flags vulnerabilities in code and dependencies

• ❏ D. Enforcing legal and license compliance for projects

Your operations lead at mcnz.com is reviewing permissions in your GitHub organization and needs to remove any titles that are not recognized roles. Which option is not a valid GitHub organization role?

• ❏ A. Billing manager

• ❏ B. Organization owner

• ❏ C. Organization architect

• ❏ D. Security manager

• ❏ E. Organization member

A team at example.com is implementing continuous integration with GitHub Actions across several repositories. In this setup, what does a “runner” do and how does it participate in executing a workflow?

• ❏ A. Cloud Build

• ❏ B. A visual timeline of workflow execution in the Actions interface

• ❏ C. A compute runner that executes workflow jobs and supplies the runtime environment

• ❏ D. A repository maintainer who supervises automation settings

At Cascade Robotics the team plans a 90 day release on GitHub and wants to coordinate related issues and pull requests under a single target. What is the primary purpose of a milestone in this situation?

• ❏ A. To organize issues and pull requests by topic using labels

• ❏ B. To monitor progress for a defined set of related issues and pull requests toward a goal date

• ❏ C. To measure how many lines of code each contributor commits

• ❏ D. To limit access to selected repository features

A developer at Pinecone Analytics wants to keep track of notable open source work without following every update. Why would you star a repository or topic on GitHub, and how might that change what you see when you return to the site? (Choose 3)

• ❏ A. It automatically subscribes you to issue and release notifications for that repository

• ❏ B. It helps you find that repository or topic quickly later from your stars page

• ❏ C. It signals interest so GitHub recommends related repositories on your home dashboard

• ❏ D. It shows support for the maintainers and contributes to project visibility

A product team at scrumtuous.com wants outside contributors to make small fixes and commit changes without setting up a local development environment. Which GitHub capabilities let them edit source files and submit changes entirely in a web browser? (Choose 2)

• ❏ A. GitHub Projects

• ❏ B. GitHub Codespaces

• ❏ C. GitHub Dependabot

• ❏ D. github.dev editor

• ❏ E. Google Cloud Shell Editor

• ❏ F. GitHub Mobile

A software team at SilverTrail Media manages code in GitHub for about 25 internal services, and they rely on a distributed version control workflow. In this context, what does the word distributed actually signify?

• ❏ A. It means tasks can be easily divided among team members

• ❏ B. Cloud Load Balancing

• ❏ C. It indicates that each developer maintains a full local replica of the repository including its entire commit history

• ❏ D. It means code files are shared peer to peer between users

The engineering team at scrumtuous.com is rolling out two factor authentication across its GitHub Enterprise organization and wants the most phishing resistant and robust way for administrators to sign in with a second factor. Which authentication method should they adopt for the highest level of protection on GitHub Enterprise?

• ❏ A. SMS authentication

• ❏ B. Security keys

• ❏ C. TOTP

• ❏ D. SSH keys

A maintainer at BrightWave Labs is triaging a busy GitHub repository and wants to quickly surface the threads with the greatest community engagement. Can issues and pull requests be sorted by the most added reaction so that the most reacted items appear first?

• ❏ A. You can only sort by labels and milestones

• ❏ B. Yes, you can sort issues and pull requests by the most added reaction

• ❏ C. No, GitHub does not provide any sorting based on reaction counts

A team at HarborView Labs is standardizing developer environments with GitHub Codespaces and wants to know which parts of a codespace can be personalized without rebuilding the project. Which settings can be customized in a codespace? (Choose 4)

• ❏ A. You can rename the codespace display name

• ❏ B. You can open the codespace in another supported IDE

• ❏ C. You can replace the operating system that runs the codespace

• ❏ D. You can choose a different compute size for the codespace virtual machine

• ❏ E. You can change the default shell used inside the codespace

A developer at mcnz.com wants to keep up with activity from repositories on GitHub.com without repeatedly checking each project. In which places can they receive notifications from GitHub? (Choose 3)

• ❏ A. Google Cloud Pub/Sub topic

• ❏ B. The notifications inbox on the GitHub.com website

• ❏ C. The notifications inbox in GitHub Mobile which syncs with your GitHub.com inbox

• ❏ D. An email client configured with a verified email address

The correct option is Submit a set of commits for review and potential merge into the target branch.

A pull request is designed to propose changes so the team can examine the diff, discuss the approach, run checks, and then merge when the work meets the project standards. It collects the commits from the feature branch into a single reviewable request, which streamlines feedback and approvals before integration into the default branch.

Create an issue to track a defect or enhancement is incorrect because issues are used to plan and track work or report problems, while a pull request is used to review and merge code changes.

Fork the repository into your own account is incorrect because forking creates a separate copy of the repository. You might open a pull request from a fork, but the act of forking is not the purpose of a pull request.

Set up a Cloud Build trigger for continuous integration is incorrect because configuring a CI trigger is a separate automation task. A pull request may trigger CI checks, but opening one is primarily for proposing changes for review and possible merge.

Look for keywords like review, discuss, commits, and merge because these usually indicate a pull request rather than an issue, a fork, or a CI configuration.

The correct option is Any user who has write access to the repository.

Creating a branch is a code change action in GitHub. From an issue page the Create a branch control in the sidebar is available to contributors who can push to the repository. This capability does not require administrator or owner status.

Users with triage permission to the repository is wrong because the triage role is focused on managing issues and pull requests and it does not grant the ability to create or push branches.

Only users with admin permissions is wrong because admin is not required for branch creation from an issue and the feature is available to non administrators who have sufficient repository access.

Only repository owners is wrong because ownership is not required to create a branch and contributors who are not owners can still start a branch directly from an issue if they have the necessary access.

Map the task to the minimum required permission. If an action involves changing code then it usually needs push capability. Eliminate options that say only admins or owners when a regular contributor level suffices.

The correct option is A defined group of steps that execute sequentially on the same runner.

This choice describes a collection of steps that run one after another on the same runner within a workflow. Steps in such a group share the runner environment and workspace. Different groups can run in parallel when there is no dependency and they can also declare needs to control order across groups.

An event that triggers a workflow run is the mechanism that starts a workflow and not the structure that contains steps. Events initiate runs when something happens such as a push or a pull request.

A GitHub-hosted virtual machine used to run workflow steps describes a runner. A runner provides the execution environment but it is not the group of steps itself.

A reusable workflow called by another workflow refers to a separate workflow that can be called by other workflows. It is a distinct concept and not the unit that contains steps executed on one runner.

Map each option to GitHub Actions vocabulary and look for keywords. If it mentions triggers then it points to an event. If it mentions a virtual machine then it is a runner. If it mentions being called by another then it is a reusable workflow. The choice that says a group of sequential steps on the same runner is a job.

The correct option is GuideCoreReference.

GitHub uses CommonMark for Markdown rendering and strong emphasis is created with double asterisks. This syntax can be placed inside a word so only the Core portion becomes bold while the rest of the word remains normal.

Guide*Core*Reference is incorrect because single asterisks create italics rather than bold. Although asterisks can work inside a word this does not satisfy the requirement to make the text bold.

GuideCoreReference is incorrect because double underscores can create bold around words, yet underscores inside a word are not treated as emphasis in CommonMark and GitHub Flavored Markdown. The Core portion would not become bold in this intraword position.

Guide_Core_Reference is incorrect because single underscores are used for italics and intraword underscores are ignored for emphasis in GitHub Flavored Markdown. It also does not produce bold text.

When you need emphasis inside a word on GitHub prefer asterisks rather than underscores. Preview your Markdown to confirm that only the intended characters are emphasized.

The correct option is The project remains intact and can be reopened later.

Closing a GitHub project board changes its state to closed while preserving all columns, cards, and activity. The board is removed from the active list but it remains available to reopen whenever needed. The issues and pull requests linked to the board are unaffected and remain in their repositories. You can view closed boards in the organization or repository and reopen one to restore it to the active list without losing any data.

Classic project boards are being phased out in favor of the newer Projects experience. Even so, closing a classic board remains a reversible action that keeps its contents intact, which aligns with this behavior.

All values and insights for the board are erased is incorrect because closing does not delete cards, configuration, or history. Everything remains preserved in the closed board.

The project is permanently deleted from the platform is incorrect because deletion is a separate action. Closing is reversible and does not remove the project or its data.

The project is moved into a separate archive section is incorrect because closed boards are simply listed as closed rather than being relocated to a distinct archive area.

Watch for verbs that imply reversibility. Words like close or disable usually mean you can restore the resource later while delete or erase usually means permanent removal.

The correct option is Ask an organization owner to review which teams are linked to the repository and have the owner or a team maintainer add your colleague to the appropriate team.

In a GitHub organization, repository access is managed through teams that are connected to repositories with defined roles. Organization owners and team maintainers can add members to those teams, which grants the correct permissions in a consistent and auditable way. This approach follows least privilege because you place the engineer into an existing team that already has the right level of access.

Create a new team with write access to the repository and add your colleague to it is not ideal because it ignores the existing team mappings and can create redundant or overly permissive teams, and you might not have the authority to create or link teams. The better first step is to review the current teams connected to the repository.

Add your teammate as a direct collaborator on the repository yourself bypasses organization team governance and auditing, and it requires repository admin privileges that you may not have. Organizations are expected to use teams for access management rather than one off collaborator invites.

Tell your colleague to open a GitHub Support ticket to request repository access is incorrect because GitHub Support does not grant access to organization repositories and will direct you to an organization owner or maintainer to manage membership and permissions.

Match the action to the platform roles and look for owner and team maintainer responsibilities. Prefer team based access that aligns with least privilege and be wary of answers that create new resources unnecessarily or route to support for tasks that owners manage.

The correct option is The commit count in the repository exceeds 10,000.

GitHub disables some repository graphs when a project has an extremely large history so that performance remains acceptable. When a repository reaches this scale the Code frequency chart can be unavailable or fail to load because generating the underlying data is too resource intensive. This limitation is tied to repository size and activity rather than to a user’s relationship to the project.

The repository is private and you only have read access is not the cause because users with read access can view repository Insights. Privacy status by itself does not disable the Code frequency chart.

You are not watching the repository is not relevant because watching only affects notifications and does not control access to Insights graphs.

The README file is missing does not impact the Code frequency chart because that graph is calculated from commit history and line changes rather than from repository documentation.

When options mix user permissions or repository cosmetics with platform behavior, look for explicit limits or scale-driven constraints. GitHub Insights issues for large repositories usually stem from size thresholds rather than watch status or missing files.

The correct options are Bug report and Feature request.

When you enable the template chooser in a repository, GitHub provides two default issue templates named Bug report and Feature request. These templates are ready to use and cover common needs for capturing defects and proposing new functionality, which helps maintainers receive consistent and actionable information.

Report a security vulnerability is not one of the default issue templates. GitHub guides projects to handle security disclosures through a SECURITY.md policy and private reporting channels rather than a public issue.

Cloud Functions is unrelated to GitHub Issues and is not available as an issue template in repository settings.

Enhancement request is not a default template. The built in choice for requesting improvements is named Feature request.

When a question says the team will use defaults in GitHub, recall the small set of built in templates and eliminate options that look like labels, third party products, or security workflows.

The correct option is Prefix the asterisk with a backslash.

Markdown treats an asterisk as emphasis, and adding a backslash directly before it escapes the character so it is shown literally. This keeps the command inline and prevents unintended formatting.

Insert two backslashes before the asterisk is incorrect because only one backslash is required to escape the character, and adding two can introduce an extra visible backslash.

Enclose the command in triple backticks is incorrect because triple backticks create a fenced code block which is not inline.

Precede the asterisk with a forward slash is incorrect because a forward slash does not escape Markdown formatting.

When a symbol triggers Markdown formatting and the question asks to keep it inline, think of using a backslash to escape the character. If the option mentions fenced code blocks then it is likely not inline.

The correct answer is A workflow can start from GitHub repository activity, from scheduled times, or from events that come from outside systems.

GitHub Actions workflows can start from many repository events such as pushes, pull requests, issues, and releases. They can also run on a schedule using cron syntax in the workflow file. External systems can initiate runs by creating supported events through the GitHub API such as repository_dispatch or by invoking workflow_dispatch which allows programmatic manual runs. These capabilities together mean workflows can begin from repository activity, from scheduled times, and from events that originate outside GitHub.

Workflows can be triggered by GitHub events or on a schedule but they cannot be started by outside systems is incorrect because outside systems can start a run by calling the GitHub API to create a repository_dispatch event or by triggering workflow_dispatch, which proves that external initiation is supported.

Cloud Pub/Sub can run GitHub Actions directly without any GitHub event configuration is incorrect because a third party service cannot run jobs on its own. It must invoke a GitHub supported event such as repository_dispatch or workflow_dispatch or otherwise cause an event that the workflow is configured to listen for.

Only commits and pull requests within the repository can start a workflow is incorrect because many other events can initiate workflows including issues, releases, tags, schedules, manual dispatch, and external dispatch through the API.

When you evaluate trigger questions, check for the full set of initiators which are repository events, scheduled runs, and external dispatch. Beware of options that use words like only or cannot because they often omit supported triggers.

The correct choice is Mark the comment as the answer to the discussion.

In GitHub Discussions that use the Q and A format you can select a specific reply as the accepted answer. This action highlights the solution with a check mark and surfaces it prominently near the top of the thread which helps readers quickly find the resolution. It also marks the thread as answered which improves discoverability for others with the same issue.

Pin the discussion to the repository keeps the entire thread at the top of the Discussions list but it does not identify a particular reply as the solution and it does not move any comment to the top of the thread.

Convert the discussion to an issue and link back changes the item type and removes Q and A features that support accepted answers. It adds unnecessary overhead and still does not highlight the solving reply inside the original discussion.

Lock the conversation prevents new replies and does not help readers locate the solution. It can also hinder follow up if clarification is needed.

Match the action to the goal. When a scenario mentions a Q and A discussion and asks to highlight one solution, choose the option that lets you mark a reply as the answer rather than actions that affect the whole thread.

The correct option is SAML single sign on paired with Enterprise Managed Users.

This configuration requires users to authenticate with the external identity provider and it centralizes account lifecycle by making the accounts enterprise managed. The enterprise controls creation, suspension, and membership through the identity provider with provisioning handled by SCIM and access to organizations enforced by SAML single sign on. This pairing ensures that sign in and lifecycle are governed outside GitHub and that deprovisioning in the identity provider removes access consistently.

SAML single sign on only is not sufficient because users still own personal GitHub.com accounts and only their access to the organization is gated. The identity provider does not create or suspend the underlying GitHub accounts and users can still sign in to GitHub independently of the enterprise.

SCIM user provisioning is not an authentication method and it does not handle user sign in. On GitHub Enterprise Cloud it is part of the enterprise managed model and works in combination with SAML for Enterprise Managed Users rather than as a standalone answer.

GitHub personal accounts with 2FA rely on GitHub authentication and only add a second factor. They do not integrate with a corporate identity provider for centralized lifecycle or access governance.

When a question asks for both authentication and lifecycle control, prefer configurations that combine an external IdP with provisioning. Look for Enterprise Managed Users with SAML and eliminate answers that mention SSO only or 2FA only.

The correct options are Board layout, Roadmap layout, and Table layout.

Board layout provides a column based board so teams can visualize work as cards and move them across statuses. It supports drag and drop and is well suited for tracking flow during the next 90 days.

Table layout shows items in a spreadsheet like grid with fields, filters, sorts, and grouping. It is ideal for bulk editing and for creating saved views that highlight priority or owner during the planning window.

Roadmap layout displays items on a timeline based on date fields which lets the team plan and communicate schedules for the quarter. It helps you see dependencies and delivery windows at a glance.

Sprint layout is not a built in view in GitHub Projects. Teams can model sprints using iterations fields and then visualize that work with Table layout, Board layout, or Roadmap layout instead.

Looker Studio is a Google analytics and visualization product and it is not a GitHub Projects view. It cannot be used to visualize items within a GitHub project.

Project layout is not a valid view type. GitHub Projects provides views such as Table layout, Board layout, and Roadmap layout for managing items.

When you see a question about GitHub Projects views, recall the built in layouts of Table, Board, and Roadmap. Distractors often include generic names or third party tools that are not part of Projects.

The correct option is Alpha. It fits the description of rapid iteration, evolving requirements, and the absence of service level agreements.

In this phase teams move quickly to validate ideas and incorporate early feedback. Requirements change often and breaking changes are likely. Vendors typically do not provide SLAs or production guarantees because the focus is learning and shaping the feature rather than stability.

Private preview targets a small set of invited customers and emphasizes restricted access and confidentiality. While it can be experimental, the defining trait in this question is the explicit combination of fast iteration, changing requirements, and no SLAs, which aligns more directly with the alpha phase rather than the access model of a private preview.

General availability represents a stable and production ready release. This phase is characterized by SLAs, stronger compatibility commitments, and slower change, which contradicts the scenario described.

Beta is usually more stable and closer to feature complete. Changes are narrower and teams aim for production readiness even if an SLA may not always be offered, so it does not best match the rapid uncertainty and pace described.

Match clues to lifecycle signals. If you see rapid iteration and no SLA then think early stage such as alpha. If you see production readiness and an SLA then think GA.

The correct option is good first issue.

This default GitHub label identifies issues that are intentionally scoped to be easy to understand and implement so new contributors can onboard quickly. GitHub also surfaces issues with good first issue in discovery features which helps first time contributors find them.

help wanted asks for additional contributors but it does not guarantee the work is suitable for beginners and it often implies the task may need more experience or context.

duplicate is applied when an issue repeats an existing one so it does not represent a task to pick up for a newcomer.

bug tracks defects and can range from trivial to very complex which means it is not inherently targeted at first time contributors.

Match the scenario to the exact default label wording and focus on intent. For beginner friendly tasks think of good first issue while remembering that help wanted only signals a need for help and not simplicity.

The correct answer is Pinning promotes the issue to the top of the repository’s issues list so it is more visible.

When a maintainer pins an issue, GitHub displays it in a pinned section at the top of the Issues tab, which makes it stand out to contributors who are scanning the list. Pinning does not alter the issue’s state or status, and it only elevates visibility within the repository.

Pinning is required before an issue can be closed is incorrect because closing an issue is independent of pinning and anyone with the required permissions can close an issue whether it is pinned or not.

Pinning converts the issue into a completed item that is removed from the open list is incorrect because pinning does not change whether an issue is open or closed and it does not remove the issue from lists.

Pinning moves the issue into GitHub Projects for planning is incorrect because Projects is a separate planning tool and issues are added to a project explicitly while pinning only affects placement within the Issues view.

Map the action words to their effects on GitHub. Pin affects visibility, close changes state, and move to project changes planning context. If a choice mixes these up, it is likely incorrect.

The correct option is Automatically enforce industry compliance requirements during file edits.

This activity is typically handled by organizational processes and tooling such as code review, continuous integration checks, or policy services. A version control system may offer hooks that let teams run checks before commits, yet those checks are integrations layered on top and are not among the primary objectives of the system.

Track who changed each file and when, and review the full history of edits is a core function of version control. Systems like Git record authorship, timestamps, and commit messages and allow you to inspect the full change history for accountability and auditing.

Restore a previous revision of a single file or the entire repository aligns directly with version control goals. These systems let you recover earlier states of files or the whole project so you can safely undo mistakes or compare past versions.

Enable many contributors to work concurrently through branching and merging is fundamental to modern version control. Branching supports parallel work and merging integrates contributions back together while preserving history.

When a question asks what is not a core version control function, remember that history, collaboration, and recovery are central. Governance and compliance checks are usually provided by external pipelines or policy tools rather than the VCS itself.

The correct option is GitHub Copilot Enterprise because it provides AI generated pull request summaries that call out key changes, list which files were affected, and direct reviewers to areas that need attention.

With this plan you get Copilot features inside GitHub that can generate a concise pull request description and produce a running summary of the conversation and code changes. These capabilities help reviewers understand impact across many repositories and quickly focus on risky or complex areas while also enumerating the files involved.

GitHub Copilot Business is focused on code completion and chat in the IDE and on GitHub but it does not include the pull request summarization features available in the enterprise tier.

GitHub Advanced Security provides code scanning, secret scanning, and supply chain security features and it does not generate AI summaries for pull requests.

GitHub Enterprise Cloud is the hosting and management plan for GitHub organizations and it does not by itself provide AI generated pull request summaries.

When a scenario mentions AI pull request summaries or generate PR descriptions think about which tier brings Copilot into GitHub itself rather than only into editors and choose accordingly.

The correct option is A TOTP authenticator app on a phone or computer or an SMS text message.

A TOTP authenticator app generates time based one time codes on your phone or computer and GitHub accepts these codes as the second factor for sign in. An SMS text message can also deliver a one time code that you enter during sign in. You can use either of these methods to complete setup and to verify your identity when you sign in.

Email verification or a password reset link is incorrect because these are recovery or confirmation flows and they do not function as a second factor during authentication.

The GitHub website or the GitHub Desktop application is incorrect because these are clients you use to access your account and they are not verification factors that prove possession or generate codes.

A security key by itself without first enabling another method is incorrect because GitHub requires you to set up another method such as TOTP or SMS before you can add a security key and only then can the key serve as an additional second factor.

Read each option and ask whether it actually provides a one time code or a possession based check. Watch for distractors like clients or email flows that are not true second factors. Remember that a security key usually requires a first method to be configured before it can be added.

The correct option is Users with write permission or admin permission for the project.

Insights for GitHub Projects are intended for people who manage and update the project. GitHub therefore limits access to users who can modify the project or administer it so that the analytics are available to those responsible for planning and execution.

Users with read access to the project is incorrect because read permission does not include access to the Insights page.

Anyone who can view the project regardless of role is incorrect because simple visibility is not enough and access to Insights requires elevated permissions.

Only users with admin permission for the project is incorrect because users with write permission are also allowed to use the Insights page.

When a feature summarizes or analyzes project data, expect that write or admin permission is required rather than read. Look for verbs like view insights or manage that imply elevated access.

The correct option is Yes, you can reference an issue from another repository in the pull request.

GitHub supports cross repository issue references in pull requests and comments. You can include owner/repo#123 or paste the full URL of the issue from RepoBeta in the pull request description so reviewers in RepoAlpha have the needed context. GitHub will create a backlink on the issue and will show a preview to readers who have access. Visibility of the linked issue follows its repository permissions.

GitHub Projects does not address linking issues from another repository in a pull request. It is a planning and tracking feature rather than a mechanism for referencing issues inside a pull request conversation.

No, GitHub restricts links to issues in the same repository is incorrect because GitHub allows linking to issues across repositories by reference or by URL.

Yes, but only if you have write access on both repositories is incorrect because creating a reference does not require write access on both repositories. People will only see details if they have permission on the target repository.

When a question mentions cross repository context in a pull request, remember that typing owner/repo#number or pasting the full URL links the issue, and that visibility depends on repository permissions rather than write access.

The correct option is Dependency graph.

This feature aggregates all direct and transitive dependencies that GitHub detects from manifest and lock files and presents them in one place in the repository. It supports multiple ecosystems and works on GitHub Enterprise Cloud, which makes it the right choice when you need a single comprehensive list of the libraries and packages your code relies on.

Code scanning alerts reports security findings from code analysis tools and does not enumerate all dependencies across ecosystems, so it does not provide the single consolidated list that is required.

Network graph visualizes commit and branch history and activity among forks and does not show package or library dependencies, so it does not meet the requirement.

Dependency review focuses on changes to dependencies within pull requests to help assess risk when adding or updating packages rather than giving you a repository wide inventory.

Scan for phrases like single place and lists every library and package across ecosystems which point to the dependency graph. Mentions of pull requests suggest dependency review, while emphasis on static analysis findings suggests code scanning.

The correct option is git status because it shows the current state of the working directory and the staging area so you can see which files are modified and which are staged.

git status provides a clear summary of changes not staged for commit and changes staged for commit. It also shows untracked files so you can decide what to add or ignore before creating a commit.

git log is not correct because it shows the commit history and related metadata rather than the current modifications in the working directory or what is staged.

gcloud source repos list is not correct because it is a Google Cloud command that lists repositories in a project and it does not inspect the state of a local Git repository.

git add is not correct because it stages changes for the next commit and it does not display a summary of which files are modified or already staged.

Map the keywords working directory and staging area to the command that summarizes state. That is usually git status. If the question asks to view actual content differences think of git diff and for staged content think of git diff –staged.

The correct option is The pull request is automatically linked to the issue.

When you create a branch directly from an issue in GitHub and then open a pull request from that branch, GitHub creates an automatic link between the pull request and the issue. This ensures traceability and shows the connection on both the pull request and the issue without any manual step.

The pull request description is automatically replaced with the issue description is incorrect. GitHub does not overwrite the pull request description when you open it. You can edit the description yourself and templates may prefill it, yet it is not replaced by the issue text automatically.

The issue is automatically closed is incorrect. Issues close when a pull request is merged with closing keywords or when you close them manually, not when the pull request is created.

A new GitHub Actions workflow file is created automatically is incorrect. Workflow files are only added to the repository by commit and GitHub does not generate them for you when opening a pull request.

Look for cues that a branch was created from an issue since that usually means the pull request will be automatically linked, while closing an issue requires keywords or manual action and workflows must be added explicitly.

The correct option is Enforcing legal and license compliance for projects. CodeHarbor can provide tools and guidance to help maintainers, yet it does not take on the role of policing or guaranteeing licensing or broader legal compliance for every hosted project.

This is correct because hosting platforms can surface license metadata, offer license templates, and point to legal resources, but the decisions and enforcement related to compliance remain with the project owners and their organizations. The service does not provide legal advice and cannot enforce how others use or distribute code.

Curated best practice guidance for development workflows is something such platforms commonly provide because they publish guides, templates, and recommended workflows that help maintainers and contributors adopt healthy development practices.

Built in development features and hosted services is accurate since these platforms typically offer capabilities such as code review, issues, continuous integration, and other hosted tooling that supports day to day development work.

Security scanning that flags vulnerabilities in code and dependencies is also within scope because many platforms surface findings from static analysis and dependency advisories to help maintainers identify and remediate risks.

Scan for negative cues like not and except and restate the stem to confirm you are selecting what the platform does not do. When you see legal or enforcement in an option ask who owns that responsibility because it is usually the project owner rather than the hosting service.

The correct option is Organization architect because GitHub does not define that as a role at the organization level.

GitHub organizations provide a small set of predefined roles and scoped permissions. This title is not among the supported roles, which confirms that it should be removed when cleaning up access.

Billing manager is a valid role that allows someone to manage billing settings for the organization without requiring full organization membership.

Organization owner is a valid role that grants full administrative control over the organization.

Security manager is a valid role that can be assigned to a team so they can manage security settings and alerts across the organization.

Organization member is a valid role that represents standard membership in the organization.

Verify the role names against the GitHub documentation. Prefer the exact wording used by GitHub and treat unfamiliar job-like titles as likely distractors.

The correct option is A compute runner that executes workflow jobs and supplies the runtime environment.

In GitHub Actions a runner is a machine that listens for workflow jobs, checks out your code, sets up the tools and dependencies, and executes each step while streaming logs and statuses back to GitHub. The runner provides the isolation and operating system image for the job and it can be GitHub hosted or self hosted so it supplies the compute and environment that the steps need.

The option Cloud Build is a Google Cloud service for building and deploying and it is not part of GitHub Actions workflows.

The option A visual timeline of workflow execution in the Actions interface is the user interface that displays runs and jobs and it does not perform any execution.

The option A repository maintainer who supervises automation settings is a person who can configure permissions and policies and they do not execute workflow jobs.

When you see the term runner think about what actually executes the jobs and provides the environment. If a choice is only a UI element or a person then it is likely a distractor.

The correct answer is To monitor progress for a defined set of related issues and pull requests toward a goal date.

A milestone in GitHub groups issues and pull requests under a single target so the team can track how many items are open or closed and work toward a due date. This fits a 90 day release plan because the milestone provides a time bound container with progress indicators and filtering that keep related work aligned to the scheduled release.

To organize issues and pull requests by topic using labels is not the primary purpose in this scenario because categorizing by topic does not provide a goal date or an aggregate progress view for a release.

To measure how many lines of code each contributor commits is unrelated because milestones do not track individual contribution metrics and lines of code are not a reliable measure of progress.

To limit access to selected repository features is incorrect because access control is managed through repository permissions and settings rather than milestones.

Watch for cues like a fixed timeframe and a need to track progress across many issues and pull requests. Those words usually point to milestones with a due date and visible progress rather than labels or permissions.

The correct options are It helps you find that repository or topic quickly later from your stars page, It signals interest so GitHub recommends related repositories on your home dashboard, and It shows support for the maintainers and contributes to project visibility.

Starring acts like bookmarking. When you add a repository or topic to your stars, it appears on your Stars page so you can quickly find it when you return. This is the primary way to keep track of interesting work without committing to notifications.

Starring also tells GitHub about your interests. GitHub uses your activity to personalize recommendations, which can surface related repositories on your home dashboard and in Explore so you are more likely to discover similar projects when you come back.

Finally, stars are a public signal of appreciation. Higher star counts can help a project become more visible in discovery views and searches, which offers maintainers social proof and helps others find the project.

It automatically subscribes you to issue and release notifications for that repository is incorrect because starring does not enable notifications. You must choose to watch a repository if you want to receive updates about issues, pull requests, and releases.

Distinguish star from watch. If the question is about saving or discovery then think starring, and if it is about notifications then think watching.

The correct options are github.dev editor and GitHub Codespaces because both allow contributors to edit files and submit changes entirely in a web browser without setting up a local environment.

With Codespaces developers get a full cloud hosted development environment in the browser that uses a familiar editor and supports terminals and extensions. They can edit files, create branches, commit changes, and open pull requests without installing anything locally. Repository owners can use dev containers and prebuilds so Codespaces starts quickly and is consistent for all contributors.

The github.dev web editor opens instantly from any repository and provides a lightweight editing experience in the browser. It does not run servers or tasks, yet it lets users edit files, create a branch, and propose a pull request directly on GitHub, which is ideal for small fixes and documentation changes.

GitHub Projects is a planning and tracking tool for issues and work items and it does not provide a code editing experience in the browser.

GitHub Dependabot automates dependency updates and security alerts and it may open pull requests, but it does not let contributors interactively edit arbitrary source files in a browser.

Google Cloud Shell Editor is a Google Cloud service and not a GitHub capability, so it is outside the GitHub platform and is not what enables browser based editing of files in a GitHub repository.

GitHub Mobile focuses on notifications, reviews, and lightweight triage while the app is not designed for full code editing and committing workflows.

Match the verbs in the prompt to platform features. If you see edit and commit in a browser with no local setup, think of GitHub’s web editors and remove options about planning or automation.

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

The correct option is It indicates that each developer maintains a full local replica of the repository including its entire commit history.

In a distributed version control system like Git every clone is a complete repository with all commits, branches, and tags stored on the developer machine. This full local replica lets developers commit, branch, merge, and inspect history without network access and they only need to push and pull when they want to share or integrate changes. This design provides speed and resilience because work can continue even if a central server is unavailable and history is redundantly stored across clones.

It means tasks can be easily divided among team members is incorrect because distribution here does not refer to project management or task assignment. Git supports parallel workflows but the term describes how repository data is stored and shared.

Cloud Load Balancing is unrelated to version control in Git. Load balancing concerns routing traffic across servers while distributed in Git refers to repository clones and history on each developer machine.

It means code files are shared peer to peer between users is not accurate. Git can exchange data directly between clones but the core idea is that each clone carries the complete history rather than a system of ad hoc file sharing between users.

When a question uses the word distributed with Git think full local history and offline commits rather than task splitting or networking features.

The correct option is Security keys for the highest level of protection on GitHub Enterprise.

Security keys use FIDO2 and WebAuthn with hardware backed credentials that bind authentication to the real GitHub origin, so a phishing site cannot replay or proxy the sign in. They perform a challenge and response using private keys that never leave the device and they require an explicit user touch or presence, which stops credential theft and common code relay attacks.

GitHub supports Security keys for two factor authentication and treats them as the most secure choice for administrators who need strong, phishing resistant protection.

The SMS authentication option is vulnerable to SIM swapping and message interception and GitHub has been phasing out SMS authentication for new two factor enrollments, so it is neither robust nor phishing resistant.

The TOTP option relies on codes that users can be tricked into entering on a fake site because it does not validate the website origin, so it is phishable and weaker than Security keys.

The SSH keys option secures Git operations over SSH, which does not serve as a second factor for signing in to the GitHub web interface, so it does not meet the requirement.

When a question stresses the most phishing resistant second factor, favor hardware backed options like security keys rather than code based methods.

The correct option is Yes, you can sort issues and pull requests by the most added reaction.

GitHub supports sorting issue and pull request search results by reaction counts. You can use the reactions sort in search to bring items with the highest number of a specific reaction such as thumbs up to the top which helps a maintainer quickly surface the threads with the most community engagement.

You can run this search within a single repository or across GitHub and order the results so that the most reacted items appear first. This makes it easy to prioritize high signal conversations during triage.

You can only sort by labels and milestones is incorrect because labels and milestones are primarily filters and GitHub provides additional sorting options such as by reaction counts.

No, GitHub does not provide any sorting based on reaction counts is incorrect because GitHub search includes a reactions based sort for issues and pull requests that can return the most reacted items first.

When a question mentions most reactions or most reacted map that to the GitHub search reactions sort feature and be wary of answers that limit sorting to labels or milestones or deny the feature exists.

The correct options are You can rename the codespace display name, You can open the codespace in another supported IDE, You can choose a different compute size for the codespace virtual machine, and You can change the default shell used inside the codespace.

Renaming only updates the display name that you see in GitHub and it does not alter the dev container or the project files. This is a simple metadata change so no rebuild is needed.

Opening the same codespace in another supported IDE changes only the client you use to connect. The container keeps running with the same environment which means switching editors does not require a rebuild.

Choosing a different compute size updates the machine type for the running codespace. GitHub stops and restarts the virtual machine while preserving your persistent storage and container state so you do not rebuild the environment.

Changing the default shell is an editor or user preference that affects the integrated terminal. You can set a different shell profile or configure it through settings or dotfiles and this does not require rebuilding the container.

You can replace the operating system that runs the codespace is incorrect. The operating system comes from the dev container image or Dockerfile and changing it means updating the dev container configuration and rebuilding or recreating the codespace.

Identify whether a change is a runtime or editor preference versus a change to the dev container or base image. Preferences can be switched quickly while container changes usually require a rebuild.

The correct options are The notifications inbox on the GitHub.com website, The notifications inbox in GitHub Mobile which syncs with your GitHub.com inbox, and An email client configured with a verified email address.

The website inbox aggregates updates from repositories, organizations, and teams in one place. It supports filtering, saved views, and triage actions so a developer can keep up with activity without visiting each project individually.

The mobile app presents the same inbox and keeps it synchronized with the web experience. You can receive push alerts and triage notifications on the go and your actions reflect across both places.

Email is supported as a delivery channel when the account has a verified address. You can tailor which events generate messages and you can read and respond from your email client to stay current without opening each repository.

The Google Cloud Pub/Sub topic option is incorrect because GitHub does not deliver user notifications directly to that service. While custom integrations are possible with webhooks or external tooling, it is not a built in notifications destination.

Look for built in delivery channels documented by the platform and be cautious when a choice names an external cloud messaging service that would require custom integration.