Free GH-900 Practice Questions

The GH-900 (GitHub Foundations) certification validates your understanding of GitHub's core features — from Git basics and repository management to collaborative workflows, GitHub Actions for automation, and security best practices. It's ideal for developers, DevOps engineers, and project managers using GitHub.

These 25 questions cover Git fundamentals, GitHub-specific features, collaboration workflows, Actions and CI/CD, and security/administration. Check our GH-900 study guide for the complete exam breakdown and study resources.

What You'll Get:

✓25 scenario-based questions across all exam domains
✓Git command questions — same format as the real exam
✓Detailed explanations for every answer option
✓Scoring guide to assess your readiness

What These Questions Cover

Git & GitHub Fundamentals

Repos, branches, commits, merging, Git commands

Collaboration & Projects

Pull requests, Issues, Discussions, GitHub Projects

Actions, Security & Admin

GitHub Actions, Copilot, security features, admin

📝 Practice Test Instructions

• Each question has ONE correct answer
• Git command questions — read the scenario context carefully
• Note your answers before scrolling to the answer key
• Aim to complete all 25 questions in 25 minutes

⚙️

Git & GitHub Fundamentals

Questions 1–8

Git vs GitHub

A developer explains to their team: "Git and GitHub are not the same thing — you can use Git without GitHub."

Which statement BEST describes the relationship between Git and GitHub?

A)Git is the distributed version control system; GitHub is a cloud-based hosting platform for Git repositories with collaboration features

B)GitHub is a replacement for Git — you use one or the other

C)Git is a GitHub product owned by Microsoft

D)GitHub is required to use Git for version control

Git Branching

A team is working on a new payment feature. The developer wants to work on the feature without affecting the main production code. They want to create an isolated copy of the codebase to work in.

What should the developer do?

A)Fork the repository

B)Create a new branch from main

C)Clone the repository to a new folder

D)Create a new commit on main with the feature code

Git Commit

A developer has made changes to three files: index.html, styles.css, and app.js. They want to save only the changes to index.html and app.js to version control, leaving styles.css uncommitted.

What is the correct sequence of Git commands?

A)git commit -m "message" then git push

B)git push then git commit

C)git add index.html app.js then git commit -m "message"

D)git status then git push -a

Git Merge vs Rebase

A developer has a feature branch with 5 commits. They want to integrate the latest changes from the main branch into their feature branch while maintaining a cleaner, linear commit history.

Which Git operation creates a linear history by replaying commits on top of the updated main branch?

A)git merge main

B)git fetch main

C)git cherry-pick main

D)git rebase main

git clone vs fork

You want to contribute to an open-source project on GitHub that you do not have write access to. You want to make changes and propose them to the project maintainers.

What is the correct approach?

A)Fork the repository to your account, clone your fork, make changes, push to your fork, then open a pull request to the original repo

B)git clone the repo, make changes, and push directly to the original repo

C)Create a branch in the original repository and push your changes

D)Download the ZIP file, make changes, and submit via email

git stash

A developer is working on a feature and has uncommitted changes. An urgent bug report comes in and they need to switch to the main branch immediately to fix it, without committing their incomplete work.

Which Git command temporarily shelves the current uncommitted changes?

A)git reset

B)git stash

C)git checkout -b bugfix

D)git commit --no-message

Pull vs Fetch

A developer wants to download the latest changes from the remote origin repository to review them BEFORE merging them into their local branch.

Which command downloads remote changes without automatically merging?

A)git pull

B)git sync

C)git fetch

D)git remote update --all

.gitignore

A developer accidentally committed their .env file containing database passwords to a GitHub repository. They want to prevent this from happening again for all future .env files in the project.

What should they add to the .gitignore file?

A)exclude .env

B)# .env

C)ignore: .env

D).env

🤝

Collaboration Features

Questions 9–17

Pull Requests

A developer has completed a feature on a branch. They want the code to be reviewed by team members and discussed before it is merged into the main branch. The process should create a trackable record of the code review discussion.

What GitHub feature should they create?

A)A Pull Request (PR)

B)A GitHub Issue

C)A GitHub Discussion

D)A commit with a detailed message

Code Review — PR Review Types

A reviewer looks at a pull request and has a blocking concern — the code will introduce a security vulnerability. The reviewer wants to formally block the PR from being merged until the issue is addressed.

Which PR review action should the reviewer submit?

A)Comment

B)Request changes

C)Approve

D)Close the PR

Branch Protection Rules

Your team wants to enforce that no one can push directly to the main branch. All changes must come through pull requests with at least 2 reviewers approving, and all CI checks must pass before merging.

