GitHub Foundations #9 Domain 7: The GitHub Community + Exam Tips

The final domain, Benefits of the GitHub Community, is not large, and most of its questions simply confirm definitions. Connect each concept’s name to its one-line definition accurately and this is an area where you score quickly and move on. After the domain material, following the series convention, come the tips to check right before the exam.

Open source and source-available are different #

Start with the distinction the exam loves most. Making a repository public is not the same as open source.

• Source-available — the code is visible to anyone. Seeing and using are separate things: without a license, no rights to use, modify, or redistribute are legally granted.
• Open source — on top of public code, a license granting use, modification, and redistribution has been applied. A license file such as MIT, Apache 2.0, or GPL is the basis of those rights.

That is why “a public repository with no LICENSE file” works as a trap option — it is not open source. Foundations does not go deep into license differences (permissive versus copyleft and so on), so it is enough to hold on to the principle that the license defines the rights.

Community files — a project’s standard signage #

These are the standard files a healthy open source project carries. Questions ask you to match each file to its role.

The screen that checks these files at a glance is the Community Standards checklist under the repository Insights tab covered in the previous post. It is also worth remembering that a .github repository lets multiple repositories in an organization inherit these files in common.

InnerSource — open source practices inside the organization #

InnerSource applies the collaboration style of open source to private repositories inside an organization. The code is not published outside the company, but within the organization other teams’ repositories can be browsed, issues opened, and contributions made through PRs in the open source manner.

• The difference from open source is the scope of visibility. Open source addresses the whole world, while InnerSource addresses the inside of an organization.
• The payoff is breaking down silos. Duplicate development between teams shrinks, and well-built internal libraries attract contributions from the entire organization.

Whether asked as a definition or as a scenario (“we want to adopt open-source-style contribution culture for our internal codebase”), the answer converges on InnerSource — Domain 7’s signature question.

Sponsorship, extensions, learning — the remaining community features #

For these items, connecting name to purpose is all that is needed.

• GitHub Sponsors — financially supports open source developers and projects.
• GitHub Marketplace — the storefront for finding and installing extensions such as Actions and apps.
• GitHub Community — the official forum where users ask questions and discuss.
• GitHub Skills — a collection of free, hands-on courses built on practice repositories, and an official preparation resource for this exam.

The standard open source contribution cycle #

The community domain also asks about the contribution procedure as a scenario. The standard flow for contributing to someone else’s public repository runs in this order.

1. Fork the repository to your own account. You have no push access to the original, so you need a server-side copy.
2. Clone the fork, create a branch, and commit your changes.
3. Push to the fork, then open a PR toward the original repository. The fork’s branch is compare, and the original’s branch is base.
4. Apply review feedback; the maintainers of the original repository decide the merge.

The CONTRIBUTING file defines each project’s rules for this procedure (branch names, commit conventions, test requirements), so when asked which file to read first before contributing, the answer is CONTRIBUTING.

Profile and discovery features #

• Profile README — put a README in a repository named the same as your account and it appears as your introduction at the top of your profile.
• Stars — bookmark a repository; star counts serve as a signal of a project’s visibility.
• Following and trending — receive other users’ activity in your feed, and discover notable repositories through Explore and trending.

That completes the last piece of the seven domains. Now for the things to check before walking into the exam.

Exam tips — approaching each question type #

Foundations questions fall into three broad types.

• Definition matching — direct confirmation questions such as “what applies open source practices inside an organization?” These are this series’ tables flipped around, so read each table in both directions (name to definition, definition to name).
• Feature boundaries — pick the feature that fits a scenario out of two similar ones. Anywhere with a boundary is a candidate: plan differences, repository roles, Dependabot’s three features.
• UI location — “where do you check this information?” You should be able to recall the Insights tab layout and where settings live.

Commonly missed patterns #

• fork vs clone — a fork is a server-side copy under your GitHub account; a clone is a local copy on your machine. The first step of “contributing to someone else’s public repository” is fork.
• Issue vs Discussion — an Issue is work or a bug to track and close; a Discussion is an open-ended conversation for questions and ideas.
• github.dev vs Codespaces — github.dev is only a browser editor with no execution environment, while Codespaces is a full development environment running in the cloud. For “building from a terminal”, the answer is Codespaces.
• Write vs Maintain vs Admin — pushing and merging start at Write, repository settings at Maintain, and security settings and deletion are Admin only.
• Git vs GitHub — Git is the version control tool that runs locally; GitHub is the hosting service layering collaboration features on top. Filter out options that disguise GitHub-side features, like PRs, as Git commands.

Time management and the test environment #

• With around 75 questions in 120 minutes, you have more than 90 seconds per question. For the ones that stall you, flag and move on, then review at the end — better for your total score.
• For online proctored (PSI) sessions, check in advance that you have ID, a webcam, and a quiet space where screen sharing works, and run the exam software’s system check the day before. Follow the pre-exam guidance on desk-item restrictions as well.
• The passing bar and domain weights can change, so it is safest to look over the latest edition of the official study guide right before you sit the exam.

Wrapping up #

Three takeaways from this post.

• Open source is not merely public code but code whose license grants use, modification, and redistribution, and InnerSource applies that collaboration style inside an organization.
• Community features like Sponsors, Marketplace, and Skills are tested as one-to-one matches between name and purpose.
• Questions converge on three types — definition matching, feature boundaries, UI location — and reading the boundary tables in both directions is the best preparation.

The next post, “GitHub Foundations #10 Bonus — Full-Scale Practice Exam”, is the last in the series. It checks all seven domains with 50 questions in the same format as the real exam, each with an explanation attached.