Study guide
4.1 Repository Structure and Community Health Files
GitHub Foundations GH-900
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Domains, Scoring, and Candidate Profile 1.3 Official Resources and Hands-On Prep
2 Version Control Fundamentals
2.1 Purpose and Benefits of Version Control 2.2 Git vs GitHub 2.3 Repositories, Commits, and History 2.4 Branches, HEAD, and the Default Branch
3 Working with GitHub
3.1 Accounts, Organizations, and Enterprise Options 3.2 GitHub Flow 3.3 Markdown for Issues and Pull Requests 3.4 GitHub Desktop and GitHub Mobile
4 Repository Structure and Key Files
4.1 Repository Structure and Community Health Files 4.2 Creating Repositories with Templates and Branches 4.3 Adding and Managing Files
5 Repository Insights and Maintenance
5.1 Insights, Stars, Dashboards, and Dependency Insights 5.2 Repository Maintenance and Collaboration Best Practices
6 Issues and Pull Requests
6.1 Issues 6.2 Pull Requests 6.3 Linking PRs, Templates, Filters, and Assignments
7 Discussions, Notifications, and Documentation
7.1 Discussions 7.2 Notifications and Workflow Management 7.3 Gists, Wikis, and GitHub Pages
8 GitHub Actions
8.1 Actions Purpose, Workflows, and Events 8.2 Jobs, Steps, Runners, Secrets, and Reusable Actions
9 GitHub Copilot
9.1 Copilot Suggestions, Agents, Agent Mode, and Multi-Model Support 9.2 Copilot for Individuals, Business, and Enterprise
10 Codespaces and github.dev
10.1 Codespaces, Customization, and Dev Containers 10.2 github.dev vs Codespaces
11 Manage Projects with GitHub
11.1 GitHub Projects and Layout Options 11.2 Configuring Projects, Labels, Milestones, and Workflows 11.3 Saved Replies and Assignees 11.4 Project Insights
12 Account Security and Access
12.1 Two-Factor Authentication and Passkeys 12.2 Access Permissions and Roles 12.3 Enterprise Managed Users and Copilot Policy
13 Privacy, Branch Protection, and Organization Admin
13.1 Privacy, Visibility, and Branch Protection 13.2 Organization Settings, Teams, and Roles
14 Open Source, Sponsors, and InnerSource
14.1 Open Source Benefits and GitHub Sponsors 14.2 How GitHub Supports Open-Source Projects 14.3 InnerSource
15 Marketplace, Discovery, and Collaboration Models
15.1 Following Users and Organizations 15.2 GitHub Marketplace 15.3 Forks, Templates, and Discoverable Repositories
4.1 Repository Structure and Community Health Files
Key Takeaways Explain This Topic AI
GitHub looks for README, CONTRIBUTING, CODE_OF_CONDUCT, and CODEOWNERS in .github/, then the repository root, then docs/, and uses the first match.
CODEOWNERS automatically requests reviews on pull requests that touch owned paths, but not on draft pull requests; listed users and teams must have write permission.
SECURITY.md is the repository security policy: it tells people how to report a vulnerability and GitHub links it from the Security tab.
A public repository named .github can supply default community health files for other repositories the account owns; LICENSE cannot be one of those defaults.
Issue templates belong in .github/ISSUE_TEMPLATE on the default branch; pull request templates may live in .github/, the root, or docs/ on the default branch.
Last updated: August 2026
Why GH-900 starts Domain 2 with files
Domain 2 of GitHub Foundations (GH-900) is 10–15% of the exam and opens with describe the structure and key files of a GitHub repository . The official skill lists five names: README , LICENSE , CONTRIBUTING , CODEOWNERS , and SECURITY . The same GitHub Docs cluster also covers CODE_OF_CONDUCT.md , .gitignore , and issue and pull request templates under .github/ . The question is not “can you memorize filenames.” It is whether you can tell a first-time visitor, a new contributor, a required reviewer, and a security researcher which file to open and which folder GitHub will actually read .
A repository holds a project’s files and each file’s Git history. GitHub then surfaces a short list of conventional filenames on the repository home, on the new-issue and new-pull-request screens, in Insights → Community Standards , and on the Security tab. Put the right file in the wrong directory and the community checklist stays incomplete, the contribute link is missing, or code owners never get a review request. That location-and-behavior pairing is what GH-900 tests.
GitHub searches most community files in this order: the .github/ folder, then the repository root , then docs/ . The first file it finds wins. Remember that order; several exam items collapse to “which copy is shown.”
- The five files the outline names
- README
A README is usually the first thing a visitor sees. GitHub renders it on the repository home. Typical contents: what the project does, why it is useful, how to get started, where to get help, and who maintains it. GitHub recognizes a README in .github/ , the root, or docs/ . If more than one exists, display order is .github , then root, then docs . Rendered Markdown beyond 500 KiB is truncated. A public repository whose name matches your username becomes your profile README . Keep the README short enough to start; longer documentation belongs in a wiki or docs site, which Domain 3 covers separately.
LICENSE
A LICENSE (commonly LICENSE , LICENSE.md , or LICENSE.txt in the root ) states what others may do with the code. GitHub’s create-repository license picker and choosealicense.com help you pick a known license such as MIT or Apache-2.0. When GitHub’s detector recognizes the file, the license name appears at the top of the repository page. You are not required to add a license, but without one default copyright applies: you retain all rights, and nobody may reproduce, distribute, or create derivative works. Public repositories may still be viewed and forked under GitHub’s Terms of Service—that is not the same as an open-source grant. You cannot ship a default LICENSE from the account-level .github repository. License files must live in each project so they are included when someone clones, packages, or downloads it.
CONTRIBUTING
CONTRIBUTING.md (the filename is not case-sensitive) tells people how to contribute: how to open a useful issue, how to send a pull request, links to external docs or a code of conduct, and community expectations. Store it in .github/ , the root, or docs/ . When someone opens an issue or pull request, GitHub shows a link to that file. GitHub also surfaces it on the repository contribute page, as a Contributing tab in the overview, and as a sidebar link. If several CONTRIBUTING files exist, GitHub again prefers .github , then root, then docs .
CODEOWNERS
A CODEOWNERS file maps path patterns to people or teams using @username or @org/team-name . When someone opens a pull request that modifies owned paths, GitHub automatically requests a review from those owners. Draft pull requests do not auto-request code owners; marking the draft ready for review does. Every listed user, and every listed team, must have write permission on the repository; a team must also be visible . GitHub looks for the file in .github/ , then the root, then docs/ , and uses the first match. The copy that fires review requests is the one on the base branch of the pull request. Last matching pattern wins. The file must stay under 3 MB or GitHub will not load it. CODEOWNERS syntax follows most gitignore rules, but GitHub does not honor ! negation, [ ] character ranges, or escaping # with a backslash. Paths are case-sensitive . Branch protection (or a ruleset) can add a second switch: Require review from Code Owners . When that option is on, approval from any one of the owners listed for a path is enough.
SECURITY.md
SECURITY.md is the repository security policy . It tells researchers how to report a vulnerability—and often which versions you still support—instead of filing a public issue. GitHub links it from the Security (or Security and quality) tab; Start setup drafts the file for you. GitHub’s own repository docs also recommend a security policy as part of hardening a public codebase. A public repository without SECURITY.md fails that row of the Community Standards checklist.
Files the exam still expects you to place
File or folder Job Where GitHub looks Exam trap
README Project intro rendered on the home page .github/ , root, then docs/ Extra copies are ignored after the first match
LICENSE / LICENSE.md Grants reuse rights; detected license badge Root of this repository Cannot be an org-wide default in .github
CONTRIBUTING.md How to send issues and pull requests .github/ , root, then docs/ Linked from new issues, new PRs, and the contribute page
CODEOWNERS Auto-request reviewers by path .github/ , root, then docs/ No auto-request on draft PRs; write access required
SECURITY.md How to report vulnerabilities Same community-file search; Security tab Not the same as Dependabot or secret scanning
CODE_OF_CONDUCT.md Behavior standards and enforcement .github/ , root, or docs/ Community-profile check prefers GitHub’s templates
.gitignore Paths Git should not stage Almost always the repository root Does not untrack files already committed
.github/ISSUE_TEMPLATE/ Issue templates and config.yml Default branch only Markdown needs name: and about: ; forms need name: and description:
PR template (for example PULL_REQUEST_TEMPLATE.md) Pre-fills the pull request body Root, docs/ , or .github/ on the default branch A template on a feature branch is invisible
.gitignore lists files and directories Git should skip when you commit. Commit the file so every clone shares the same ignore rules. On github.com/new , GitHub can drop in a language-specific template from the github/gitignore collection. Adding a pattern later does not stop Git from tracking a file that is already in history—that is a 4.3 trap ( git rm --cached ).
CODE_OF_CONDUCT.md defines how people should engage and how abuse is handled. GitHub ships templates such as Contributor Covenant. Using a GitHub template is what marks Code of conduct complete on the community profile; a hand-pasted custom file still exists in the tree but may not check that box.
Issue templates must live in .github/ISSUE_TEMPLATE on the default branch . Markdown templates need YAML front matter with name: and about: . Issue forms use .yml with name: and description: . A config.yml in that folder customizes the template chooser. Pull request templates may live in the visible root, docs/ , or hidden .github/ (classic name: PULL_REQUEST_TEMPLATE.md ), also on the default branch. Templates created on any other branch are not offered to collaborators.
On a public repository, open Insights → Community Standards to see the maintainer checklist. Missing files show Add (maintainers) or Propose (outside contributors).
Loading diagram... Where GitHub looks for community health files
Account-wide defaults: a public repository named .github
A folder named .github/ inside a project is not the same thing as a repository named .github . Create a public repository called .github on a user account or organization. Default community health files stored there apply to any other repository that account owns if that repository does not already have its own file of the same type . Supported defaults include CODE_OF_CONDUCT.md , CONTRIBUTING.md , SECURITY.md , SUPPORT.md , FUNDING.yml , GOVERNANCE.md , discussion category forms, and issue and pull request templates (issue templates and config.yml must sit in .github/ISSUE_TEMPLATE inside that defaults repo).
Two override rules matter on the exam. First, LICENSE is not supported as a default —each repository needs its own license file. Second, if a repository has any files in its own .github/ISSUE_TEMPLATE folder, GitHub uses none of the default issue templates. Defaults do not appear in the file browser, Git history, clones, packages, or downloads of the consuming repositories, which is why they are convenient for organizations and useless as a substitute for LICENSE. The .github repository must be public . A private .github repo does not publish these defaults.
Exam scenarios and traps
CODEOWNERS is not a polite comment. It auto-requests reviewers. Requiring those reviewers to approve is a separate branch-protection or ruleset checkbox. Draft PRs skip the auto-request.
Write permission is mandatory. Listing @docs-team without granting that team write (and visibility) means no code owner is assigned.
Search order is not “root first.” For README, CONTRIBUTING, CODEOWNERS, and similar files, .github/ beats the root, which beats docs/ .
SECURITY.md is the reporting policy , not secret scanning, Dependabot, or a SECURITY.md-shaped README paragraph. GitHub wants the dedicated file so the Security tab can link it.
Issue templates in any folder except .github/ISSUE_TEMPLATE , or on a non-default branch, do not count for the community-profile checkmark.
The .github repository vs the .github/ folder. Org-wide CONTRIBUTING lives in a public repo named .github . Per-repo Actions workflows and issue templates live in a folder named .github/ inside each project.
No license is not “public domain.” Public visibility plus fork rights under the Terms of Service is not an open-source license.
GH-900 will phrase this as short stories: a maintainer who added CONTRIBUTING.md under docs/ while another copy sits in .github/ ; a draft pull request that “should have” requested @security ; an organization that put LICENSE only in the .github defaults repo; a researcher who opened a public issue because SECURITY.md was missing. Match the story to the file, the folder, and the GitHub surface that should have appeared.