A developer at scrumtuous.com is working in a local Git repository and wants to refer to the tip commit of the currently checked out branch using the standard symbolic name that Git recognizes, so what is this reference called in Git?

• ❏ A. MAIN

• ❏ B. HEAD

• ❏ C. ORIG_HEAD

• ❏ D. FETCH_HEAD

A repository maintainer at mcnz.com is preparing the next release and wants to use milestones to organize work across issues and pull requests. What practical reasons would lead them to create milestones in the repository? (Choose 2)

• ❏ A. To automate repository workflows

• ❏ B. To group related issues and pull requests under one release target

• ❏ C. To manage and audit third party dependencies

• ❏ D. To see how much work remains toward a specific goal or release

• ❏ E. To declare that the repository is currently stable

After earning the GitHub Foundations credential, Lena wants to opt in for early access so she can try experimental capabilities on GitHub before they reach general availability. Which GitHub feature should she enable to test in development functionality ahead of the full release?

• ❏ A. GitHub Sponsors

• ❏ B. GitHub Feature Previews

• ❏ C. GitHub Discussions

• ❏ D. GitHub Actions

A product team at scrumtuous.com hosts planning threads in GitHub Discussions as they collect feedback from contributors. They want a native feature that lets participants cast votes on proposals so they can gauge interest and guide roadmap priorities. Which GitHub Discussions capability should they use?

• ❏ A. Categories

• ❏ B. Polls

• ❏ C. Reactions

• ❏ D. Labels

Morgan maintains CI automation on GitHub using GitHub Actions and recently renamed the repository that hosts a custom action referenced across several workflows. What will occur for workflows that continue to point to the old repository path?

• ❏ A. GitHub Actions will automatically update the references to the renamed repository

• ❏ B. You can turn on repository redirects for actions so existing workflow references continue to run

• ❏ C. Workflows that still reference the previous repository path will fail to execute

• ❏ D. The workflows will keep running but will show a warning about the rename

At Savant Labs an administrator oversees about 24 engineering teams on GitHub Enterprise Cloud and wants each team to automatically mirror its identity provider group memberships by using the team synchronization capability. Which identity provider supports this team synchronization with organizations on GitHub Enterprise Cloud?

• ❏ A. PingOne

• ❏ B. Microsoft Entra ID

• ❏ C. Okta

• ❏ D. Google Cloud Identity

A developer at a small game studio wants to simplify everyday Git tasks by using GitHub Desktop on their laptop. Which capabilities does GitHub Desktop provide to support routine version control work?

• ❏ A. Automated testing, continuous integration, and release pipelines

• ❏ B. Web based code editing, cloud file versioning, and hosted repositories

• ❏ C. Command line Git console, live coauthoring, and project milestones

• ❏ D. Managing local repositories, creating branches, and using a graphical interface

Nimbus Labs uses GitHub Enterprise for source control and wants pull requests to automatically route to the right reviewers whenever certain folders change and they also want clear ownership for different parts of the repository. What purpose does a CODEOWNERS file serve in this process?

• ❏ A. It sets branch protection rules and required status checks for merging

• ❏ B. It documents licensing terms and any associated fees for using the code

• ❏ C. It maps file patterns to specific users or teams who own those areas so pull requests request their review automatically

• ❏ D. It stores code quality ratings and maintainability scores from static analysis

At BrightPixel Labs your administrators want to make a GitHub project reusable so new teams can quickly start work across the organization. With admin permissions on that project, which steps in the GitHub interface should you follow to mark the project as a template that others in your organization can use?

• ❏ A. Open Organization settings then navigate to Repository templates and create a repository template instead

• ❏ B. Open your organization and select Projects then in the left sidebar choose Use as template

• ❏ C. Open the project and choose Settings from the top right menu then in Templates turn on the Make template switch

• ❏ D. Go to your profile settings select Projects under your organization and click the Make template button

A developer at Solara Retail attempts to commit and push a 60 MiB data file to a GitHub repository using the command line. What behavior should they expect from Git during the push?

• ❏ A. Git requires enabling Git Large File Storage before continuing

• ❏ B. Git stops the push and refuses to accept the file

• ❏ C. Git prints a large file size warning yet the push can complete

• ❏ D. The push is rejected and the tool suggests uploading the asset to Cloud Storage instead

Use GitHub Foundations practice exams on Udemy and certificationexams.pro to help you prepare.

A small developer team plans to publish an app on GitHub Marketplace and wants to charge customers for subscriptions. Under Marketplace rules, who must own the app for paid plans to be allowed?

• ❏ A. A verified partner organization account

• ❏ B. An individual developer account

• ❏ C. An organization account

• ❏ D. Any account that lists an app on GitHub Marketplace

A small engineering team at NovaByte uses the GitHub Free plan for a private repository and wants to assign several teammates to a bug fix issue. What is the maximum number of assignees they can set for that issue?

• ❏ A. Up to 3 people

• ❏ B. Unlimited

• ❏ C. One assignee only

• ❏ D. Up to 12 people

Riverton Analytics is onboarding a regulated product to GitHub and wants stricter control over changes that reach the main branch. How do branch protection rules help reinforce secure development practices for this repository?

• ❏ A. CODEOWNERS

• ❏ B. Dependabot alerts

• ❏ C. Enforce required reviews and successful status checks on protected branches before merging

• ❏ D. Use a .gitignore file to stop tracking confidential files

A developer at a small nonprofit wants an introduction to appear at the top of their GitHub user profile. Which file should they create or modify so that this content shows on the profile?

• ❏ A. Only account settings can change the profile

• ❏ B. A README.md in a repository that matches the username

• ❏ C. A CONTRIBUTING.md in the profile repository

A development team at mcnz.com plans to standardize on GitHub Codespaces for contributors and wants to tailor the environment to their workflow. Which settings in a codespace can be customized? (Choose 4)

• ❏ A. Switch the host operating system to macOS or Windows

• ❏ B. Update the display name of a codespace for easier identification

• ❏ C. Pick a different compute size for the codespace virtual machine

• ❏ D. Choose a Google Cloud project where the codespace runs and bills to

• ❏ E. Set or switch the shell used in the terminal within a codespace

• ❏ F. Specify the geographic region where new codespaces are provisioned