Which GitHub feature enforces these merge requirements?

A)GitHub Issues with labels

B)A CODEOWNERS file

C)Branch protection rules on the main branch

D)Repository rulesets

GitHub Issues

A software team wants to track bug reports, feature requests, and technical tasks. They need each item to be assignable to team members, labeled by category (bug, enhancement, documentation), and linked to pull requests.

Which GitHub feature is designed for this project tracking?

A)GitHub Discussions

B)GitHub Milestones

C)GitHub Projects

D)GitHub Issues

GitHub Discussions

An open-source project wants a space where community members can ask general questions, share ideas, announce releases, and have threaded conversations that are separate from bug reports and feature requests.

Which GitHub feature is best suited for this community communication?

A)GitHub Discussions

B)GitHub Issues

C)GitHub Wiki

D)README.md comments

CODEOWNERS

Your repository has a microservices architecture. The team wants to automatically require review from the backend team when changes are made to the /api directory and from the frontend team for changes to the /ui directory.

What should you create?

A)Branch protection rules with required reviewers

B)A CODEOWNERS file in the repository root

C)Individual PR review assignments

D)Repository teams with write access

GitHub Projects

A product team wants to visualize their sprint backlog, track which issues are in progress vs done, and see a roadmap view of upcoming features — all connected to their GitHub Issues.

Which GitHub feature provides this project management with multiple views?

A)GitHub Issues milestones

B)GitHub Discussions

C)GitHub Projects (project boards with table, board, and roadmap views)

D)Repository Insights

Merge Strategies

Your team wants every feature branch merge into main to result in a single, clean commit rather than bringing all the feature branch's individual commits into the main history. This keeps the main branch history clean and readable.

Which merge strategy achieves this?

A)Create a merge commit

B)Fast-forward merge

C)Rebase and merge

D)Squash and merge

GitHub Releases

After completing a sprint, a team wants to package version 2.1.0 of their application, attach compiled binaries, write release notes documenting what changed, and make it publicly available for download.

Which GitHub feature is designed for distributing versioned software packages?

A)GitHub Releases

B)GitHub Packages

C)GitHub Pages

D)A tagged commit with a README

🔒

Actions, Security & Administration

Questions 18–25

GitHub Actions — Basics

A development team wants to automatically run their test suite every time a pull request is opened against the main branch, and automatically deploy to staging when code is merged to main.

Which GitHub feature enables these automated CI/CD workflows?

A)GitHub Pages

B)GitHub Actions

C)GitHub Packages

D)GitHub Apps

GitHub Actions — Triggers

You are writing a GitHub Actions workflow. You want it to run automatically whenever a push is made to the main branch OR when a pull request is opened targeting the main branch.

Which YAML trigger configuration is correct?

A)on: [push, pull_request]

B)trigger: push to main OR pull_request to main

C)on: push: branches: [main] pull_request: branches: [main]

D)when: push(main) or pr(main)

GitHub Actions — Secrets

Your GitHub Actions workflow needs to authenticate to an external cloud service using an API key. The API key must not be visible in the workflow YAML file or in the workflow run logs.

How should you store and reference the API key?

A)Store it as a plain text environment variable in the YAML file

B)Store it in a .env file committed to the repository

C)Hardcode it in the workflow file and restrict repository access

D)Store it as a GitHub Actions Secret and reference it with ${{ secrets.API_KEY }}

GitHub Copilot

A developer is writing a function and wants AI-powered code suggestions that appear inline in their editor as they type, completing lines and suggesting entire functions based on context.

Which GitHub feature provides these real-time inline code suggestions in the IDE?

A)GitHub Copilot

B)GitHub Codespaces

C)GitHub Actions

D)GitHub Code Search

Dependabot

Your repository uses open-source npm packages. You want GitHub to automatically alert you when any of your dependencies has a known security vulnerability and to automatically open pull requests to update them to safe versions.

Which GitHub security feature provides automated dependency vulnerability alerts and update PRs?

A)GitHub Advanced Security — Code Scanning

B)Dependabot alerts and Dependabot security updates

C)GitHub Secret Scanning

D)GitHub Actions with npm audit

Secret Scanning

A developer accidentally pushed a GitHub Personal Access Token to a public repository. Within minutes, the token was invalidated and they received an email notification about the exposure.

Which GitHub security feature detected and alerted on this exposed token?

A)Dependabot alerts

B)Code Scanning with CodeQL

C)Secret Scanning

D)Branch protection rules

GitHub Codespaces

