GH-900 — GitHub Foundations (GH-900) Exam Blueprint

How to Use This Exam Blueprint

Use this checklist as a practical readiness map for the GitHub GitHub Foundations (GH-900) exam. It is not a replacement for hands-on practice. Treat each section as a set of skills you should be able to explain, recognize in scenarios, and apply in a basic GitHub workflow.

Because exact exam weights are not provided here, the areas below are organized as readiness areas, not weighted domains. For final review, focus on whether you can answer: “Which GitHub feature, workflow, permission, or setting fits this situation?”

Readiness areas at a glance

Core GitHub concepts checklist

Git vs. GitHub

Make sure you can clearly separate the version control system from the hosting and collaboration platform.

Ready check:

• I can explain why Git can be used without GitHub.
• I can explain why GitHub repositories still use Git history.
• I can describe the difference between cloning and forking.
• I can identify when a branch is enough and when a fork is more appropriate.
• I can explain what happens when a commit is pushed to GitHub.

Repository basics

Can you do this?

• Identify the default branch of a repository.
• Find commit history for a file.
• Compare two branches or commits conceptually.
• Explain why a README matters to a public or internal project.
• Recognize when a repository should include contribution or security guidance.
• Explain the difference between a tag and a release at a high level.

Git command and workflow recognition

The GH-900 exam is not a deep Git administration exam, but you should recognize common commands and know what they mean in a GitHub workflow.

Common command readiness

Basic workflow you should recognize:

git clone https://github.com/example/project.git
cd project
git switch -c feature/update-docs
git status
git add README.md
git commit -m "Update documentation"
git push origin feature/update-docs

Ready check:

• I know which commands affect only my local repository.
• I know which commands communicate with GitHub.
• I can explain why changes are staged before committing.
• I can explain why a branch is created before starting work.
• I can recognize that pushing a branch often precedes opening a pull request.

GitHub Flow readiness

GitHub Flow is a common collaboration model built around short-lived branches and pull requests.

    flowchart LR
	    A[Create or choose an issue] --> B[Create a branch]
	    B --> C[Make commits]
	    C --> D[Push branch to GitHub]
	    D --> E[Open pull request]
	    E --> F[Review and discuss]
	    F --> G[Checks pass]
	    G --> H[Merge]
	    H --> I[Delete branch when appropriate]

GitHub Flow checklist

• I can explain why work should be done on a branch instead of directly on the default branch.
• I can describe how commits become part of a pull request.
• I can identify who reviews a pull request and where comments appear.
• I can explain the role of automated checks in a pull request.
• I can describe what “merge” means in the context of a pull request.
• I can recognize when a pull request should not be merged yet.
• I can explain how branch protection or repository rules can enforce review and quality gates conceptually.

Pull request readiness table

Scenario cues:

Issues, discussions, and planning

Issue management checklist

• I can describe what an issue is used for.
• I can distinguish issues from pull requests.
• I can use labels to categorize work.
• I can use assignees to indicate ownership.
• I can use milestones to group work toward a target.
• I can explain how issue templates improve consistency.
• I can recognize when an issue should be closed, linked, transferred, or converted into actionable work.

GitHub Projects readiness

GitHub Projects can organize issues and pull requests into views for planning and tracking.

Can you do this?

• Explain why a project is useful when issues alone are not enough.
• Recognize table, board, and roadmap-style planning concepts.
• Understand that project fields can track status, priority, iteration, owner, or custom metadata.
• Distinguish a project view from the underlying issue or pull request.
• Understand that automation can help move or update items based on workflow events.

Scenario cues:

Markdown and documentation artifacts

GitHub uses Markdown heavily in repositories, issues, pull requests, discussions, and documentation.

Markdown skills to verify

• Headings using #, ##, and ###
• Bulleted and numbered lists
• Links and images
• Code blocks and inline code
• Tables
• Task lists with checkboxes
• Mentions of users or teams
• References to issues or pull requests
• Basic formatting such as bold and italic text

Example recognition:

## Setup

1. Clone the repository.
2. Install dependencies.
3. Run the tests.

- [ ] Update README
- [ ] Open pull request
- [ ] Request review

Repository documentation files

Ready check:

• I can identify which documentation file solves a given collaboration problem.
• I understand why public repositories often need clear community guidance.
• I can read a Markdown checklist and know how it appears on GitHub.
• I can explain why secrets, generated files, and local environment files are often excluded with .gitignore.

Identity, access, and permissions

Authentication and access concepts

Can you do this?

• Explain why 2FA reduces account takeover risk.
• Recognize when an SSH key is used for Git authentication.
• Recognize when a token may be needed instead of a password.
• Explain why tokens should be limited, rotated, and protected.
• Identify that secrets should not be committed to a repository.
• Explain why team-based access is easier to manage than user-by-user access.
• Distinguish repository-level access from organization-level administration.

Permissions and administration scenario checks

Repository security readiness

The exam may test basic awareness of GitHub security features and secure collaboration practices. Focus on what each feature is for, not deep configuration details.

Can you do this?

• Identify why committing credentials is dangerous.
• Explain why dependency updates matter for security.
• Recognize that security alerts need triage, not just acknowledgment.
• Explain why automated checks can block risky changes before merge.
• Distinguish code review from automated security scanning.
• Recognize that repository visibility is not the same as secure code.
• Explain why secrets should be stored in protected configuration areas for automation.

Common traps:

GitHub Actions basics

GitHub Actions provides automation for workflows such as CI, testing, publishing, issue triage, and deployment support.

Actions concepts checklist