A small nonprofit named Cedar Ridge Arts wants a simple way to publish a static site directly from a GitHub repository without managing servers. What is GitHub Pages primarily for and when would you choose to use it?

• ❏ A. GitHub Pages acts as the system of record for commits and branching across a codebase

• ❏ B. GitHub Pages is intended for making a repository’s source tree browsable on the web rather than publishing a site

• ❏ C. GitHub Pages publishes static websites straight from a repository and is well suited for project sites documentation or personal portfolios

• ❏ D. GitHub Pages lets you run backend code from your repo to power dynamic applications with databases

A product team at scrumtuous.com is configuring GitHub Projects and wants to use only the built-in default project workflows to keep items updated automatically. Which event is not available as a default project workflow trigger in GitHub Projects?

• ❏ A. Item reopened

• ❏ B. Issue assigned

• ❏ C. Auto-archive items

• ❏ D. Code review approved

A small engineering team at scrumtuous.com is setting up a new GitHub repository for an internal tool and wants to keep it organized and collaborative from the start. Which practices and features should they adopt to maintain a healthy repository? (Choose 3)

• ❏ A. Delete commit history to shrink the repository

• ❏ B. Enable Git Large File Storage for oversized assets

• ❏ C. Create a README file to explain the project

• ❏ D. Prefer working in branches instead of forks

Lakeview Robotics follows GitHub Flow with short lived feature branches that merge into main through pull requests. After a branch is merged and the release has passed a 48 hour staging soak, what is the primary reason the team should remove that merged branch?

• ❏ A. To prevent all future merge conflicts related to the feature

• ❏ B. To avoid accidental use of an obsolete branch and to signal that the work is complete

• ❏ C. To speed up git clone and fetch by shrinking repository history

• ❏ D. To speed up Google Cloud Build pipelines for subsequent commits

At Blue Harbor Analytics you need to give a contractor access to a single private repository for 45 days without making them an organization member. Which statement accurately describes a limitation of an outside collaborator compared with an organization member on GitHub?

• ❏ A. An outside collaborator is not required to enable two factor authentication when the organization enforces it

• ❏ B. An outside collaborator can view every team and the full list of members in the organization

• ❏ C. An outside collaborator cannot be added to any team in the organization

• ❏ D. An outside collaborator can @mention any visible team in issues and pull requests

Use GitHub Foundations practice exams on Udemy and certificationexams.pro to help you prepare.

Priya maintains an active GitHub repository for the scrumtuous.com organization with many collaborators. She wants to keep the CODEOWNERS file under the platform limit so that it always loads and code owner reviews are requested automatically. What is the largest allowed size for a CODEOWNERS file on GitHub?

• ❏ A. 5 MB

• ❏ B. 1 MB

• ❏ C. 3 MB

• ❏ D. 2 MB

At NovaCode Studio your team is standardizing on reusable workflows in GitHub Actions to avoid duplicating automation. From which locations can one workflow invoke another reusable workflow while complying with GitHub access rules? (Choose 3)

• ❏ A. A Docker container image hosted on Docker Hub

• ❏ B. The same repository that contains the calling workflow

• ❏ C. A public repository when organizational policy permits use of public reusable workflows

• ❏ D. A private repository that has been configured to allow access for reuse

At a mid sized retailer called BrightWave Outfitters, engineering leads want to break down team silos and increase reuse of internal code. They are evaluating InnerSource as a practice. Which description captures a core trait of InnerSource in this context?

• ❏ A. Using a private hosted Git platform

• ❏ B. Adopting open source style collaboration and transparency within the company

• ❏ C. Implementing Scrum or Kanban practices to manage sprints

• ❏ D. Running closed development that keeps code limited to the originating team

A cross functional team at scrumtuous.com is adopting GitHub Projects to plan quarterly releases and track roadmap items. Which practices should they put in place to manage their Projects effectively? (Choose 5)

• ❏ A. Leverage appropriate field types such as iteration, single select, and date to model work

• ❏ B. Prefer ad hoc email threads over issues and pull requests for coordination

• ❏ C. Keep the project description, README, and status updates current to share context

• ❏ D. Split large issues into smaller issues so work can progress in parallel

• ❏ E. Maintain a single source of truth for key information so details do not diverge

• ❏ F. Use @mentions to notify specific teammates or groups in comments and discussions

At scrumtuous.com, a maintainer creates a new repository named orchard-api for an internal tool. Who is allowed to enable GitHub Discussions for this repository?

• ❏ A. Organization owners only

• ❏ B. The repository owner and any collaborator who holds Write permissions

• ❏ C. Any authenticated user who can view the repository

• ❏ D. Collaborators with Triage permissions

Rivertown Analytics wants to accelerate onboarding for new projects while keeping a consistent starter layout across teams. In GitHub, which actions are supported when you work with repository templates to achieve this? (Choose 2)

• ❏ A. Delete all repositories that originated from a specific repository template in a single step

• ❏ B. Create a new organization from a repository template

• ❏ C. Convert an existing repository into a template repository

• ❏ D. Create a new repository from a template repository

• ❏ E. Remove every repository in the organization that does not use an approved template

A small engineering team at mcnz.com is starting to use Git for source control and wants a place to collaborate with pull requests and issues. They want to understand what GitHub is in relation to Git. Which description best fits GitHub?

• ❏ A. Cloud Source Repositories

• ❏ B. A code editor

• ❏ C. A web based service that hosts Git repositories and adds collaboration tools such as pull requests and issues

• ❏ D. A version control system

Your compliance team at Northwind Labs is drafting access guidelines for repositories that hold highly confidential source code on GitHub. Which authentication approach should your developers avoid using for these sensitive workflows?

• ❏ A. Deploy keys

• ❏ B. Basic username and password sign in

• ❏ C. Personal access tokens

• ❏ D. SSH keys

A developer at Suntrail Labs is standardizing automation with GitHub Actions across several projects. In which locations can the team define reusable actions so that their workflows can reference them? (Choose 3)

• ❏ A. Any public repository

• ❏ B. Google Artifact Registry

• ❏ C. The same repository as the workflow file

• ❏ D. A published Docker container image on Docker Hub

Your team at scrumtuous.com is preparing to set up collaboration in GitHub for a new project. Which statement correctly distinguishes a personal account from an organization account on GitHub?

