GH-900 — GitHub Foundations (GH-900) Exam Scenario Practice Guide

This independent scenario practice guide is for candidates preparing for GitHub Foundations (GH-900) from GitHub. It focuses on how to read scenario-based questions, identify the real decision point, and choose the most defensible answer from the facts provided.

GH-900 scenarios are usually not asking you to recite a definition in isolation. They often describe a team, repository, workflow, access need, collaboration problem, or security requirement. Your task is to decide which GitHub concept, feature, or action best satisfies the goal with the least unnecessary complexity.

What GH-900 Scenarios Usually Test

A GitHub Foundations scenario commonly asks you to connect a practical situation to the right GitHub capability. Before looking for an answer, classify the situation.

You are often deciding:

• Where work should happen

  • Local Git repository
  • GitHub repository
  • Fork
  • Branch
  • Pull request
  • Issue, Discussion, Project, Wiki, or README

• How people should collaborate

  • Review changes
  • Track bugs or tasks
  • Discuss ideas
  • Assign responsibility
  • Organize work across repositories
  • Document a project

• How access should be controlled

  • Repository visibility
  • Organization membership
  • Teams
  • Repository roles or permissions
  • Branch protections
  • Required reviews or status checks

• How automation should be used

  • GitHub Actions workflows
  • Events that trigger workflows
  • Jobs, steps, and runners
  • Secrets used by workflows
  • Status checks on pull requests

• How security signals should be handled

  • Dependency alerts
  • Secret exposure
  • Code scanning findings
  • Branch protection needs
  • Least privilege access

The best answer is the one that fits the described goal, scope, and constraints. Do not choose a powerful GitHub feature simply because it sounds advanced.

First Pass: Identify the Environment

Before judging the answer choices, locate the environment described by the question.

Ask:

• Is the action happening locally with Git or remotely on GitHub?
• Is the scenario about a personal account, repository, organization, or team?
• Is the repository public or private?
• Is the person a maintainer, collaborator, organization member, or outside contributor?
• Is the change being made on the default branch, a feature branch, or a fork?
• Is the problem about code, planning, documentation, automation, or security?

This prevents you from choosing an answer that solves the wrong layer of the problem.

Local Git vs GitHub

A common GH-900 distinction is whether the scenario is about Git itself or the GitHub platform.

Use this reasoning:

• If the scenario mentions tracking versions locally, think Git concepts such as commits, branches, merging, cloning, fetching, pulling, or pushing.
• If the scenario mentions collaboration, reviews, issues, permissions, organizations, hosted repositories, workflows, or pull requests, think GitHub features.
• If the scenario says a change exists locally but not on GitHub, the missing step may involve pushing.
• If the scenario says a repository exists on GitHub and a user needs a local copy, cloning is likely relevant.
• If a user does not have write access to a repository but wants to propose a change, a fork and pull request workflow may be relevant.

Find the Actual Decision Point

Most scenario questions contain extra context. Your job is to find the one decision that matters.

Look for the sentence that asks what should be done:

• “Which feature should the team use?”
• “What is the best way to allow this collaboration?”
• “Which action should the developer take next?”
• “How can the team protect the default branch?”
• “What should be configured to automate this process?”
• “Which GitHub feature addresses this security concern?”

Then restate the question in your own words.

For example:

• Long scenario: “A team wants contributors to propose changes, discuss them, run automated checks, and merge only after approval.”
• Restated decision: “Which GitHub workflow supports review and validation before merging?”
• Likely direction: “Use pull requests with reviews and checks.”

The restatement keeps you from chasing every detail in the scenario.

Separate Facts, Constraints, and Distractors

Read each scenario detail as one of three types.

Facts

Facts describe the current state.

Examples:

• The repository is public.
• The contributor does not have write access.
• The change is already committed locally.
• The team uses GitHub Actions.
• The default branch should not be changed directly.
• A dependency vulnerability was reported.

Constraints

Constraints limit what the answer must satisfy.

Examples:

• Changes must be reviewed before merge.
• Secrets must not be stored in source code.
• Access should be granted only to a group.
• The process should be automated.
• The team needs visibility across multiple repositories.
• The solution should preserve an audit trail.

Distractors

Distractors may be true statements but do not solve the scenario.

Examples:

