GH-900's official name is "GitHub Foundations," and unlike other Microsoft-numbered exams, you register for it directly through GitHub (examregistration.github.com), not Pearson VUE — a detail that alone catches candidates who assume it works like AZ-900 or MS-900 registration. The exam runs 60 questions in 60 minutes across seven domains, from Git basics all the way to GitHub Copilot policy and repository administration, so breadth is the real challenge, not difficulty per question.
Real exam questions describe a situation (a developer needs to X) and ask what you'd do about it, which is exactly how the 25 questions below are written. Click any question to reveal the answer, the reasoning, and why each wrong option is wrong.
Want the full domain breakdown first? See the GH-900 study guide.
Treat your score on these 25 as a diagnostic, not a verdict: missing several questions in one section below tells you exactly which of the seven domains — see the full GH-900 GitHub Foundations exam domain list — needs another pass before you schedule the real thing.
Git Command Quick Reference
A handful of these commands show up directly in the questions below — worth memorizing what each one actually does before you start.
| git clone <url> | Copy a remote repository to your local machine |
| git add <file> | Stage changes for the next commit |
| git commit -m "msg" | Save staged changes to local history |
| git push | Send local commits to the remote repository |
| git pull | Fetch remote changes and merge them into your branch |
| git fetch | Download remote changes without merging them |
| git branch <name> | Create a new branch |
| git checkout -b <name> | Create and switch to a new branch in one step |
| git merge <branch> | Combine another branch's history into the current branch |
| git rebase <branch> | Replay current branch commits on top of another branch |
| git stash | Temporarily shelve uncommitted changes |
| git log | View commit history |
Git & GitHub Fundamentals
Questions 1–8 · branching, committing, cloning, and the Git/GitHub distinction
1Git vs GitHubA 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?Tap to see the four answer choices and the correct answer →
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.
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.
2Git BranchingA 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?Tap to see the four answer choices and the correct answer →
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.
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.
3Staging & CommittingA 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?Tap to see the four answer choices and the correct answer →
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.
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.
4Merge vs RebaseA 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?Tap to see the four answer choices and the correct answer →
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.
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).
5Fork & Pull Request WorkflowYou 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?Tap to see the four answer choices and the correct answer →
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.
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.
6git stashA 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?Tap to see the four answer choices and the correct answer →
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).
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).
7git fetch vs git pullA 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?Tap to see the four answer choices and the correct answer →
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).
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.
8.gitignoreA 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?Tap to see the four answer choices and the correct answer →
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.
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.
Collaboration Features
Questions 9–17 · pull requests, Issues, Projects, and review workflow
9Pull RequestsA 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?Tap to see the four answer choices and the correct answer →
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.
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.
10PR Review ActionsA 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?Tap to see the four answer choices and the correct answer →
"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.
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).
11Branch Protection RulesYour 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?Tap to see the four answer choices and the correct answer →
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.
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.
12GitHub IssuesA 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?Tap to see the four answer choices and the correct answer →
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.
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.).
13GitHub DiscussionsAn 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?Tap to see the four answer choices and the correct answer →
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.
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.
14CODEOWNERSYour 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?Tap to see the four answer choices and the correct answer →
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`
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.
15GitHub ProjectsA 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?Tap to see the four answer choices and the correct answer →
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.
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.
16Merge StrategiesYour 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?Tap to see the four answer choices and the correct answer →
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.
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.
17GitHub ReleasesAfter 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?Tap to see the four answer choices and the correct answer →
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.
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.
Actions, Security & Administration
Questions 18–25 · CI/CD, Copilot, Dependabot, and repo administration
18GitHub Actions BasicsA 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?Tap to see the four answer choices and the correct answer →
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.
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).
19Actions TriggersYou 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?Tap to see the four answer choices and the correct answer →
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.
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.
20Actions SecretsYour 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?Tap to see the four answer choices and the correct answer →
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.
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 }}.
21GitHub CopilotA 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?Tap to see the four answer choices and the correct answer →
GitHub Copilot is an AI pair programmer that provides real-time inline code suggestions in your IDE as you type. It integrates with VS Code, JetBrains, Visual Studio, and other editors. It suggests complete lines, functions, and even entire code blocks based on context.
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.
22DependabotYour 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?Tap to see the four answer choices and the correct answer →
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.
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).
23Secret ScanningA 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?Tap to see the four answer choices and the correct answer →
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.
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.
24GitHub CodespacesA 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?Tap to see the four answer choices and the correct answer →
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.
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.
25Repository VisibilityA 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?Tap to see the four answer choices and the correct answer →
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.
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 to use this: the real GH-900 exam runs 45–75 questions. If you missed more than 5 of these 25, spend another pass through the study guide before scheduling — the exam leans hard on scenario recognition, not memorized definitions.
Go Beyond 25 Questions
MSCertQuiz has 500 GH-900 questions covering Git workflows, PR review scenarios, Actions YAML configuration, Dependabot/Secret Scanning/CodeQL, and Copilot/Codespaces — with the same reveal-as-you-go format.