• ❏ A. Only personal accounts support SSH key authentication while organization accounts only allow password sign in

• ❏ B. An organization account can only be created if you purchase GitHub Enterprise Cloud

• ❏ C. An organization account supports multiple owners and members whereas a personal account is associated with one individual

• ❏ D. Only organization accounts can own repositories and personal accounts cannot create repositories

A development team at Orion Media wants to extend their repositories with vetted integrations. They are evaluating GitHub Marketplace and need to know its main purpose. What is GitHub Marketplace primarily used for?

• ❏ A. Providing customer support for GitHub accounts

• ❏ B. Connecting developers with potential employers and partner organizations

• ❏ C. Discovering and installing free and paid apps and actions that add capabilities to GitHub workflows

• ❏ D. Publishing and monetizing solutions on Google Cloud Marketplace

In GitHub Projects, how can you bring issues and pull requests into a project board so that teams can track work efficiently?

• ❏ A. Only by using the GitHub CLI

• ❏ B. Manually one by one, with automation rules, or by importing many items together

• ❏ C. Only through automated project workflows such as GitHub Actions

• ❏ D. Only by adding one item at a time manually

A small engineering team at mcnz.com is choosing a tool for source control and collaboration. What is the most accurate way to describe GitHub so the team knows what it provides?

• ❏ A. GitHub is primarily a continuous integration and delivery tool

• ❏ B. GitHub is a distributed version control system

• ❏ C. GitHub is a hosted platform built around Git that adds collaboration and code management capabilities

• ❏ D. GitHub is a file sharing site that relies on centralized version control

At OrionCode Labs a group of four engineers contributes to the same GitHub repository every day and they want a straightforward workflow that supports code review and keeps work centralized. What approach should they use to collaborate effectively?

• ❏ A. Have each developer fork the repository and submit pull requests across repositories

• ❏ B. Use a single shared repository and open pull requests from feature branches

• ❏ C. Create a separate Git submodule for each contributor

• ❏ D. Commit straight to the default branch without creating branches

A team working on a shared repository in a hosted Git platform reviews changes through pull requests. When they finalize a contribution, what happens if they choose the “Squash and merge” option?

• ❏ A. It integrates the pull request using a fast-forward so no merge commit is created

• ❏ B. It bypasses required reviews so changes can land directly in the main branch

• ❏ C. It condenses every commit from the pull request into a single commit and merges that into the target branch

• ❏ D. It drops all commits from the pull request and leaves the default branch unchanged

The correct option is HEAD because it is the standard symbolic name Git uses for the tip of the currently checked out branch.

HEAD is a symbolic reference that usually points to the current branch under refs or heads and it advances as you make new commits on that branch. When you check out another branch the pointer moves to follow it. In a detached state HEAD can point directly to a specific commit which still represents the commit you are currently on.

The option MAIN is not a special symbolic name in Git. MAIN is commonly used as a default branch name but it is simply a normal branch and it does not inherently refer to the currently checked out branch.

The option ORIG_HEAD records the previous position of your head before operations such as merge or rebase so it is meant for recovery and reference and it does not indicate the current branch tip.

The option FETCH_HEAD records the result of the most recent fetch from a remote so it captures what was fetched and where it came from and it is not the tip of your currently checked out branch.

When a question asks for the tip of the currently checked out branch think of the symbolic reference that moves when you checkout another branch or commit. That is the one Git calls HEAD.

The correct options are To group related issues and pull requests under one release target and To see how much work remains toward a specific goal or release.

Milestones let maintainers associate issues and pull requests with a single named goal such as a version or release. This creates a central place to plan scope and track the set of related work which improves visibility and coordination across the team.

Milestones also provide a clear view of progress with counts and a progress bar for open and closed items. This makes it easy to assess remaining work toward the goal and to adjust priorities so the target can be met.

To automate repository workflows is incorrect because automation is handled by GitHub Actions while milestones are used for grouping and tracking work.

To manage and audit third party dependencies is incorrect because dependency management and auditing are provided by the dependency graph and Dependabot rather than milestones.

To declare that the repository is currently stable is incorrect because stability is communicated through releases, tags, or documentation while milestones are for organizing and tracking progress.

Map each feature to its primary purpose before choosing answers. Milestones organize issues and pull requests and show progress toward goals while automation and dependency auditing belong to other GitHub features.

The correct option is GitHub Feature Previews.

GitHub Feature Previews lets users opt in to experimental capabilities so they can try features in development before those features reach general availability. It is designed for early access and feedback which matches the scenario described.

GitHub Sponsors is a funding program that helps developers and organizations financially support open source maintainers and projects. It does not provide early access to experimental platform features.

GitHub Discussions provides a community forum for Q and A and ideas and announcements within a repository or organization. It is not a mechanism for enabling pre release features.

GitHub Actions is the automation and continuous integration and delivery service for building and deploying workflows. It does not control early access to new GitHub platform functionality.

Watch for keywords like early access and experimental features which usually point to the opt in mechanism provided by Feature Previews rather than a product area like Actions or Discussions.

The correct option is Polls because it is the native way in GitHub Discussions for participants to cast votes on proposals and view results that help prioritize a roadmap.

This feature lets maintainers add choices inside a discussion and allows contributors to vote directly in the thread. Results are tallied automatically which makes it easy to measure interest at a glance and to base planning decisions on clear counts rather than manual tallies.

Categories organize discussions into topical buckets and can control the format of posts in each bucket, yet they do not provide a voting mechanism.

Reactions allow emoji responses on posts and comments and they can signal sentiment, but they are not a structured voting tool and they do not offer multiple explicit options or aggregated tallies.

Labels are used to classify and filter items for triage and reporting, and they are not designed for voting in discussions.

When a scenario emphasizes voting and visible tallies in GitHub Discussions, map it to the feature named Polls rather than sentiment features like reactions or organizational tools like labels and categories.

The correct option is Workflows that still reference the previous repository path will fail to execute.

GitHub Actions resolves the action repository at run time using the owner and repository name in the uses entry. After a repository is renamed the old path no longer resolves for Actions. Actions does not follow repository redirects for referenced actions which prevents silent redirection to unexpected code. As a result any workflow that continues to point to the prior path fails during action resolution until you update the uses reference to the new repository path or to a specific commit SHA.