• The repository has a README, but the decision is about branch protection.
• The organization uses Projects, but the question is about reviewing code.
• The workflow uses YAML, but the issue is that secrets should be handled securely.
• The scenario mentions Issues, but the actual requirement is to automate tests on pull requests.

Do not ignore context, but do not let background facts override the actual goal.

Use a GH-900 Decision Sequence

When an answer is not obvious, use this sequence.

1. Name the object being managed

Identify the main object:

• Repository
• Branch
• Commit
• Pull request
• Issue
• Project
• Organization
• Team
• Workflow
• Secret
• Dependency
• Package
• Release
• Documentation page

The object often points directly to the feature.

2. Name the required outcome

Ask what the user or team wants to achieve:

• Propose a change
• Review code
• Track a bug
• Plan work
• Automate testing
• Protect a branch
• Limit access
• Store credentials securely
• Publish documentation
• Respond to a security alert

3. Match the object and outcome to a GitHub capability

Examples:

• Code change plus review: pull request
• Isolated code work: branch
• Outside contribution without write access: fork plus pull request
• Task or bug tracking: Issue
• Planning and boards: GitHub Projects
• Open-ended team or community conversation: Discussions
• Automation: GitHub Actions
• Sensitive workflow values: Actions secrets
• Required review before merge: branch protection and pull request review rules
• Dependency vulnerability signal: Dependabot-related feature
• Exposed credential signal: secret scanning-related feature

4. Apply least privilege and least disruption

If two options seem possible, prefer the one that satisfies the requirement without granting excessive access or changing more than necessary.

Examples:

• Grant a team the required repository permission instead of making every user an administrator.
• Require pull request reviews instead of relying on informal instructions.
• Store a token as a secret instead of committing it to the repository.
• Use a branch for new work instead of editing the default branch directly.
• Use a Project for planning rather than forcing planning details into commit messages.

5. Check whether the answer solves the exact problem

Before selecting, ask:

• Does this answer operate at the correct scope?
• Does it satisfy the stated constraint?
• Does it address the symptom, not just a related topic?
• Does it create unnecessary risk?
• Does it confuse Git with GitHub?

Reading Collaboration Scenarios

Collaboration is central to GitHub Foundations. Many scenarios describe how people contribute, review, and organize work.

Branches, Forks, and Pull Requests

Use these distinctions:

• A branch is useful for isolated work within a repository.
• A fork is a copy of a repository under another account, often useful when a contributor does not have write access to the original repository.
• A pull request is used to propose, discuss, review, and merge changes.
• A commit records a snapshot of changes.
• A push sends local commits to a remote repository.
• A merge integrates changes from one branch into another.

When the scenario mentions review, discussion of code changes, or checks before merging, a pull request is usually central.

Mini-scenario

A developer wants to fix a typo in an open-source repository but does not have write access. The maintainer wants to review the change before accepting it.

Reasoning:

• The developer cannot push directly to the original repository.
• The maintainer wants review before merge.
• The correct workflow should support an outside contribution.

Most defensible answer: fork the repository, make the change on a branch, and open a pull request to the original repository.

Issues, Discussions, and Projects

Do not treat every collaboration feature as interchangeable.

Use this practical distinction:

• Use Issues for actionable work, bugs, tasks, or enhancements.
• Use Discussions for open-ended conversations, questions, ideas, or community interaction.
• Use Projects to organize and track work, often across issues and pull requests.
• Use a README for important introductory project information.
• Use a Wiki or documentation area when the scenario emphasizes maintained project documentation rather than task tracking.

Mini-scenario

A team needs to track feature requests, assign owners, and connect the work to pull requests.

Reasoning:

• The work is actionable.
• Ownership and progress matter.
• Pull requests may link back to the tracked work.

Most defensible answer: use Issues for the work items and organize them with GitHub Projects if planning views are needed.

Reading Access and Permission Scenarios

Access scenarios often ask for the safest way to let people do their jobs.

Identify:

• Who needs access?
• To what resource?
• What must they be able to do?
• Is this one person or a group?
• Is the access temporary or ongoing?
• Is administrative access truly required?

Use Scope Carefully

GitHub access can be discussed at different levels:

• Account
• Repository
• Organization
• Team
• Branch
• Workflow or secret