A developer joins a new team and needs to start contributing code. Instead of spending hours setting up their local development environment (installing dependencies, configuring tools, etc.), they want a fully configured development environment available immediately in their browser.

Which GitHub feature provides a cloud-hosted development environment configured for the repository?

A)GitHub Actions

B)GitHub Dev (github.dev)

C)GitHub Pages

D)GitHub Codespaces

Repository Visibility

A company wants to host their proprietary source code on GitHub where only members of their GitHub organization can access it. The code must not be visible to the public or to other GitHub users outside their organization.

Which repository visibility setting should they choose?

A)Private

B)Public

C)Internal (GitHub Enterprise)

D)Restricted

✋ Stop Here Before Scrolling!

Have you answered all 25 questions? Complete the test before checking the answers below.

Pro tip: The GH-900 exam tests practical GitHub knowledge — hands-on practice in a real GitHub repo helps significantly

📝 Answer Key with Detailed Explanations

Review each explanation carefully, even for questions you answered correctly

Quick Answer Reference

Q10

Q11

Q12

Q13

Q14

Q15

Q16

Q17

Q18

Q19

Q20

Q21

Q22

Q23

Q24

Q25

Question 1: Git vs GitHub

✓ Correct Answer: A) Git is the distributed version control system; GitHub is a cloud-based hosting platform for Git repositories with collaboration features

Why this is correct:

Git is open-source software for tracking file changes (version control), created by Linus Torvalds in 2005. It runs locally on your machine. GitHub is a cloud platform that hosts Git repositories and adds collaboration features: pull requests, issues, Actions, Copilot, Projects, etc. Git works without GitHub; GitHub requires Git.

Why other answers are incorrect:

B: They are complementary, not alternatives. You use Git WITH GitHub, not instead of it.

C: Git was created by Linus Torvalds, not GitHub or Microsoft. GitHub (and Git) were later acquired by Microsoft in 2018.

D: Git is a standalone tool that works with many hosting services (GitLab, Bitbucket, Azure DevOps, or self-hosted) and works entirely locally without any hosting service.

💡 Key Concept:

Git = version control tool (local/distributed). GitHub = hosting + collaboration platform. Other Git hosts: GitLab, Bitbucket, Azure DevOps. Git commands (commit, push, pull) work the same regardless of the hosting platform.

Question 2: Git Branching

✓ Correct Answer: B) Create a new branch from main

Why this is correct:

Branches in Git create an isolated copy of the codebase at a point in time. Changes on a branch don't affect other branches until you explicitly merge them. Creating a feature branch is the standard workflow — work in isolation, merge back when done.

Why other answers are incorrect:

A: Forking creates a copy of the entire repository in a different account/organization — it's for external contributors, not for internal feature development.

C: Cloning to a new folder creates a second complete copy of the entire repo on your machine — not the right tool for feature isolation.

D: Committing to main directly is the exact problem branches solve — it affects production code immediately.

💡 Key Concept:

Branch naming conventions: feature/payment-integration, bugfix/login-error, hotfix/security-patch, release/v2.0. Branches are lightweight in Git — creating them is instant and free.

Question 3: Git Commit

✓ Correct Answer: C) git add index.html app.js then git commit -m "message"

Why this is correct:

Git's staging area (index) lets you select exactly which changes to include in a commit. "git add" moves files from working directory to staging. "git commit" saves staged changes to history. By adding only index.html and app.js, styles.css remains unstaged and excluded from the commit.

Why other answers are incorrect:

A: git commit without git add first commits only previously staged changes (or nothing if nothing is staged).

B: git push sends commits to remote — it doesn't create commits. You must commit before you can push.

D: git push -a is not a valid command. "git status" shows state but doesn't stage or commit.

💡 Key Concept:

Git workflow: Edit files (working directory) → git add (staging area) → git commit (local repo) → git push (remote repo). git add . stages ALL changes. git add -p stages changes interactively, hunk by hunk.

Question 4: Git Merge vs Rebase

✓ Correct Answer: D) git rebase main

Why this is correct:

Rebase replays your branch's commits on top of the updated main branch tip, creating a linear history as if your feature was developed from the latest main. The result is a clean, linear commit history without merge commits. "git merge main" creates a merge commit that shows both histories converging.

Why other answers are incorrect:

A: git merge main incorporates main's changes but creates a non-linear history with a merge commit — the question asks for linear history.

B: git fetch downloads remote changes but doesn't integrate them into your branch — it doesn't update the local branch at all.

C: git cherry-pick applies individual specific commits from one branch to another — not for integrating all of main's changes.