GitHub Actions will automatically update the references to the renamed repository is incorrect because GitHub does not edit your workflow files and it will not change the uses entries for you. You must update them yourself.

You can turn on repository redirects for actions so existing workflow references continue to run is incorrect because there is no setting that enables redirects for Actions. While repository renames create redirects for web and Git operations, Actions does not honor repository redirects for security reasons.

The workflows will keep running but will show a warning about the rename is incorrect because the runs do not continue and they fail to resolve the action rather than proceeding with a warning.

When a workflow references an external action verify the exact repository path in the uses entry. If the action repository is renamed then update the path promptly and consider pinning to a full length commit SHA to avoid surprises.

The correct option is Microsoft Entra ID.

GitHub Enterprise Cloud supports team synchronization with Microsoft Entra ID so you can map identity provider groups to GitHub teams and keep membership in sync automatically. When group membership changes in Entra ID the corresponding team membership in GitHub updates without manual maintenance. This is the only identity provider that integrates with this feature for organizations on Enterprise Cloud.

The option PingOne is not supported for GitHub team synchronization on Enterprise Cloud and it cannot mirror identity provider groups to teams.

The option Okta can provide single sign on and user provisioning for GitHub but team synchronization is not available with this provider on Enterprise Cloud.

The option Google Cloud Identity does not integrate with GitHub team synchronization and it cannot automatically map groups to teams.

Scan for the phrase team synchronization with GitHub Enterprise Cloud and remember it is supported only with Microsoft Entra ID. If several identity providers are listed then pick the one tied to this feature.

The correct option is Managing local repositories, creating branches, and using a graphical interface.

GitHub Desktop is designed to make everyday Git tasks easier through a point and click experience. It lets you add or clone a local repository and it provides simple workflows to create and switch branches, commit changes, and synchronize with remotes. The application focuses on a graphical interface so you can stage files, review diffs, resolve many merge conflicts, and push or pull without needing to use the command line for common actions.

Automated testing, continuous integration, and release pipelines is incorrect because those capabilities belong to continuous integration services such as GitHub Actions or other CI tools rather than the Desktop client.

Web based code editing, cloud file versioning, and hosted repositories is incorrect because those are features of GitHub on the web where repositories are hosted and edited online, while Desktop is a local application that works with repositories on your machine and syncs with remotes.

Command line Git console, live coauthoring, and project milestones is incorrect because GitHub Desktop does not include its own integrated command line console and it does not provide real time coauthoring or project milestone management, which belong to other tools such as your editor or GitHub Issues and Projects.

Match the tool to its scope. GitHub Desktop is a local GUI for routine Git actions like commits and branches, while cloud CI, hosted repos, and web editing belong to GitHub services on the web.

The correct option is It maps file patterns to specific users or teams who own those areas so pull requests request their review automatically.

A CODEOWNERS file lists path patterns and assigns them to GitHub users or teams. When a pull request changes files that match those patterns, GitHub automatically requests reviews from the specified owners. This creates clear ownership for folders or components and ensures the right reviewers are included without manual triage.

It sets branch protection rules and required status checks for merging is incorrect. Branch protection and required checks are configured in repository or organization settings. The CODEOWNERS file does not create these rules, although branch protection can require reviews from code owners who are defined by the file.

It documents licensing terms and any associated fees for using the code is incorrect. Licensing information belongs in a LICENSE file or related documentation rather than in CODEOWNERS.

It stores code quality ratings and maintainability scores from static analysis is incorrect. Quality metrics come from code scanning or other analysis tools and surface in checks or reports, not in CODEOWNERS.

Look for keywords such as file patterns, ownership and automatic reviewer requests. These usually indicate a CODEOWNERS file, while mentions of branch protection or required checks point to repository settings instead.

The correct option is Open the project and choose Settings from the top right menu then in Templates turn on the Make template switch.

This path is the one provided in the GitHub Projects interface for admins. You open the specific project that you want to share, go to its Settings, locate the Templates section, and enable the Make template toggle so the project can be used as a starting point by others in your organization. Once enabled, teammates can create new projects from it which ensures consistent configuration and fields.

Open Organization settings then navigate to Repository templates and create a repository template instead is incorrect because repository templates are for repositories and do not mark a GitHub Project as a template. This path would not expose a project for reuse in the Projects experience.

Open your organization and select Projects then in the left sidebar choose Use as template is incorrect because the organization level Projects list does not provide a Use as template action for making a project a template. This setting lives within the project’s own Settings page.

Go to your profile settings select Projects under your organization and click the Make template button is incorrect because personal profile settings do not control an organization project’s template status. The Make template toggle is found within the project itself under Settings.

When you see choices that differ by navigation scope, identify the resource being configured and look for the action inside its Settings. Also separate a repository template from a project template since they live in different places.

The correct option is Git prints a large file size warning yet the push can complete.

A 60 MiB file is above GitHub�s warning threshold of 50 MB yet it is still below the 100 MB hard limit. During the push you will see a warning about large files while the server accepts the objects so the push completes. Git Large File Storage can be helpful for large or binary assets yet it is not required for a file of this size.

Git requires enabling Git Large File Storage before continuing is incorrect because GitHub does not require LFS for files under 100 MB. A push with a file in this range proceeds with only a warning.

Git stops the push and refuses to accept the file is incorrect because that failure occurs when a single file exceeds the 100 MB limit. At 60 MiB the push succeeds with a warning.

The push is rejected and the tool suggests uploading the asset to Cloud Storage instead is incorrect because GitHub does not redirect users to a separate cloud storage service for files in this range and it simply warns and allows the push.

Memorize the GitHub thresholds and map the scenario to them. Watch for a 50 MB warning versus a 100 MB hard limit and remember that Git LFS is optional unless you exceed the hard limit or need better handling of large binaries.

Use GitHub practice exams on Udemy and certificationexams.pro to help you prepare.

The correct option is An organization account. Under GitHub Marketplace rules, only apps that are owned by an organization can offer paid subscriptions.

Paid plans require organization ownership because Marketplace billing, payouts, and tax processes are set up for businesses rather than personal accounts. The listing requirements explicitly state that paid pricing plans are only available when the app is owned by an organization, which ensures the partner can configure payments and comply with Marketplace policies.

A verified partner organization account is not correct because partner verification is a separate program and is not required to enable paid plans. The rule is about ownership by an organization and not about holding a partner verification status.