• I can explain what a workflow is.
• I know workflows are defined with YAML files in a repository.
• I can explain that events trigger workflows.
• I can identify jobs and steps in a workflow.
• I can explain that actions are reusable units of workflow logic.
• I know runners execute workflow jobs.
• I understand secrets can be used by workflows without hardcoding sensitive values.
• I can distinguish workflow artifacts from source files.
• I can recognize a failed workflow check on a pull request.

Example workflow recognition:

name: Basic CI

on:
  pull_request:
  push:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: echo "Run project tests here"

You do not need to memorize every YAML option for a foundations-level checklist, but you should be able to identify the major parts:

Scenario cues:

Developer productivity tools

Tool selection checklist

Can you do this?

• Choose GitHub Desktop for a user who prefers a graphical Git workflow.
• Choose GitHub CLI for terminal-based GitHub operations.
• Recognize Codespaces as a ready-to-use development environment scenario.
• Recognize the web editor as useful for small edits.
• Explain that Copilot can suggest code but does not replace review, testing, or security validation.
• Identify GitHub Marketplace as a source of apps and reusable actions.

Open source and community collaboration

Contribution workflow readiness

A common open source contribution flow looks like this:

1. Find a repository and read its README and contribution guidance.
2. Fork the repository if direct branch access is not available.
3. Clone your fork.
4. Create a branch.
5. Make commits.
6. Push to your fork.
7. Open a pull request to the original repository.
8. Respond to review feedback.
9. Maintainers decide whether and how to merge.

Can you do this?

• Explain why external contributors often fork repositories.
• Identify the upstream repository versus the contributor’s fork.
• Explain how maintainers review and discuss proposed changes.
• Recognize why a code of conduct matters in community projects.
• Recognize why a license matters before reuse.
• Explain how issue templates and contribution guides reduce maintainer burden.

Integrations, APIs, and ecosystem concepts

You should know that GitHub is extensible and can connect to other tools.

Scenario cues:

Troubleshooting and decision-point checks

Common symptoms and likely causes

Decision prompts

Ask yourself these questions during scenario practice:

• Is the problem about source control, collaboration, automation, security, or administration?
• Is the actor a repository contributor, maintainer, organization owner, reviewer, or external user?
• Does the scenario require a Git feature or a GitHub platform feature?
• Is the change local only, or has it been pushed to GitHub?
• Should the person create a branch, fork the repository, or request access?
• Should the work be tracked as an issue, discussion, project item, or pull request?
• Is the goal to prevent a risky change, detect a problem, or respond after exposure?
• Does the scenario require human review, automated checks, or both?
• Is a secret, token, or key being handled safely?
• Is the proposed permission broader than necessary?

High-value “Can you do this?” checklist

Use this as a final readiness drill.

Fundamentals

• Define Git.
• Define GitHub.
• Explain repository, branch, commit, clone, fork, and remote.
• Describe how local changes become visible on GitHub.
• Explain why version history is useful.
• Identify the purpose of the default branch.

Collaboration

• Open a pull request conceptually from a feature branch.
• Explain what reviewers do in a pull request.
• Identify where automated checks appear.
• Explain when a merge conflict must be resolved.
• Link a pull request to an issue conceptually.
• Choose issues, discussions, projects, or milestones for a scenario.

Security and permissions

• Explain least privilege.
• Identify why 2FA is important.
• Explain the purpose of SSH keys and tokens.
• Recognize why secrets should not be committed.
• Match Dependabot, secret scanning, and code scanning concepts to scenarios.
• Explain how teams help manage access.
• Recognize when branch protection or repository rules are appropriate.

Automation

• Identify the parts of a GitHub Actions workflow.
• Explain what triggers a workflow.
• Distinguish jobs from steps.
• Explain what a runner does.
• Recognize when to use secrets in workflows.
• Interpret a failed check as a merge readiness signal.

Documentation and community

• Identify the purpose of README, LICENSE, CONTRIBUTING, SECURITY, and CODE_OF_CONDUCT files.
• Read and write basic Markdown.
• Explain a fork-based contribution workflow.
• Recognize the role of maintainers in open source.
• Explain why issue and PR templates improve collaboration.

Tools and ecosystem

• Choose between GitHub web UI, GitHub Desktop, GitHub CLI, and Codespaces.
• Explain GitHub Marketplace at a high level.
• Recognize webhooks and APIs as integration mechanisms.
• Explain GitHub Pages and Packages at a basic use-case level.
• Describe Copilot as an assistant that still requires review and validation.

Common weak areas and traps

Scenario practice matrix

Use this matrix to test whether you can choose the best GitHub feature quickly.

Final-week checklist

Seven to five days out

• Review all core terms: repository, branch, commit, pull request, issue, fork, clone, remote.
• Walk through a complete GitHub Flow scenario without notes.
• Review the difference between issues, discussions, projects, and milestones.
• Review common Git commands and what each command changes.
• Review basic repository documentation files and their purposes.

Four to two days out

• Practice permission and access scenarios.
• Review secure handling of tokens, SSH keys, and secrets.
• Review GitHub Actions vocabulary: workflow, event, job, step, runner, secret, artifact.
• Review pull request states: review needed, checks failed, conflict, ready to merge.
• Review open source contribution flow using forks and pull requests.

Final day

• Re-read the common traps table.
• Drill scenario cues instead of memorizing isolated definitions.
• Confirm you can explain each major GitHub feature in one or two sentences.
• Practice choosing the simplest correct GitHub feature for a scenario.
• Avoid cramming product limits, dates, or pricing details unless they appear in your official study materials.

Practical next step

Use this checklist to mark weak areas, then practice with scenario-based questions that force you to choose between similar GitHub features: branch vs. fork, issue vs. discussion, project vs. milestone, token vs. SSH key, and review requirement vs. automated check. Focus on explaining why the selected GitHub feature is the best fit for the situation.