A scenario about a team of developers should usually make you think about team-based access rather than repeatedly configuring individuals. A scenario about protecting a branch should make you think about branch rules rather than repository visibility alone.

Least Privilege Reasoning

Prefer the option that grants only the required level of access.

Examples:

• If users only need to triage issues, they may not need full administrative control.
• If a team needs to contribute code, repository permissions should match that contribution need.
• If the default branch must be protected, configure branch protections instead of trusting informal process.
• If only certain maintainers should approve sensitive changes, review rules or code ownership may be relevant depending on the scenario.

Do not choose “admin” simply because it is the most permissive answer. On security and administration scenarios, more access is rarely better unless the scenario explicitly requires administrative capabilities.

Reading Security Scenarios

Security scenarios in GH-900 often describe a risk signal or a control requirement. First decide whether the scenario is about prevention, detection, review, or response.

Match the Security Need to the Feature Area

Use these associations:

• Prevent direct changes to important branches

  • Think branch protection and required reviews or checks.

• Require the right people to review code

  • Think pull request reviews and, when relevant, code ownership concepts.

• Detect vulnerable dependencies

  • Think dependency security features such as Dependabot alerts or updates.

• Detect committed credentials

  • Think secret scanning-related capabilities.

• Analyze code for security issues

  • Think code scanning-related capabilities.

• Keep credentials out of source code and workflows

  • Think encrypted secrets or secure secret management in GitHub Actions.

Mini-scenario

A team wants automated tests to pass before code can be merged into the default branch.

Reasoning:

• The branch is the protected resource.
• The requirement is enforced before merge.
• The tests are automation signals.
• The answer should enforce behavior, not merely recommend it.

Most defensible answer: configure branch protection to require status checks before merging.

Mini-scenario

A workflow needs an API token to deploy an application, but the team does not want the token visible in the repository.

Reasoning:

• The value is sensitive.
• It is used by automation.
• It should not be committed to source code.

Most defensible answer: store the token as a GitHub Actions secret and reference it securely in the workflow.

Reading GitHub Actions Scenarios

GitHub Actions scenarios usually describe automation.

Look for:

• What event should start the automation?
• What repository contains the workflow?
• What tasks should the workflow perform?
• Does it run on a GitHub-hosted or self-hosted runner?
• Does it need secrets?
• Is the result used as a status check for a pull request?

Key Concepts to Recognize

• A workflow defines an automated process.
• An event triggers a workflow.
• A job groups steps that run on a runner.
• A step runs a command or action.
• A runner executes the workflow jobs.
• A secret stores sensitive values for workflows.

If a scenario asks how to automate tests on pull requests, think about a workflow triggered by pull request activity. If it asks how to prevent merging unless tests pass, combine the automation idea with branch protection or required status checks.

Mini-scenario

A repository should automatically run tests whenever a pull request is opened or updated.

Reasoning:

• The goal is automation.
• The trigger is pull request activity.
• The task is testing.

Most defensible answer: create or configure a GitHub Actions workflow that runs tests on pull request events.

Reading Repository and Documentation Scenarios

Some GH-900 scenarios focus on how information is presented in a repository.

Ask what kind of information needs to be shared:

• Project overview and setup instructions: README
• Contribution expectations: contributing guidelines
• Community expectations: code of conduct
• Security reporting instructions: security policy
• Longer project documentation: Wiki or documentation files
• Versioned downloadable software delivery: Releases
• Static site publishing: GitHub Pages, when the scenario clearly describes hosting a site from repository content

Mini-scenario

A new open-source project wants visitors to immediately understand what the project does, how to install it, and how to start contributing.

Reasoning:

• The information should be visible when people land on the repository.
• It is introductory project information.
• It should be easy for all visitors to find.

Most defensible answer: create a clear README and, if needed, supporting contribution documentation.

How to Compare Similar Answer Choices

GH-900 questions may include choices that are related but not equivalent. Compare them by outcome.

If the scenario says “propose changes”

Prefer:

• Branch plus pull request for review inside a repository
• Fork plus pull request when the contributor lacks write access

Be cautious with:

• Direct commits to the default branch if review or protection is required
• Issues alone, because they track work but do not submit code changes

If the scenario says “track work”

Prefer:

• Issues for actionable tasks, bugs, or enhancements
• Projects for organizing and visualizing work