💡 Key Concept:

Merge vs Rebase: Merge = non-destructive, preserves history, creates merge commit. Rebase = rewrites history, creates linear commits, cleaner log. Golden rule: never rebase public/shared branches (changes commit SHAs, breaks others' history).

Question 5: Fork and Pull Request

✓ Correct Answer: A) Fork the repository to your account, clone your fork, make changes, push to your fork, then open a pull request to the original repo

Why this is correct:

This is the standard open-source contribution workflow. Forking creates your own copy of the repo where you have write access. You make changes in your fork and propose them back to the original via a pull request, which the maintainers can review and accept or decline.

Why other answers are incorrect:

B: Without write access to the original repo, you cannot push directly to it — this would fail with a permission error.

C: Creating branches in the original repo requires write (or collaborate) access to that repo — you don't have it.

D: Submitting via email is not the GitHub contribution workflow — pull requests provide trackable, reviewable code contributions.

💡 Key Concept:

Fork vs Clone: Fork = copy of a repo in your GitHub account (on GitHub servers, for contributing to repos you don't own). Clone = copy of a repo on your local machine (for working on it). You typically fork then clone your fork.

Question 6: git stash

✓ Correct Answer: B) git stash

Why this is correct:

git stash saves your uncommitted changes (both staged and unstaged) to a stash stack and reverts your working directory to the last commit (HEAD). You can then switch branches freely. To restore the stashed changes later, use "git stash pop" (apply + remove from stash) or "git stash apply" (apply but keep in stash).

Why other answers are incorrect:

A: git reset moves the HEAD pointer — "git reset HEAD" unstages staged changes; "git reset --hard" discards changes permanently. Neither saves the work for later.

C: git checkout -b creates a new branch but doesn't help if you have conflicting uncommitted changes.

D: "git commit --no-message" is not a valid command — and committing incomplete work to avoid the issue is bad practice.

💡 Key Concept:

git stash commands: git stash (save), git stash list (see all), git stash pop (restore latest, delete from stash), git stash apply (restore, keep in stash), git stash drop (delete without applying), git stash show (preview).

Question 7: git fetch vs git pull

✓ Correct Answer: C) git fetch

Why this is correct:

git fetch downloads objects and refs from the remote repository to your local repo but does NOT merge them into your current branch. You can then inspect the fetched changes (git log origin/main) and decide when/how to merge. git pull = git fetch + git merge (or git fetch + git rebase with --rebase flag).

Why other answers are incorrect:

A: git pull downloads AND automatically merges remote changes into your current branch — the question asks to review before merging.

B: git sync is not a standard Git command.

D: git remote update is similar to git fetch --all (fetches from all remotes) but is less commonly used.

💡 Key Concept:

Workflow: git fetch → git log origin/main (review changes) → git merge origin/main (merge when ready). Or just git pull if you trust the remote. Use git fetch when you want to see what changed before integrating.

Question 8: .gitignore

✓ Correct Answer: D) .env

Why this is correct:

In .gitignore, each line specifies a pattern to ignore. ".env" exactly matches a file named .env in the repository root. The file extension alone (without a path) matches any file named .env in any subdirectory too.

Why other answers are incorrect:

A: "exclude .env" is not valid .gitignore syntax — there is no "exclude" keyword.

B: "# .env" makes it a comment — the # character starts a comment in .gitignore and the pattern is ignored (the file would NOT be ignored by Git).

C: "ignore: .env" is not valid — .gitignore uses patterns directly, not key-value pairs.

💡 Key Concept:

