GitHub GH-900 Sample Questions with Explanations

These original sample questions are designed to help you check how the exam topics appear in decision-style prompts. They are not taken from the live exam.

Use these sample questions as a guided self-assessment for GitHub Foundations (GH-900) topics such as repositories, branches, commits, pull requests, issues, projects, permissions, account security, GitHub Actions awareness, and collaboration workflow. The prompts focus on choosing the right GitHub object or control for a realistic team situation.

Where these questions fit in the GH-900 guide

The sample set below is part of the GitHub Foundations GH-900 guide path:

• GitHub certification hub
• GH-900 exam guide
• GH-900 cheat sheet
• GH-900 study plan
• GH-900 FAQ
• GH-900 resources
• GH-900 glossary

GH-900 collaboration sample questions

Work through each prompt before opening the explanation. Foundations questions usually test whether you choose the right collaboration feature and protect the workflow without over-engineering it.

---

Question 1

Topic: Reviewing a change before merge

A developer has finished a small feature on a branch. The team wants discussion, code review, automated checks, and a visible record before the change reaches the default branch. Which GitHub feature best fits?

• A. Create a new repository for the feature and copy files into the original repository later.
• B. Create a pull request from the feature branch into the default branch.
• C. Open an issue and paste the changed code into the issue body.
• D. Upload a compressed archive of the branch to the repository’s releases page.

Best answer: B

Explanation: A pull request is the collaboration object for reviewing branch changes before merge. It supports discussion, review comments, checks, merge decisions, and a durable record of what changed.

Why the other choices are weaker:

• A fragments history and bypasses the normal branch-based review flow.
• C can track work, but issues are not the primary object for reviewing a concrete branch diff.
• D uses releases for packaging, not pre-merge collaboration.

What this tests: Pull request purpose, branch workflow, code review, and checks.

Related topics: Pull requests; Branches; Reviews; Status checks

---

Question 2

Topic: Tracking work without changing code

A product team wants to track a bug report, assign an owner, add labels, discuss reproduction steps, and link the eventual code fix. What should they create first?

• A. A release, because every bug should be tracked as a release artifact.
• B. A branch protection rule, because it stores bug metadata.
• C. An issue, then link the fixing pull request when code changes are ready.
• D. A repository secret, because it can hold reproduction details privately.

Best answer: C

Explanation: Issues are built for tracking work, discussion, labels, assignment, and linking to pull requests. The code fix can come later in a branch and pull request.

Why the other choices are weaker:

• A packages completed software; it does not manage the investigation workflow.
• B controls merge policy but does not track bug context.
• D stores sensitive values for workflows, not bug reports.

What this tests: Choosing between issues, pull requests, releases, and repository settings.

Related topics: Issues; Labels; Assignment; Work tracking

---

Question 3

Topic: Protecting a repository secret

A beginner adds an API key to a public repository by mistake. The team removes the line from the newest commit. What should they do next to reduce risk?

• A. Rename the repository so the old key is no longer searchable.
• B. Leave the key unchanged because the newest file no longer contains it.
• C. Move the key into a README note so other contributors know not to use it.
• D. Revoke or rotate the exposed key, then review repository history and any related alerts.

Best answer: D

Explanation: Removing a secret from the latest file is not enough because it may still exist in history, forks, caches, or logs. The safer response is to revoke or rotate the credential and then investigate exposure.

Why the other choices are weaker:

• A does not invalidate the leaked credential.
• B ignores repository history and possible external discovery.
• C exposes the secret again and treats documentation as a control.

What this tests: Secret exposure response, repository history, and account-security basics.

Related topics: Secrets; Repository history; Credential rotation; Security basics

Independent study note

Tech Exam Lexicon and IT Mastery are independent study tools. They are not affiliated with, endorsed by, or sponsored by GitHub or any certification body.