Be cautious with:

• Pull requests alone, because they review code changes but are not the primary planning object
• Discussions when the work is specific and assignable

If the scenario says “automate”

Prefer:

• GitHub Actions workflows
• Appropriate workflow triggers
• Secrets for sensitive workflow values

Be cautious with:

• Manual checklists when the requirement is automated
• README instructions as a substitute for enforced automation

If the scenario says “protect”

Prefer:

• Branch protection
• Required reviews
• Required status checks
• Least privilege access

Be cautious with:

• Relying only on team norms
• Granting broader permissions than required
• Making a repository private when the actual requirement is branch-level control

If the scenario says “detect a security issue”

Prefer:

• The security feature that matches the issue type:
  • Dependency risk: dependency alerting/update capability
  • Secret exposure: secret scanning capability
  • Code weakness: code scanning capability

Be cautious with:

• Choosing a general collaboration feature when the scenario is specifically about detection or alerting

Interpreting Commands and Workflow Steps

Some scenarios may include Git commands or ask what action comes next. Focus on state changes.

Useful command-level reasoning:

• clone: create a local copy of a remote repository.
• commit: save changes to local history.
• push: send local commits to a remote repository.
• pull: bring remote changes into the local branch and integrate them.
• fetch: retrieve remote changes without necessarily integrating them.
• branch: create or use a separate line of work.
• merge: integrate changes from one branch into another.

If the scenario says “the developer committed locally, but teammates cannot see the change on GitHub,” the missing idea is likely pushing to the remote. If the scenario says “the developer needs a local copy of a GitHub repository,” cloning is likely relevant.

A Practical Elimination Method

When answer choices are close, eliminate in this order.

Eliminate answers at the wrong scope

Examples:

• A local Git command will not configure organization permissions.
• A repository setting will not replace a pull request review workflow.
• An Issue will not automatically run tests.
• A README will not enforce branch protection.

Eliminate answers that solve a related but different problem

Examples:

• GitHub Projects can organize work, but they do not by themselves review code.
• Pull requests review code, but they do not replace dependency alerts.
• Discussions support conversation, but they are not the best fit for tracking assigned bugs.
• Repository visibility controls who can see a repository, but it does not define merge requirements for a branch.

Eliminate answers that are unnecessarily broad

Examples:

• Giving admin access when write access or a specific role is enough.
• Making a repository private when only a branch needs protection.
• Disabling a process instead of configuring it correctly.
• Using manual approval outside GitHub when a GitHub review control is available.

Eliminate answers that ignore a stated constraint

Examples:

• If the scenario says “must be automated,” remove manual-only answers.
• If the scenario says “must be reviewed,” remove direct-commit answers.
• If the scenario says “must not expose secrets,” remove answers that store credentials in code.
• If the scenario says “contributors do not have write access,” remove answers that assume they can push to the upstream repository.

Compact Checklist for GH-900 Scenario Questions

Use this checklist during final review practice:

1. Who is acting?

   • Maintainer, contributor, organization owner, team member, outside user?

2. What object is involved?

   • Repository, branch, pull request, issue, workflow, secret, project, organization?

3. What is the desired outcome?

   • Review, automate, protect, track, document, publish, secure, collaborate?

4. What is the key constraint?

   • No write access, least privilege, no exposed secrets, required review, automated checks?

5. Is the answer Git or GitHub?

   • Local version control action or hosted collaboration feature?

6. Does the answer enforce or merely suggest?

   • For protection scenarios, enforced settings are usually stronger than informal instructions.

7. Is the answer proportional?

   • Choose the simplest feature that fully satisfies the requirement.

Final Review Practice Method

For each GH-900 scenario you practice, slow down and mark four things before looking at the answers:

• Scope: local Git, repository, organization, branch, workflow, or security feature
• Goal: what the user or team wants to accomplish
• Constraint: what must or must not happen
• Best-fit feature: the GitHub concept that directly satisfies the need

Then compare answer choices against that best-fit feature. If an option is technically true but does not meet the scenario’s goal, eliminate it.

For your next study session, use short topic drills for Git basics, repositories, collaboration, GitHub Actions, permissions, and security features. Then move into mixed GH-900 mock exams so you can practice switching between scenario types under exam-like timing.