An individual developer account is not correct because personal accounts cannot offer paid subscriptions on GitHub Marketplace. Individuals can publish free apps, but paid plans require organization ownership.

Any account that lists an app on GitHub Marketplace is not correct because paid plans are restricted to apps owned by an organization and this is more specific than simply having any type of account.

When you see questions about Marketplace paid plans, look for the ownership requirement. If the ownership is not an organization, eliminate it, even if the option mentions partner status or general eligibility.

The correct option is One assignee only. On a GitHub Free plan private repository you can assign only a single person to an issue, so the maximum is one.

This keeps assignment simple for small teams and aligns with the reduced collaboration features that come with the free plan for private work. It means you cannot distribute responsibility for a single issue across multiple assignees in that context.

Up to 3 people is not supported for a private repository on the free plan because you cannot assign multiple people to a single issue in that scenario.

Unlimited is never correct because GitHub enforces caps on issue assignees and the free plan does not remove those limits.

Up to 12 people overstates what is possible on the free plan and is not available for private repositories in this situation.

When a question mentions plan and repository type pay attention to limits that can restrict collaboration features. If an option claims unlimited and the feature is usually capped then eliminate it quickly.

The correct option is Enforce required reviews and successful status checks on protected branches before merging.

Branch protection rules allow maintainers to require approving pull request reviews and passing status checks before any change can be merged. This ensures that only validated and reviewed code reaches the main branch. These rules can also prevent force pushes and deletions and can restrict who can push which strengthens governance for regulated environments.

CODEOWNERS designates ownership and can automatically request reviewers which is helpful for accountability but it does not block merges on its own. Only a protection rule that requires reviews will enforce a gate.

Dependabot alerts provide security notifications for vulnerable dependencies and help teams remediate risk. They do not control merge behavior and they are not a branch protection mechanism.

Use a .gitignore file to stop tracking confidential files helps avoid adding certain files to future commits on developer machines but it does not enforce reviews or status checks and it does not protect against already committed secrets.

When you see mentions of branch protection rules look for answers that add merge gates like required reviews and required status checks. Features that notify or suggest reviewers often complement protections but do not enforce them by themselves.

The correct option is A README.md in a repository that matches the username.

GitHub supports a special profile repository that must be named exactly the same as your account. You create it as public and place a README.md at the root. GitHub then displays that profile README at the top of your user profile and it updates automatically when you push changes. This is the intended way to add an introduction.

Only account settings can change the profile is incorrect because settings let you edit your name, bio, location, and other metadata but they do not create a custom introduction section. The introduction is powered by the profile README.

A CONTRIBUTING.md in the profile repository is incorrect because a CONTRIBUTING file provides contribution guidelines for a project. It is shown within repositories for collaborators and it does not render on a user profile.

When a question asks how to add custom content to a GitHub profile, look for the special repository named exactly your username with a public README.md. Mentions of only account settings or using CONTRIBUTING.md usually indicate distractors.

The correct options are Update the display name of a codespace for easier identification, Pick a different compute size for the codespace virtual machine, Set or switch the shell used in the terminal within a codespace, and Specify the geographic region where new codespaces are provisioned.

Renaming a codespace is supported and lets teams keep environments easy to recognize across multiple projects or tasks. You can change a codespace name from the GitHub interface or through supported tools so lists remain clear as work evolves.

Choosing a machine type is a built in capability that allows you to align CPU and memory with the workload. You can start with a smaller configuration and later change to a larger one if builds or tests need more resources.

Switching the terminal shell is also supported. You can select bash, zsh, or another shell through the editor’s terminal profiles or by configuring your dotfiles so contributors work in a familiar command line environment.

Setting a region for new environments is available so you can place codespaces closer to your developers or data and reduce latency. Organizations can also control which regions are allowed and set defaults to keep provisioning consistent.

Switch the host operating system to macOS or Windows is incorrect because GitHub Codespaces run on Linux based virtual machines and you cannot change the underlying host operating system to macOS or Windows.

Choose a Google Cloud project where the codespace runs and bills to is incorrect because Codespaces are hosted on GitHub’s infrastructure and billed through GitHub’s billing on Azure infrastructure rather than through Google Cloud projects.

Scan each option for what layer it targets. Features like name, machine size, shell, and region are customizable, while the underlying host platform or third party cloud billing are usually fixed. If an option changes the managed infrastructure or external provider, be skeptical.

The correct option is GitHub Pages publishes static websites straight from a repository and is well suited for project sites documentation or personal portfolios.

This choice matches the need for a simple workflow because GitHub Pages serves static files directly from a repository branch or a docs folder and requires no server management. It is commonly used for project sites and documentation and portfolios and it supports custom domains and automatic HTTPS and optional Jekyll based site generation.

GitHub Pages acts as the system of record for commits and branching across a codebase is incorrect because that describes Git and repository features while GitHub Pages is for static site hosting rather than version control.

GitHub Pages is intended for making a repository’s source tree browsable on the web rather than publishing a site is incorrect because browsing code is handled by the GitHub web interface while GitHub Pages exists to publish a website from repository content.

GitHub Pages lets you run backend code from your repo to power dynamic applications with databases is incorrect because GitHub Pages serves static content only and it cannot run back end code or connect to databases.

Look for phrases like static site and no servers and directly from a repository to identify GitHub Pages. Mentions of databases or back end code point to a different hosting solution.

The correct option is Issue assigned because assignment changes are not provided as a built in default project workflow trigger in GitHub Projects.

GitHub Projects includes default workflow triggers for common item and pull request events so items can move or update automatically without custom automation. These include item state changes such as when an item is added to a project, reopened, or closed, and pull request events such as review approvals or changes requested. There is no default trigger for assignment changes, so Issue assigned does not appear in the built in list.

Item reopened is available as a default trigger and can be used to update fields or move an item when an issue or pull request is reopened.

Auto-archive items is a built in workflow that automatically archives items after a period of inactivity based on the configuration you choose.

Code review approved is covered by the default trigger for pull request reviews that are approved, which can update project fields or move items when a review approval occurs.

When you see questions about default project workflows, mentally group events into item state changes and pull request review or merge events. If an event feels more like an assignment or label change, it is often not a built in trigger.

