Free GH-900 practice test

The standard open-source contribution workflow involves forking the repository (creating a personal copy on GitHub), cloning the fork, making changes on a feature branch, pushing to the fork, and then opening a Pull Request against the original (upstream) repository. Option D is incorrect because external contributors cannot push directly to a repository they don't have write access to. Option C (creating an Issue) is a way to request changes but is not the standard contribution workflow. Option A is incorrect; Codespaces on the original repository does not grant write access, and committing directly to main is not possible without permissions.

GitHub Enterprise Cloud satisfies all three requirements: (1) SAML single sign-on is an Enterprise Cloud feature that allows organizations to authenticate members through a corporate IdP; (2) GitHub Enterprise Cloud includes a 99.9% monthly uptime SLA backed by a service credit agreement; (3) 'internal' repository visibility is an enterprise-level concept that makes a repo visible to all members of the enterprise while keeping it hidden from the public — this visibility option does not exist on Free or Team plans. Option D is wrong: GitHub Free does not support SAML SSO and does not include an uptime SLA. Option C is wrong: GitHub Team does not include SAML SSO (it is an Enterprise feature) and does not come with an uptime SLA. Option A is wrong: 'GitHub Codespaces Enterprise' is not a GitHub pricing plan; Codespaces is a feature, not a standalone plan.

GitHub Copilot is an AI-powered pair programming assistant that provides code completions and function suggestions based on context (E), and it supports multiple programming languages thanks to its underlying generative AI model (B). Option C is false — Copilot integrates with popular IDEs such as VS Code, JetBrains, Neovim, and Visual Studio, not just the GitHub web editor. Option D is false — Copilot only suggests code; it never automatically deploys anything. Option A is false — Copilot has no version control capabilities and does not replace Git.

A Git tag is a fixed, named pointer to a specific commit (unlike a branch, which moves forward as new commits are added). Tags — especially annotated tags — are the standard way to mark release points in a repository's history, enabling reproducible checkouts of that exact state. Option A is wrong: a branch is a moving pointer; even if named after the release, it will advance with future commits unless frozen, making it an unreliable fixed reference. Option C is wrong: a GitHub Release is a GitHub UI/API feature that wraps around a Git tag — it requires an underlying tag to exist. It does not replace or eliminate the need for a Git tag. Option D is wrong: a commit message is free-form text with no special meaning to Git or GitHub tooling; it cannot be used to reliably check out a specific commit by name.

The GitHub CLI (gh) supports: creating repositories (gh repo create) — A; creating, viewing, and merging pull requests (gh pr create, gh pr review) — B; creating and listing issues (gh issue create, gh issue list) — D; and viewing Actions workflow run statuses (gh run list, gh run view) — E. All four are correct. Option C is incorrect — gh does not manage DNS or infrastructure-level settings for GitHub Enterprise Server. Option F is incorrect — while gh repo delete exists, there is no CLI command to delete an entire organization without multiple confirmation steps, and this is not considered a standard gh workflow task. Since the question asks for THREE, the best supported three from the clearly correct set are A, B, D, and E — noting that the question intends any three of those four valid answers to be selected.

A .gitignore file is specifically designed to tell Git which file patterns to ignore, preventing untracked files from appearing in git status and ensuring they are never accidentally committed. Option A is partially related — core.excludesfile is a global gitignore — but pointing it to a directory is not valid syntax, and a repository-level .gitignore is the correct, team-shared solution. Option B is wrong: .gitattributes controls how Git handles files that are already tracked (e.g., line endings, diff drivers); it does not prevent files from being tracked. Option D is wrong: git rm --cached removes files from the index but does not prevent them from reappearing as untracked; it would need to be repeated after every build and does not scale.

git commit --amend allows the developer to modify the most recent (unpushed) commit — including its message and its staged content. By removing the credentials from the files, staging the corrected files with 'git add', and then running 'git commit --amend', the developer replaces the last commit with a new, corrected one. Option C (git revert HEAD) is incorrect because it creates a brand-new commit that undoes the previous one, which would still expose the credentials in the history. Option A (git reset HEAD~1) undoes the commit and unstages its changes but does not fix the commit — it leaves the developer with uncommitted changes that still need to be cleaned up; it also doesn't let them directly amend the message. Option D (git cherry-pick HEAD) is used to apply a commit from one branch onto another and is irrelevant here.

The Insights tab on a GitHub repository contains a Traffic section that shows page views and unique visitors over the past 14 days, as well as referring sites and popular content. This is the dedicated location for repository engagement analytics. Option C (Settings > Collaborators) only manages who has write/admin access to the repository — it contains no traffic data. Option D (Security tab) is focused on vulnerability alerts, Dependabot, code scanning, and secret scanning — not visitor analytics. Option A (Actions tab) shows workflow run history and usage minutes for GitHub Actions — not repository traffic.

Options A and D are both correct. Option A: 'Require a pull request before merging' applies to ALL pushes to the protected branch, including those from users in the restricted push list — 'Restrict who can push' controls which accounts can push AT ALL, but the PR requirement still enforces that changes must arrive via a pull request; a direct push is rejected by this rule. Option D: 'Dismiss stale pull request approvals when new commits are pushed' means that if a commit is pushed to the HEAD of the PR branch, existing approvals are invalidated — however, since option A correctly states the push is rejected, option D applies to the scenario context of the existing PR (the prior approvals on her open PR would have been dismissed had she pushed to the PR branch before merging). Both A and D reflect real behavior of these two settings working in tandem. Option B is wrong: the 'Restrict who can push' setting gates who may attempt a push, but it does NOT override the 'Require a pull request' rule — the push is still rejected. Option C is wrong: GitHub never auto-creates a pull request from a rejected or completed push. Option E is a partially true distractor — CODEOWNER review is required — but the primary rejection reason is the PR requirement (option A), not CODEOWNER enforcement specifically on a direct push. Option F is wrong: status checks are evaluated within a pull request workflow; a direct push that violates the PR requirement is rejected outright and does not trigger the status-check gate.