.gitignore patterns: *.log (all .log files), /build (only root build dir), build/ (any dir named build), **/*.tmp (all .tmp files recursively), !important.log (negate — DO track this file). Committed secrets require rotating the credentials — removing from .gitignore doesn't erase them from git history.

Question 9: Pull Requests

✓ Correct Answer: A) A Pull Request (PR)

Why this is correct:

Pull Requests (PRs) are the GitHub mechanism for proposing code changes. They create a discussion space where team members can review the diff, leave line-by-line comments, request changes, approve, and ultimately merge. PRs create a permanent record of why changes were made.

Why other answers are incorrect:

B: Issues track bugs and feature requests — they don't contain code changes for review.

C: Discussions are for open-ended conversations and community communication — not structured code review with merge capability.

D: A detailed commit message documents the commit but doesn't create a reviewable, discussable proposal — it's part of a PR, not a replacement.

💡 Key Concept:

PR lifecycle: Branch → Push → Open PR → CI checks run → Code review → Requested changes → Revised → Approved → Merged → Branch deleted. Draft PRs allow work-in-progress sharing without requesting review.

Question 10: PR Review Types

✓ Correct Answer: B) Request changes

Why this is correct:

"Request changes" is the GitHub review action that formally blocks a PR from being merged (when branch protection requires reviews with no pending change requests). It signals that the reviewer found issues that MUST be addressed before merging. The PR author must resolve and re-request review.

Why other answers are incorrect:

A: Comment adds feedback without formally approving or blocking — the PR can still be merged if other requirements are met.

C: Approve indicates the reviewer is satisfied and the code is ready to merge — wrong action for a blocking security issue.

D: Closing the PR is a final action (often done by the PR author or maintainers) — reviewers typically don't close PRs, they request changes.

💡 Key Concept:

PR review states: Pending (reviewer added, hasn't submitted), Commented (feedback only), Approved (✓, ready to merge), Changes Requested (blocking until resolved, author must fix and re-request review).

Question 11: Branch Protection Rules

✓ Correct Answer: C) Branch protection rules on the main branch

Why this is correct:

Branch protection rules in GitHub Settings > Branches allow you to: require PR reviews (with minimum count), require status checks to pass before merging, restrict who can push, prevent force pushes, and require up-to-date branches. This is the standard way to enforce code quality gates.

Why other answers are incorrect:

A: Issue labels organize issues by type — they have no connection to code merging or branch access control.

B: CODEOWNERS assigns automatic reviewers based on file paths — it works within branch protection rules but doesn't configure the minimum reviewer count or CI requirements by itself.

D: Repository rulesets (the newer system replacing branch protection) are the correct modern approach — but "Branch protection rules" is the well-established feature that the exam primarily focuses on.

💡 Key Concept:

Branch protection rule options: Require PR before merging, Require status checks, Require branches to be up to date, Require signed commits, Require linear history, Restrict pushes, Block force pushes. Apply to main and release/* branches.

Question 12: GitHub Issues

✓ Correct Answer: D) GitHub Issues

Why this is correct:

GitHub Issues is the built-in issue tracking system. Each issue can be assigned to team members, labeled (bug, enhancement, documentation), linked to pull requests ("Closes #123" in a PR body auto-closes the issue on merge), organized with milestones, and tracked in GitHub Projects boards.

Why other answers are incorrect:

A: GitHub Discussions are for community Q&A and open-ended conversations — they're not designed for structured task tracking and bug reporting.

B: Milestones group issues by sprint or release version — they're a feature within issues, not a replacement for issues.

C: GitHub Projects is a project management tool that USES issues and pull requests as items — it's the board/tracker, not the individual items themselves.

💡 Key Concept:

Issue templates: Create .github/ISSUE_TEMPLATE/ with markdown files to provide forms for bug reports, feature requests, etc. Ensures issues contain the needed information (steps to reproduce, expected behavior, etc.).

Question 13: GitHub Discussions

✓ Correct Answer: A) GitHub Discussions

Why this is correct:

GitHub Discussions is the community forum feature designed for open-ended conversations, Q&A, announcements, and general community engagement. It supports categories (Q&A, Ideas, Announcements, Show and Tell), threaded replies, and the ability to mark answers as solutions.

Why other answers are incorrect:

B: Issues are for trackable bugs and tasks with clear actionable outcomes — not for general community conversations and ideas.

C: GitHub Wiki provides structured documentation pages — it's not a threaded conversation forum.

D: README.md doesn't support comments — it's a static document.

💡 Key Concept:

Issues vs Discussions: Issues = trackable work items (bug/feature, can be opened/closed, linked to PRs). Discussions = community conversations (Q&A, announcements, open-ended). Convert between them when appropriate.

Question 14: CODEOWNERS

✓ Correct Answer: B) A CODEOWNERS file in the repository root

Why this is correct:

The CODEOWNERS file (stored in root, /docs, or /.github) defines file ownership patterns and assigns GitHub users or teams as owners. When a PR modifies files matching a pattern, the code owners are automatically added as required reviewers. Syntax: `/api/ @company/backend-team`

Why other answers are incorrect:

A: Branch protection rules can require a minimum number of reviewers but can't automatically assign specific people/teams based on the files changed.

C: Manual PR review assignment is per-PR and doesn't scale to automatic file-path-based assignments.

D: Repository team write access gives them permission to push — it doesn't automatically request their review on specific file changes.

💡 Key Concept:

CODEOWNERS syntax: # comment, * @global-owner, *.js @frontend-team, /api/ @backend-team, /docs/ @tech-writers. Last matching rule wins. CODEOWNERS + branch protection with "require code owner review" = enforced ownership.

Question 15: GitHub Projects

✓ Correct Answer: C) GitHub Projects (project boards with table, board, and roadmap views)

Why this is correct:

GitHub Projects (Projects V2) is a flexible project management tool that connects directly to GitHub Issues and PRs. It supports multiple views: Board (Kanban-style columns), Table (spreadsheet-like), and Roadmap (timeline/Gantt). You can add custom fields, filters, and automations.

Why other answers are incorrect:

A: Milestones group issues by target date/version — they're simple progress tracking, not multi-view project management.

B: Discussions are for community conversations — not project task tracking with board/roadmap views.

D: Repository Insights shows contributor statistics, commit activity, and traffic — not project management boards.

💡 Key Concept:

GitHub Projects vs classic project boards: New Projects (V2) = organization or user-level, multiple views (board/table/roadmap), custom fields, automations, cross-repo. Classic boards = single-repo, basic Kanban only. Use Projects V2.

Question 16: Merge Strategies

✓ Correct Answer: D) Squash and merge

Why this is correct:

Squash and merge combines all commits from the feature branch into a single commit when merging to main. The full feature development history is condensed to one clean commit: "Add payment feature (#42)" — keeping main's history readable without noise from intermediate work-in-progress commits.

Why other answers are incorrect:

A: "Create a merge commit" brings all individual feature branch commits into main's history plus adds a merge commit — creates noise in the history.

B: Fast-forward merge requires no diverged history and moves the branch pointer forward linearly — creates no merge commit but keeps all commits.

C: "Rebase and merge" replays individual commits without a merge commit — keeps all commits but still imports every intermediate commit.

💡 Key Concept:

Merge strategies: Merge commit (keeps all history, adds merge commit), Squash (condenses to 1 commit, clean main), Rebase (linear, no merge commit, keeps all commits). Teams often use: squash for features, regular merge for releases.

Question 17: GitHub Releases

✓ Correct Answer: A) GitHub Releases

Why this is correct:

GitHub Releases (built on top of Git tags) allows you to create versioned software releases with: release notes (markdown), attached binary files/assets, pre-release flags, and source code archives. It provides a clean download page for users and integrates with package managers.

Why other answers are incorrect:

B: GitHub Packages hosts package artifacts (npm, Docker, Maven, etc.) for reuse in other projects — not the same as creating a versioned release with binary downloads and release notes.

C: GitHub Pages hosts static websites from a repository — not for distributing software packages with release notes.

D: A tagged commit with README is the underlying mechanism, but Releases adds the UI, file attachments, and release notes on top of tags — the full feature for distribution.

💡 Key Concept:

Releases vs Packages: Releases = versioned distribution (binaries, release notes, changelogs). Packages = reusable software packages (libraries, containers) published to GitHub's package registry for use as dependencies.

Question 18: GitHub Actions

✓ Correct Answer: B) GitHub Actions

Why this is correct:

GitHub Actions is GitHub's built-in CI/CD platform. It uses YAML workflow files stored in .github/workflows/ to define automated workflows triggered by events (push, pull_request, schedule, etc.). Actions can run tests, build artifacts, deploy to cloud services, and automate any task.

Why other answers are incorrect:

A: GitHub Pages hosts static websites — it doesn't run CI/CD workflows or automated testing.

C: GitHub Packages stores and distributes packages — it's a registry, not an automation platform.

D: GitHub Apps are integrations built by third parties that can respond to GitHub events — they're distinct from GitHub's built-in Actions platform.

💡 Key Concept:

GitHub Actions concepts: Workflow (YAML file defining automation), Job (unit of work, runs on a runner), Step (individual action within a job), Action (reusable step from marketplace or custom), Runner (machine that executes jobs, GitHub-hosted or self-hosted).

Question 19: Actions Triggers

✓ Correct Answer: C) on:\n push:\n branches: [main]\n pull_request:\n branches: [main]

Why this is correct:

This YAML trigger configuration specifies that the workflow runs on pushes to main AND on pull_requests targeting main. The branch filter ensures it only runs for the main branch, not all branches. This is the standard CI configuration: test on PRs and deploy on push to main.

Why other answers are incorrect:

A: "on: [push, pull_request]" would trigger on ALL pushes and ALL pull_requests to any branch — no branch filtering.

B: This is not valid YAML — GitHub Actions uses specific YAML event syntax, not natural language.

D: Not valid GitHub Actions trigger syntax.

💡 Key Concept:

Common GitHub Actions triggers: push, pull_request, workflow_dispatch (manual), schedule (cron), release, issues, issue_comment, create, delete. Filter with branches:, paths:, tags: to control when workflows run.

Question 20: Actions Secrets

✓ Correct Answer: D) Store it as a GitHub Actions Secret and reference it with ${{ secrets.API_KEY }}

Why this is correct:

GitHub Actions Secrets are encrypted environment variables stored securely in repository (or organization/environment) settings. They're automatically masked in workflow logs (replaced with ***). Referenced with `${{ secrets.SECRET_NAME }}` syntax in workflow YAML. Values are never exposed in plain text.

Why other answers are incorrect:

A: Plain text environment variables in YAML are visible to anyone who can read the repository — a serious security risk.

B: .env files committed to repos make secrets visible in the repository history — even if later deleted, the secret remains in git history.

C: Restricting repo access doesn't protect secrets already committed — anyone with access can read the code.

💡 Key Concept:

Secrets hierarchy: Repository secrets (available to the repo), Environment secrets (gated behind deployment environments with protection rules), Organization secrets (available to selected repos). Reference: ${{ secrets.NAME }}.

Question 21: GitHub Copilot

✓ Correct Answer: A) GitHub Copilot

Why this is correct:

GitHub Copilot is an AI pair programmer that provides real-time inline code suggestions in your IDE as you type. It's powered by OpenAI Codex/GPT-4 and integrates with VS Code, JetBrains, Visual Studio, and other editors. It suggests complete lines, functions, and even entire code blocks based on context.

Why other answers are incorrect:

B: GitHub Codespaces is a cloud development environment — it gives you a full VS Code instance in the browser but isn't the AI code suggestion feature.

C: GitHub Actions automates CI/CD workflows — it doesn't provide code suggestions in an editor.

D: GitHub Code Search is a powerful search tool for finding code across GitHub repositories — it searches, not suggests.

💡 Key Concept:

GitHub Copilot features: Inline completions (ghost text as you type), Copilot Chat (ask questions, explain code, suggest fixes), Copilot in CLI (command line help), Copilot Workspace (multi-file task planning). Available in VS Code, JetBrains, Visual Studio, NeoVim.

Question 22: Dependabot

✓ Correct Answer: B) Dependabot alerts and Dependabot security updates

Why this is correct:

Dependabot is GitHub's automated dependency management tool. Dependabot alerts notify you when a dependency has a known vulnerability in the GitHub Advisory Database. Dependabot security updates automatically opens PRs to update the vulnerable dependency to a safe version.

Why other answers are incorrect:

A: Code Scanning with CodeQL analyzes your own source code for vulnerabilities — not third-party dependency vulnerabilities.

C: Secret Scanning detects credentials and tokens accidentally committed — not dependency vulnerabilities.

D: GitHub Actions with npm audit could work but requires you to configure and maintain the workflow — Dependabot is built-in and requires no setup.

💡 Key Concept:

Dependabot capabilities: Dependabot alerts (vulnerability notifications), Dependabot security updates (auto PRs for security fixes), Dependabot version updates (keeps dependencies current to latest versions, configured via .github/dependabot.yml).

Question 23: Secret Scanning

✓ Correct Answer: C) Secret Scanning

Why this is correct:

GitHub Secret Scanning automatically scans repository content for known patterns of secrets (API keys, tokens, credentials) from 100+ service providers. When detected in public repos, the token is automatically revoked (with partner program providers) and both the repository owner and service provider are notified.

Why other answers are incorrect:

A: Dependabot handles dependency vulnerabilities — not accidentally committed credentials.

B: CodeQL performs static analysis for security vulnerabilities in your code logic — not pattern-matching for exposed secrets.

D: Branch protection rules control merge requirements — they don't scan for committed secrets.

💡 Key Concept:

Secret Scanning: Free for public repos (automatic). For private repos requires GitHub Advanced Security. Supports 100+ service providers (AWS, Azure, Google Cloud, GitHub tokens, etc.). Push protection can BLOCK commits containing secrets before they're pushed.

Question 24: GitHub Codespaces

✓ Correct Answer: D) GitHub Codespaces

Why this is correct:

GitHub Codespaces provides cloud-hosted development environments based on dev containers (devcontainer.json). The environment is pre-configured with all required tools, extensions, and dependencies for the repository. Accessible in browser via VS Code Web or in desktop VS Code. Team members get the same setup instantly.

Why other answers are incorrect:

A: GitHub Actions automates CI/CD — it doesn't provide an interactive development environment.

B: GitHub Dev (github.dev or pressing "." in a repo) opens a lightweight VS Code editor in the browser for viewing and light editing — but it's NOT a full development environment (no terminal, no running processes, no debugging).

C: GitHub Pages hosts static websites — not interactive development environments.

💡 Key Concept:

Codespaces vs GitHub Dev: Codespaces = full VM with terminal, run servers, debug. GitHub Dev (github.dev) = lightweight editor, view/edit files, no execution. Codespaces are billable (GitHub-hosted compute); GitHub Dev is free.

Question 25: Repository Visibility

✓ Correct Answer: A) Private

Why this is correct:

Private repositories are visible only to the repository owner and explicitly invited collaborators/teams. On GitHub.com, private repos are invisible to the general public and to GitHub users who haven't been granted access. This is the correct setting for proprietary code.

Why other answers are incorrect:

B: Public repositories are visible to everyone on the internet — including unauthenticated users. Wrong for proprietary code.

C: Internal visibility is a GitHub Enterprise feature where repos are visible to all organization members (but not the public). Mentioned for completeness — the question asks about private access.

D: "Restricted" is not a GitHub repository visibility option — the three options are Public, Private, and Internal (Enterprise only).

💡 Key Concept:

Repository visibility: Public (anyone can read, contribute via PRs), Private (only invited users), Internal (GitHub Enterprise org members only). Changing from private to public exposes the entire commit history — be careful with secrets in history.

📊 How Did You Score?

23–25

Exam Ready

Excellent! Schedule your exam.

19–22

Almost There

Review GitHub Actions and security features.

14–18

Keep Studying

Focus on Git commands and collaboration features.

0–13

More Study Needed

Work through the GH-900 study guide.

Ready for More GH-900 Practice?

These 25 questions are just a sample. The actual GH-900 exam has 45–75 questions.

MSCertQuiz GH-900 includes 500 questions covering:

✓ Git commands and workflow scenarios in depth
✓ GitHub collaboration features — PRs, Issues, Projects
✓ GitHub Actions workflows, triggers, and secrets
✓ Dependabot, Secret Scanning, Code Scanning
✓ GitHub Copilot, Codespaces, and modern dev features

$14.99 One-Time Payment

Lifetime access • No subscription • 500 questions

Try 40 Free Questions Get 500 Questions — $14.99

📚 Related GH-900 Resources

📖

GH-900 Study Guide

Complete guide covering all GitHub Foundations exam domains

🎯

GH-900 Certification Page

Exam details, domains, and preparation resources

Free GH-900 Practice Questions with Detailed Explanations

What You'll Get:

What These Questions Cover

📝 Practice Test Instructions

Git & GitHub Fundamentals

Git vs GitHub

Git Branching

Git Commit

Git Merge vs Rebase

git clone vs fork

git stash

Pull vs Fetch

.gitignore

Collaboration Features

Pull Requests

Code Review — PR Review Types

Branch Protection Rules

GitHub Issues

GitHub Discussions

CODEOWNERS

GitHub Projects

Merge Strategies

GitHub Releases

Actions, Security & Administration

GitHub Actions — Basics

GitHub Actions — Triggers

GitHub Actions — Secrets

GitHub Copilot

Dependabot

Secret Scanning

GitHub Codespaces

Repository Visibility

✋ Stop Here Before Scrolling!

📝 Answer Key with Detailed Explanations

Quick Answer Reference

Question 1: Git vs GitHub

Why this is correct:

Why other answers are incorrect:

💡 Key Concept:

Question 2: Git Branching

Why this is correct:

Why other answers are incorrect:

💡 Key Concept:

Question 3: Git Commit

Why this is correct:

Why other answers are incorrect:

💡 Key Concept:

Question 4: Git Merge vs Rebase

Why this is correct:

Why other answers are incorrect:

💡 Key Concept:

Question 5: Fork and Pull Request

Why this is correct:

Why other answers are incorrect:

💡 Key Concept:

Question 6: git stash

Why this is correct:

Why other answers are incorrect:

💡 Key Concept:

Question 7: git fetch vs git pull

Why this is correct:

Why other answers are incorrect:

💡 Key Concept:

Question 8: .gitignore

Why this is correct:

Why other answers are incorrect:

💡 Key Concept:

Question 9: Pull Requests

Why this is correct:

Why other answers are incorrect:

💡 Key Concept:

Question 10: PR Review Types

Why this is correct:

Why other answers are incorrect:

💡 Key Concept:

Question 11: Branch Protection Rules

Why this is correct:

Why other answers are incorrect:

💡 Key Concept:

Question 12: GitHub Issues