The correct options are Enable Git Large File Storage for oversized assets, Create a README file to explain the project, and Prefer working in branches instead of forks.

This choice keeps large binaries out of the Git history by storing lightweight pointers while the actual files live in a specialized storage. It reduces repository size and speeds up cloning and fetching, and it prevents the history from ballooning when large assets change frequently.

A README explains the project purpose, setup, usage, and contribution guidelines so newcomers can onboard quickly and follow consistent practices. It becomes the single entry point for context and helps maintain clarity as the repository evolves.

This workflow keeps work inside the same repository which simplifies permissions, keeps continuous integration and required checks centralized, and makes it easy to open pull requests for review. It encourages small, focused changes that are straightforward to test and merge.

Delete commit history to shrink the repository is not a healthy practice because it destroys traceability and can disrupt collaborators who have existing clones. It also fails to address the real source of bloat when large binaries are committed, which is better handled with Git Large File Storage.

Favor practices that prevent problems before they start. When a choice suggests rewriting or deleting history, look for alternatives that improve collaboration and clarity such as clear documentation and structured branching workflows.

The correct option is To avoid accidental use of an obsolete branch and to signal that the work is complete.

In GitHub Flow you keep feature branches short lived and remove them after they are merged and the release is stable. Deleting the merged branch keeps the list of branches clean, reduces the chance that someone continues work on an outdated branch by mistake, and clearly communicates that the feature has shipped. The commits remain in the main branch and in the pull request record, so no history is lost.

To prevent all future merge conflicts related to the feature is incorrect because deleting a branch does not influence how future changes interact. Merge conflicts happen when changes overlap in the same parts of the code and they can still occur regardless of branch deletion.

To speed up git clone and fetch by shrinking repository history is incorrect because removing a branch reference does not delete commits from the repository. Clones and fetches transfer objects from the commit graph which are unchanged after a feature branch is merged and only the reference is removed.

To speed up Google Cloud Build pipelines for subsequent commits is incorrect because pipeline performance depends on the code and the pipeline configuration rather than on the presence of old merged branch references. Removing a branch does not make builds run faster.

When branch deletion appears in answers, favor workflow clarity and communication benefits over claims about performance or history size since deleting a merged branch does not change the commit history.

The correct option is An outside collaborator cannot be added to any team in the organization.

Teams are an organization feature that group members for permission management and notifications. Outside collaborators are not organization members, so they cannot be placed on teams and must receive repository access directly. This is the key limitation that fits the scenario of giving time-bound access to a single private repository.

An outside collaborator is not required to enable two factor authentication when the organization enforces it is incorrect. When an organization requires two factor authentication, members and outside collaborators must enable it or they lose access to the organization and its repositories.

An outside collaborator can view every team and the full list of members in the organization is incorrect. Outside collaborators are not members and cannot browse organization teams, and they cannot see the full member roster. At most they can see public information such as members who have chosen to make their membership public.

An outside collaborator can @mention any visible team in issues and pull requests is incorrect. Team visibility is limited to organization members and secret teams are hidden from everyone else. Since outside collaborators are not members they cannot see teams and their mentions will not resolve or notify the team.

When a question mentions an outside collaborator, ask whether the capability relies on organization membership or team membership. If it does then the outside collaborator cannot do it.

Use GitHub practice exams on Udemy and certificationexams.pro to help you prepare.

The correct option is 3 MB.

GitHub enforces a maximum CODEOWNERS file size at this value and files that exceed it are ignored. Keeping the file under the limit ensures it loads in the web interface and that code owner review requests are triggered automatically.

5 MB is incorrect because it is above the documented maximum and a file that large would not be processed.

1 MB is incorrect because the platform allows a larger file for CODEOWNERS and this would underestimate the limit.

2 MB is incorrect because the actual limit is higher and choosing this would be more restrictive than necessary.

When a question asks for a specific size, tie it to the described behavior and confirm the exact number from official documentation. For CODEOWNERS remember that files over the limit are ignored, which explains why staying under it keeps reviews automatic.

The correct options are The same repository that contains the calling workflow, A public repository when organizational policy permits use of public reusable workflows, and A private repository that has been configured to allow access for reuse.

Calling from the same repository that contains the calling workflow is straightforward because the reusable workflow file lives in the same codebase and is enabled with the workflow_call trigger. You reference it by path and ref and GitHub enforces access within the repository boundary.

You can also call from a public repository when organizational policy permits use of public reusable workflows. This requires the organization or enterprise settings to allow actions and reusable workflows from public repositories. When permitted, you reference the workflow by owner and repository and ref and GitHub enforces the policy and permission checks.

It is additionally possible to call from a private repository that has been configured to allow access for reuse. The called private repository must explicitly grant access for reuse to the requesting repositories or to the organization scope. With that configuration in place, the caller can reference the reusable workflow and GitHub honors the access controls and token permissions.

A Docker container image hosted on Docker Hub is not a valid source for a reusable workflow because workflows must reside in GitHub repositories under the .github/workflows directory and be invoked with workflow_call. A container image can host an action implementation but it does not host a reusable workflow.

Confirm whether the option points to a repository location that GitHub can enforce with workflow_call. If an option mentions registries or container images it is about actions rather than workflows. Watch for organization policy and explicit access configuration for private repositories.

The correct option is Adopting open source style collaboration and transparency within the company.

This approach describes InnerSource because it brings open source practices into a private organization. Work is visible by default and repositories are discoverable across teams. Contribution guidelines invite participation from colleagues in other groups and code review and discussion happen in the open within the company. This fosters reuse and reduces silos as anyone can propose improvements and consume shared components.

Using a private hosted Git platform describes an infrastructure choice rather than a collaborative practice. You can host code privately and still work in isolation, which does not achieve InnerSource goals.

Implementing Scrum or Kanban practices to manage sprints is about agile delivery cadence and workflow. InnerSource is about cross team transparency and contribution norms rather than sprint management.

Running closed development that keeps code limited to the originating team is the opposite of InnerSource because it restricts visibility and prevents broad contribution and reuse.

When you see InnerSource, map it to open collaboration and transparency inside the company and rule out answers that only mention tools or agile rituals without cross team contribution.

