Try 10 focused GitHub Foundations GH-900 questions on Privacy and Administration, with explanations, then continue with IT Mastery.
Open the matching IT Mastery practice page for timed mocks, topic drills, progress tracking, explanations, and full practice.
Try GitHub Foundations GH-900 on Web View full GitHub Foundations GH-900 practice page
| Field | Detail |
|---|---|
| Exam route | GitHub Foundations GH-900 |
| Topic area | Understand Privacy, Security, and Administration |
| Blueprint weight | 10% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Understand Privacy, Security, and Administration for GitHub Foundations GH-900. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 10% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
Topic: Understand Privacy, Security, and Administration
A GitHub organization adds six new documentation contributors. They all need the same access to four private repositories, and the administrator wants to manage that access in one place as people join or leave the group. What is the best GitHub approach?
Options:
A. Create a team and grant the team repository permissions
B. Enable branch protection on each repository’s default branch
C. Assign all six contributors the organization owner role
D. Add each contributor separately to each repository
Best answer: A
Explanation: Use a team when multiple organization members need the same access across repositories. Teams centralize permission management, so the admin can add or remove people once instead of updating every repository individually.
In GitHub organizations, teams are the standard way to manage shared repository access for a group of members. This fits the scenario because the contributors need the same permissions on multiple private repositories, and the administrator wants a single place to maintain membership over time.
A team helps by:
The closest distractor is adding people separately to each repository, but that creates more admin work and is harder to maintain as the group changes.
Topic: Understand Privacy, Security, and Administration
Priya has been added to a private GitHub repository and can already view files, issues, and pull requests. During release prep, she is asked to change branch protection and other repository settings. What is the correct next step?
Options:
A. Star and watch the repository to unlock settings controls
B. Open a pull request that describes the setting changes
C. Request Admin access from a repository or organization administrator
D. Create a fork and update the settings there
Best answer: C
Explanation: Viewing repository content and administering repository settings are different permission levels on GitHub. Because Priya can already see the repository but needs to change branch protection and settings, she needs elevated administrative access from someone who manages the repository.
This scenario tests the difference between repository access for viewing content and repository access for administration. Being able to open files, issues, and pull requests means Priya already has access to the repository’s content, but that does not allow her to manage settings. Tasks like changing branch protection or other repository settings require administrative permissions.
On GitHub, content work and settings work are separate:
The key takeaway is that seeing a repository is not the same as being allowed to administer it.
Topic: Understand Privacy, Security, and Administration
A small team has a GitHub repository for an internal training app. The repository is currently public because it began as a demo, but the team is about to add proprietary course content. Only the existing team members should be able to view the code and files. Branch protection on main is already enabled. What is the best next step?
Options:
A. Open a discussion asking contributors not to share the repository link
B. Create a new branch for the proprietary content
C. Require pull requests before merging to main
D. Change the repository visibility to private
Best answer: D
Explanation: The requirement is about who can see the repository, so the visibility setting is the control that must change. Branch protection and pull request rules help control changes, but they do not stop the public from viewing a public repository.
Repository visibility determines who can view a project on GitHub. In this scenario, the repository is public, but the team now needs to restrict access so only the intended team members can see the code and files. The best next action is to change the repository to private.
Branch protection and pull request requirements protect important branches from unsafe or unreviewed changes, but they do not hide repository contents from the public. A discussion post is only communication guidance and does not enforce access control. When the goal is to match project access with who may see it, use the repository visibility setting.
The key takeaway is to choose visibility settings for viewing access and use branch rules for change control.
Topic: Understand Privacy, Security, and Administration
A team stores code in a private GitHub repository. The repository is already visible only to approved members, but the organization also wants to reduce the risk of someone signing in with a stolen password and accessing any of a member’s GitHub resources.
Which foundational GitHub concept best explains the control they should add?
Options:
A. Private repository visibility
B. Team-based repository permissions
C. Two-factor authentication
D. Branch protection
Best answer: C
Explanation: The scenario is about protecting the account sign-in process, not changing who can see the repository. Two-factor authentication adds an extra verification step after the password, which helps if the password is stolen.
This scenario separates two different GitHub ideas: account security and repository access settings. A private repository controls who is allowed to see that repository, but it does not strengthen how a user signs in. If an attacker gets a member’s password, private visibility alone does not stop access through that compromised account.
Two-factor authentication is an account security control. It requires an additional verification factor during sign-in, which helps protect the user’s GitHub account and, by extension, the repositories and organizations that account can access.
The key takeaway is that repository visibility limits audience, while account security controls protect identity and sign-in.
main, not account authentication.Topic: Understand Privacy, Security, and Administration
Nina created a private GitHub repository for a school project. Her instructor says, “Private visibility controls who can see the repository, but you also need to protect your GitHub sign-in.” What should Nina do next to address that second requirement?
Options:
A. Set up an account sign-in control such as two-factor authentication
B. Add branch protection to the default branch
C. Invite only selected collaborators to the repository
D. Change the repository visibility to internal
Best answer: A
Explanation: Repository visibility and account security solve different problems. Since the repository is already private, the next step for protecting Nina’s sign-in is to enable an account-level control such as two-factor authentication.
The key distinction is account security versus repository access. A private repository limits who can view the repository, but it does not by itself strengthen how Nina signs in to GitHub. To reduce the risk of someone accessing her account, she should use an account-level sign-in protection such as two-factor authentication.
Private or internal visibility, collaborator lists, and branch protection all control repository access or repository change rules. They do not replace account authentication controls. In this workflow, first confirm the repository visibility meets the sharing need, then configure account security to protect the user account itself.
The closest distractors improve repository management, but they do not directly secure the sign-in process.
Topic: Understand Privacy, Security, and Administration
Priya learns that a password she once used on another website was exposed. She uses GitHub on devices that support biometric unlock and wants a stronger sign-in method that is phishing-resistant and does not require entering a password or one-time code each time.
What is the best next step?
Options:
A. Open a discussion asking teammates to watch for suspicious sign-ins
B. Make her repositories private
C. Add a passkey to her GitHub account
D. Enable branch protection on the default branch
Best answer: C
Explanation: This scenario points to a passkey because the goal is stronger account security with passwordless, phishing-resistant sign-in. Repository visibility, branch protection, and team discussion do not secure the account login itself.
A passkey is the best fit when someone wants to protect a GitHub account with a modern sign-in method that can use a device’s biometric unlock or PIN. In this scenario, the key clues are phishing resistance and avoiding repeated password or one-time code entry. That maps directly to passkey use.
Two-factor authentication also improves account security, but it usually adds a second verification step to sign-in rather than replacing the password experience in the same way. The other choices focus on repository management or team communication, not on protecting the user’s GitHub account credentials.
When the need is account-level, passwordless sign-in, choose a passkey rather than a repository setting.
Topic: Understand Privacy, Security, and Administration
A team creates a GitHub repository for an unreleased product feature. The project manager says that only approved team members should be able to view the code until launch. One contributor suggests adding a confidential label to issues and pull requests. What should the team do next?
Options:
A. Change the repository visibility to private and use labels only to organize work
B. Enable branch protection on the default branch and keep the repository visible
C. Keep the repository public and add a confidential label to all work items
D. Create a project named Confidential and track the feature there
Best answer: A
Explanation: This privacy requirement is about who can see the repository, so it must be handled with repository visibility. Labels, projects, and branch protection help manage work or changes, but they do not restrict repository access.
The core concept is that repository visibility is an access control setting, while labels are a collaboration tool. If the goal is to prevent people outside the approved team from viewing the code, the repository must be set to a private visibility level. Labels such as confidential can still be useful, but only for organizing issues and pull requests inside the repository.
Branch protection controls how changes reach a branch, such as requiring reviews, but it does not hide the repository. Projects help track work, and discussions or labels help coordinate contributors, but none of those features replace visibility settings for privacy.
When the requirement is about who can see the content, choose visibility settings instead of collaboration labels.
Topic: Understand Privacy, Security, and Administration
A repository maintainer in one GitHub organization is asked to make employee access follow the company’s identity provider across all company-owned GitHub organizations, including centralized account provisioning and removal. The maintainer has admin access only to a single repository. What is the best next step?
Options:
A. Add branch protection rules to the default branch.
B. Make the repository private and manage each collaborator manually.
C. Ask the enterprise administrators to evaluate Enterprise Managed Users for centralized account management.
D. Create a repository discussion for onboarding requests.
Best answer: C
Explanation: Enterprise Managed Users applies to organization or enterprise administration because it centrally manages user identities and lifecycle with an identity provider. A repository maintainer cannot solve that requirement with a repository-only setting.
The key clue is the scope: the company wants identity-provider-based access and centralized provisioning and removal across company-owned organizations. That is an account and administration requirement, not a repository workflow task. Enterprise Managed Users is relevant when an enterprise wants managed user identities controlled centrally, so the right action is to involve the enterprise administrators rather than change settings in one repository.
Repository settings such as visibility or branch protection can help with collaboration and security inside a repo, but they do not create centrally managed user accounts or organization-wide identity lifecycle control. The best takeaway is to match the request to the correct admin layer: repository, organization, or enterprise.
Topic: Understand Privacy, Security, and Administration
A team stores code in a private GitHub repository inside an organization. The team lead wants developers to push changes, testers to view the repository and comment on work, and only a few maintainers to manage repository settings. What is the best GitHub approach?
Options:
A. Create issue labels for each group
B. Assign appropriate repository roles and permissions to users or teams
C. Enable branch protection on the default branch
D. Move project discussions to the repository Wiki
Best answer: B
Explanation: GitHub controls repository access through permissions and roles. In this scenario, the team needs different levels of access for different people, so assigning the right repository roles to users or teams is the correct solution.
The core concept is that GitHub repository access is managed by permissions and roles. When a team needs different people to do different things—such as pushing code, commenting, or managing settings—the correct approach is to assign the appropriate access level to each user or team.
This supports least-necessary access:
Branch protection helps control changes to a branch, but it does not replace repository access roles. Labels and Wikis help organize work and documentation, not control who can access or administer a repository.
Topic: Understand Privacy, Security, and Administration
Rina signs in to GitHub.com with only a password. Her team wants an extra verification step so that a stolen password alone cannot be used to access her GitHub account. What is the best next step?
Options:
A. Change the repository visibility to private.
B. Enable branch protection on the default branch.
C. Enable two-factor authentication on her GitHub account.
D. Add an SSH key to the repository.
Best answer: C
Explanation: Two-factor authentication is an account security control that requires a second verification factor in addition to a password. In this scenario, the goal is to protect sign-in to Rina’s GitHub account, so enabling 2FA is the direct next action.
The core concept is that two-factor authentication protects a user account, not a repository. It reduces the risk of unauthorized access because an attacker would need both the password and a second factor to sign in.
In this scenario, the problem is specifically that Rina uses only a password for GitHub.com access. The best next step is to enable 2FA on her GitHub account so sign-in requires an added verification step.
Repository visibility and branch protection help secure code and collaboration, but they do not add a second factor to account login. Adding an SSH key helps with certain Git operations, but it is not the same as enabling 2FA for account sign-in.
Use the GitHub Foundations GH-900 Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Try GitHub Foundations GH-900 on Web View GitHub Foundations GH-900 Practice Test
Read the GitHub Foundations GH-900 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.