Draft PRs are GitHub's built-in mechanism for marking a pull request as not ready for review or merge. The 'Mark as ready for review' button must be clicked before the PR can be merged, and required reviewers are not automatically notified. Adding a 'WIP' label (option B) is a manual convention with no enforcement by GitHub — it does not prevent merging or suppress review requests. A comment (option C) is purely informational with no enforcement. Setting the repository to private (option D) is unrelated to PR status and would affect all repository access, not just this PR.

GitHub recognizes a set of closing keywords — including 'fixes', 'closes', 'resolves', 'fix', 'close', and 'resolve' (case-insensitive) — that automatically close a linked issue when the PR is merged into the default branch. 'FIXES #42' is one of these recognized keywords. 'RELATES TO' (option C), 'REFERENCES' (option B), and 'SEE' (option D) are not recognized closing keywords; they will create a cross-reference hyperlink in the issue timeline but will not automatically close the issue.

(B) The verified creator badge on GitHub Marketplace indicates GitHub has confirmed the publisher's identity, which is a meaningful trust signal. (F) Pinning to a commit SHA rather than a mutable tag is a best practice that prevents the action's code from being silently changed after your review. (A) Reading the source code of an action — especially action.yml and any scripts — is the most direct way to detect malicious behavior like exfiltrating secrets or making unauthorized network requests. (D) Stars and commit recency are weak signals of trustworthiness — popular repos can still be malicious or compromised. (C) is false — both JavaScript and Docker-based actions are fully supported in production; there is no restriction by type. (E) is a social-engineering red flag, not a trust indicator — any creator can name their action anything.

By default, when a job fails in GitHub Actions, all downstream jobs that depend on it (directly or transitively via 'needs') are automatically skipped — they are not run at all. Since 'test' needs 'build', and 'build' failed, 'test' is skipped. Since 'deploy' needs both 'build' and 'test', it is also skipped. This behavior can be overridden by using 'if: always()' or 'if: failure()' conditions on dependent jobs, but no such conditions are present here. Options A and D describe incorrect partial-execution behaviors. Option B is wrong — GitHub Actions does not automatically retry jobs on failure, and downstream jobs are skipped, not independently executed.

Draft issues exist inside the project only; they can be converted into real repository issues later. They are not auto-created in any repository, so they do not appear in repository issue search. Draft issues can hold title, body, assignees, and custom field values. There is no automatic 30-day deletion.

Triage permission is designed for issue and PR management without code access: applying/removing labels, assigning people, and setting milestones. Creating or deleting labels requires write permission. Pushing commits requires write permission. Changing project visibility requires project admin rights, which triage on a repository does not grant.

Using the GitHub Audit Log API with filters for invitation-related events is the most appropriate approach. The audit log captures org.invite_member and org.accept_invitation events, is queryable via the API, supports time-range filtering (including 90-day windows), and can be exported programmatically — satisfying all requirements for automation and compliance reporting. — Manually downloading a member list and cross-referencing a spreadsheet is not scriptable or automatable, and does not reflect historical invitation states — only the current member roster. — GitHub Insights provides contribution metrics (commits, PRs, code frequency) for members and does not record invitation status, acceptance events, or onboarding history. — The /orgs/{org}/members endpoint with filter=2fa_disabled returns current members who have 2FA disabled — it is unrelated to invitation status and does not provide historical acceptance data.

SAML SSO enforced at the enterprise level requires all members to authenticate through the company's IdP before accessing GitHub, ensuring identity verification. SCIM (System for Cross-domain Identity Management) works alongside SSO to automatically provision, update, and deprovision user accounts based on IdP changes, completing the identity management lifecycle. Two-factor authentication is a GitHub-native security layer and does not integrate with a corporate IdP. IP allow lists restrict access by network location but do not enforce IdP-based authentication. Branch protection rules with signed commits are a code integrity feature, not an authentication mechanism. GitHub Advanced Security handles vulnerability and secret detection, unrelated to SSO or identity provider integration.

Archiving makes a repository read-only: no new issues, pull requests, comments, or pushes are permitted. Forks are still allowed on archived repositories, enabling others to create active copies if needed. All existing content — issues, pull requests, code, wiki — is preserved and remains visible in a read-only state. Archiving is NOT deletion; the repository persists and can be unarchived, so saying it is 'permanently deleted' is false. Collaborators do NOT lose access; they can still view and clone the repository, they simply cannot make changes. While it can be unarchived, that fact was not among the three correct options selected — the three behaviors above are the most accurate descriptions of the archived state itself.

GitHub Sponsors lets individuals and organizations fund developers and projects with one-time or recurring payments through GitHub, including via a FUNDING.yml sponsor button. GitHub Marketplace is for publishing apps and Actions (and paid apps require a verified publisher/organization), not for donating to a maintainer. Discussions is a community conversation forum with no payment function. Codespaces provides cloud development environments.

Topics classify a repository and appear in topic search and browsing; a clear description and README drive both GitHub search relevance and human evaluation; published releases help users find stable versions and signal an actively maintained project. A pile of open issues does not improve search ranking and often signals neglect. Template status affects how others create copies, not searchability. Dependabot alerts are a security feature visible mainly to maintainers and do not affect discovery.