The correct options are Leverage appropriate field types such as iteration, single select, and date to model work, Keep the project description, README, and status updates current to share context, Split large issues into smaller issues so work can progress in parallel, Maintain a single source of truth for key information so details do not diverge, and Use @mentions to notify specific teammates or groups in comments and discussions.

Leverage appropriate field types such as iteration, single select, and date to model work because purpose built fields capture schedule, categorization, and timelines in a structured way. This enables reliable filtering, views, automation, and reporting so the project board reflects real planning artifacts rather than unstructured notes.

Keep the project description, README, and status updates current to share context because these surfaces communicate goals, scope, and changes to everyone without requiring meetings. When combined with Maintain a single source of truth for key information so details do not diverge the team avoids duplication and drift as stakeholders can trust one canonical place for objectives, definitions, and links.

Split large issues into smaller issues so work can progress in parallel because breaking down work clarifies ownership and acceptance criteria, reduces coordination overhead, and allows independent pull requests that merge sooner. This leads to faster feedback and more predictable throughput.

Use @mentions to notify specific teammates or groups in comments and discussions because explicit notifications route questions and decisions to the right people, which improves responsiveness and accountability while keeping the conversation discoverable on GitHub.

Prefer ad hoc email threads over issues and pull requests for coordination is incorrect because email fragments context, is not easily searchable, and lacks linked history with code and reviews. GitHub issues, pull requests, and discussions keep decisions transparent and auditable in the same system where the work happens.

Look for practices that increase transparency, keep information in a single authoritative place, and use GitHub features to coordinate work. Eliminate options that move collaboration into private or unsearchable channels.

The correct option is The repository owner and any collaborator who holds Write permissions.

This is correct because enabling a community feature for a repository can be done by the people responsible for managing that repository and by collaborators who have sufficient contribution privileges. Those with write access are trusted to help configure collaboration features for the project, so they can turn on Discussions to support communication and Q and A threads within the repository.

Organization owners only is incorrect because the scope is too limited. Control over repository features is not restricted to organization owners when the repository owner and collaborators with appropriate permissions can manage these settings for that specific project.

Any authenticated user who can view the repository is incorrect because viewing access does not grant rights to change repository settings. Only trusted collaborators or the repository owner can enable features like Discussions.

Collaborators with Triage permissions is incorrect because triage access is intended for issue and pull request management without write access to the repository’s configuration. Triage collaborators cannot enable repository features.

When a question asks who can configure a repository feature, map verbs like enable, configure, or manage to the minimum permission level that allows changes, rather than to general viewing or triage roles.

The correct options are Convert an existing repository into a template repository and Create a new repository from a template repository.

GitHub allows you to mark an existing repository as a template in the repository settings. This turns the project into a reusable starting point so teams can generate consistent repositories without copying by hand. From that template, you can generate a brand new repository that copies the directory structure and files which accelerates onboarding and keeps layouts consistent across teams.

Delete all repositories that originated from a specific repository template in a single step is not supported because GitHub does not provide a bulk deletion feature tied to template lineage. You would have to remove repositories individually or automate this with scripts or the API.

Create a new organization from a repository template is not possible because templates apply to repositories only. They do not create or configure organizations.

Remove every repository in the organization that does not use an approved template is not a supported action. GitHub does not offer an automatic cleanup or enforcement feature that deletes nonconforming repositories across an organization.

Scan for actions that GitHub exposes directly in the repository settings or on the repository home page. Be skeptical of options that imply bulk deletion or organization wide enforcement since these are not typical capabilities of repository templates.

The correct option is A web based service that hosts Git repositories and adds collaboration tools such as pull requests and issues.

GitHub is a hosted platform built on top of Git that stores repositories and provides a web interface for collaboration. Teams use it to review code through pull requests, discuss work through issues, and manage workflows and permissions. It is not a replacement for Git because it uses Git for version control and then adds hosting and collaboration capabilities.

Cloud Source Repositories is a Google Cloud product that hosted Git repositories but it is not GitHub. This service has been retired by Google which makes it less likely to be a viable choice on newer exams.

A code editor is a local tool used to write and edit code, which does not describe GitHub. GitHub is a hosted service that provides repository hosting and collaboration features rather than being an editor.

A version control system describes Git rather than GitHub. GitHub uses Git for version control and adds web based hosting and collaboration features on top.

When options mix Git and GitHub language, map the keywords to their roles. Git is the version control system while GitHub is the hosted platform that adds collaboration features like pull requests and issues.

The correct option is Basic username and password sign in.

This method is weak for protecting highly confidential code because it cannot be scoped to specific resources and it is hard to rotate and audit. GitHub has deprecated the use of account passwords for Git and API operations and has required stronger non password credentials for these workflows. Attackers can more easily phish or reuse passwords, so sensitive automation and developer actions should avoid this method and use credentials that support least privilege, rotation, and revocation.

Deploy keys are appropriate for automation on a single repository and can be configured as read only or with write access. They use SSH which is a stronger approach for machine access and can be rotated and audited.

Personal access tokens are the supported replacement for passwords. Fine grained tokens can be limited to specific repositories and permissions and can have expirations, which makes them suitable for sensitive workflows when managed with least privilege.

SSH keys provide strong cryptographic authentication and are well suited for developer access and automation when protected with a passphrase and proper key management. They are widely recommended over passwords for secure Git operations.

When you see both password sign in and token or SSH options, favor scoped and revocable credentials and avoid passwords for sensitive repositories. The word deprecated is a strong hint to steer away from that choice.

The correct options are Any public repository, The same repository as the workflow file, and A published Docker container image on Docker Hub.

For Any public repository, GitHub Actions supports referencing actions that are hosted in publicly accessible repositories. A workflow can use the uses key with the owner and repository plus a specific version to pull and run the action from this location.

For The same repository as the workflow file, teams can keep action code in the same repository and reference it with a relative path using the uses key. This makes versioning and updates straightforward within the same codebase and does not require a separate repository.

For A published Docker container image on Docker Hub, workflows can run a container action by pointing the uses key to a published image using the docker scheme. This lets teams reuse a containerized action that is hosted there without storing action code in a repository.

The option Google Artifact Registry is not a supported source for reusable actions with the uses key. While you can authenticate to and pull images from that registry in custom steps, GitHub Actions does not treat it as a first class location for actions that workflows can reference directly.

