7.5. Managing Organization Settings, Teams, and Roles
An organization's settings and team structure are what turn a flat list of members into something that actually maps to how a company is organized.
💡 First Principle: Organization settings control policy at the org level — default repository permissions, security requirements, billing — while teams group members for the purpose of granting access in bulk, rather than repository-by-repository per person. Teams can be nested, mirroring a real org chart (a "Backend" team nested under "Engineering," for example), and permissions granted to a parent team cascade down to nested teams. The organization owner role sits above everything — able to change billing, security policy, and membership itself.
⚠️ Exam Trap: Granting repository access to a team is not the same as granting it to each member individually and calling it done — team-based access stays current automatically as people join or leave the team, while individually granted access has to be revoked manually per person.
Reflection Question: An organization has a nested "Frontend" team under "Engineering." If "Engineering" is granted write access to a repository, does "Frontend" automatically inherit that access?