When you see a question about where actions can live, map options to the three supported sources which are a public repository, the same repository, and a Docker Hub image. Vendor specific artifact registries are usually distractors.

The correct option is An organization account supports multiple owners and members whereas a personal account is associated with one individual.

GitHub organizations are shared accounts that let teams manage projects together. They support multiple owners and members with roles and permissions. A personal account identifies a single user and represents only that individual. This matches how GitHub structures collaboration and access control.

The statement Only personal accounts support SSH key authentication while organization accounts only allow password sign in is incorrect because authentication happens through individual user accounts and SSH is fully supported for users regardless of whether they work in or outside organizations. Organizations themselves do not sign in as an entity. GitHub also does not allow account passwords for Git operations over HTTPS and requires personal access tokens or SSH.

The statement An organization account can only be created if you purchase GitHub Enterprise Cloud is incorrect because anyone can create an organization on GitHub Free or on paid plans and Enterprise Cloud is optional.

The statement Only organization accounts can own repositories and personal accounts cannot create repositories is incorrect because both user accounts and organizations can own repositories. Individuals can create repositories under their personal account and teams can create repositories under an organization.

Focus on ownership and membership when comparing GitHub account types. Authentication is tied to the user and not to the organization.

Use GitHub practice exams on Udemy and certificationexams.pro to help you prepare.

The correct answer is Discovering and installing free and paid apps and actions that add capabilities to GitHub workflows.

GitHub Marketplace exists to help teams find vetted integrations and add them to their repositories. It lets you browse free and paid GitHub Apps and GitHub Actions and install them to enhance automation, continuous integration and delivery, code quality, security scanning, and project management. Billing and permissions are integrated with GitHub so teams can adopt tools quickly and manage them centrally.

The option Providing customer support for GitHub accounts is incorrect because account and billing support is handled by GitHub Support and the Help portal rather than by the marketplace.

The option Connecting developers with potential employers and partner organizations is incorrect because the marketplace is not a recruitment or networking service and it focuses on technical integrations that extend repositories and workflows.

The option Publishing and monetizing solutions on Google Cloud Marketplace is incorrect because that is a different vendor platform and it is unrelated to GitHub Marketplace.

When a question asks for the main purpose of a service, match the primary function in the option text to the product. For GitHub Marketplace, look for apps, actions, discover, install, and workflows rather than support or hiring.

The correct option is Manually one by one, with automation rules, or by importing many items together.

GitHub Projects lets you add issues and pull requests directly from the project interface when you want to curate items individually. You can also configure built in project automation so that items are added automatically based on rules like repository, filters, or events which keeps your board up to date without constant manual work. When you need to seed or update a board with many items at once you can bulk add from search or import via CSV to bring in a large set efficiently.

The statement Only by using the GitHub CLI is incorrect because the web interface supports manual addition, built in automation can auto add items, and bulk import is available.

The statement Only through automated project workflows such as GitHub Actions is incorrect because you can add items manually in the project and you can also import many at once without relying on Actions.

The statement Only by adding one item at a time manually is incorrect because you can use automation to add items automatically and you can perform bulk imports when needed.

Watch for absolute words like only or always. For intake questions remember that platforms often support a mix of manual steps, built in automation, and bulk import.

The correct option is GitHub is a hosted platform built around Git that adds collaboration and code management capabilities.

This description is accurate because GitHub hosts Git repositories and provides collaboration features such as pull requests, issues, code review, permissions, project boards, and wikis. It also integrates automation and package management, which extends the core version control provided by Git with a complete platform for team workflows.

GitHub is primarily a continuous integration and delivery tool is incorrect because CI and CD are features offered through GitHub Actions while the service itself is a broader platform for hosting Git repositories and enabling collaboration.

GitHub is a distributed version control system is incorrect because Git is the distributed version control system while GitHub is the platform built on top of Git that provides hosting and collaboration features.

GitHub is a file sharing site that relies on centralized version control is incorrect because GitHub is not a simple file sharing site and it uses Git which is a distributed model rather than a centralized one.

Distinguish the platform from the underlying tool. If a statement says the product is the DVCS it points to Git, while if it says it adds collaboration to Git it points to GitHub. Watch for words like primarily that often indicate a trap.

The correct option is Use a single shared repository and open pull requests from feature branches.

This shared repository with pull requests from feature branches keeps all work in one place and supports a clean review process. Each engineer works on a feature branch and opens a pull request so teammates can review changes and automated checks can run before merge. This helps a small team iterate daily while keeping history organized and the default branch stable.

Branch protection and required reviews work best with this feature branch pull request model. It simplifies permissions and reduces coordination overhead while preserving a clear source of truth.

Have each developer fork the repository and submit pull requests across repositories spreads changes across separate repositories and introduces extra steps to keep forks synchronized. That model is better for external contributors rather than a small team that wants centralized collaboration.

Create a separate Git submodule for each contributor misapplies submodules since they are intended for including independent projects as dependencies. It increases complexity and does not improve collaboration or reviews within one repository.

Commit straight to the default branch without creating branches bypasses peer review and automated checks and increases the risk of breaking the main line. It does not meet the requirement for a straightforward workflow that supports code review.

When you see hints like centralized work and code review for a small team choose a shared repository with feature branches and pull requests. Reserve forks for external contributors and avoid submodules for people.

The correct option is It condenses every commit from the pull request into a single commit and merges that into the target branch.

This choice takes all commits from the pull request and combines them into one commit that is added to the target branch. It keeps the history linear and avoids creating a merge commit with two parents. The individual commits from the feature branch are not preserved on the base branch and the pull request is then marked as merged.

It integrates the pull request using a fast-forward so no merge commit is created is incorrect because a fast forward preserves all original commits and simply moves the branch pointer, while a squash merge creates a brand new single commit that replaces the series of commits in the base branch.

It bypasses required reviews so changes can land directly in the main branch is incorrect because required reviews and other protections are enforced by branch protection rules and the merge method does not override those requirements.

It drops all commits from the pull request and leaves the default branch unchanged is incorrect because squash merging does not discard the work. It adds one new commit to the target branch that contains the combined changes.

Map each merge method to its effect on history. Remember that squash produces a single commit, merge commit preserves all commits with a merge commit, and rebase reapplies commits onto the base branch. Requirements like branch protection and reviews are enforced regardless of the merge method.