{"id":78750,"date":"2026-09-26T05:53:26","date_gmt":"2026-09-26T05:53:26","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=78750"},"modified":"2026-09-26T05:53:28","modified_gmt":"2026-09-26T05:53:28","slug":"github-organization-administration-essentials-2-hour-tutorial","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/github-organization-administration-essentials-2-hour-tutorial\/","title":{"rendered":"GitHub Organization Administration Essentials \u2014 2-Hour Tutorial"},"content":{"rendered":"\n
\n

Last Verified:<\/strong> September 2026
Based on:<\/strong> GitHub Organization Administration \u2014 Complete Reference Guide and Tutorial<\/em>
Duration:<\/strong> 2 hours
Audience:<\/strong> GitHub organization owners, DevOps\/platform engineers, developers with delegated administration duties, security administrators, and technical trainers.<\/p>\n<\/blockquote>\n\n\n\n

This is the Essentials<\/strong> version of the complete GitHub Organization Administration guide. It intentionally removes deep enterprise, migration, AI-governance, advanced networking, and large-scale automation material so a learner can understand and practice the core administration model in about two hours<\/strong>.<\/p>\n\n\n\n

The goal is not to memorize every GitHub setting. The goal is to understand the few administration layers that control almost everything:<\/p>\n\n\n

Identity -> Teams and roles -> Repository access -> Policies -> CI\/CD and security -> Audit\n<\/code><\/span><\/pre>\n\n\n
By the end of this tutorial, a learner should be able to safely administer a small or medium GitHub organization and understand how the same model scales to enterprise environments.<\/p>\n\n\n\n
\n\n\n\n
1. Two-Hour Learning Plan<\/h2>\n\n\n\n
Time<\/th>Module<\/th>Outcome<\/th><\/tr><\/thead>
0\u201310 min<\/td>Organization foundations<\/td>Understand what an organization is and how administration is layered<\/td><\/tr>
10\u201330 min<\/td>People, teams, and roles<\/td>Build a maintainable access model<\/td><\/tr>
30\u201350 min<\/td>Repository access and governance<\/td>Control repository creation, visibility, and permissions<\/td><\/tr>
50\u201370 min<\/td>Rulesets and custom properties<\/td>Apply policy centrally instead of configuring every repository manually<\/td><\/tr>
70\u201390 min<\/td>GitHub Actions administration<\/td>Control workflow permissions, actions, runners, secrets, and cloud access<\/td><\/tr>
90\u2013105 min<\/td>Security, apps, tokens, and audit<\/td>Protect identities and programmatic access and investigate changes<\/td><\/tr>
105\u2013115 min<\/td>Hands-on organization baseline<\/td>Put the essentials together in one practical exercise<\/td><\/tr>
115\u2013120 min<\/td>Review and knowledge check<\/td>Confirm the key administration principles<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
What is intentionally outside this 2-hour scope?<\/h3>\n\n\n\n
The complete reference guide should be used later for:<\/p>\n\n\n\n
    \n
  • SAML SSO implementation details<\/li>\n\n\n\n
  • SCIM provisioning<\/li>\n\n\n\n
  • Enterprise Managed Users<\/li>\n\n\n\n
  • IP allow lists<\/li>\n\n\n\n
  • Codespaces administration<\/li>\n\n\n\n
  • Copilot, agents, MCP, and AI governance<\/li>\n\n\n\n
  • GitHub Packages administration<\/li>\n\n\n\n
  • GitHub Pages and Discussions administration<\/li>\n\n\n\n
  • Advanced Security and Code Quality rollout<\/li>\n\n\n\n
  • Organization migration<\/li>\n\n\n\n
  • GitHub Enterprise Importer<\/li>\n\n\n\n
  • Detailed billing administration<\/li>\n\n\n\n
  • REST and GraphQL automation<\/li>\n\n\n\n
  • Terraform administration<\/li>\n\n\n\n
  • SIEM and audit streaming<\/li>\n\n\n\n
  • Enterprise-scale operating models<\/li>\n<\/ul>\n\n\n\n
    These are important, but they are not prerequisites for understanding core organization administration<\/strong>.<\/p>\n\n\n\n
    \n\n\n\n
    Module 1 \u2014 GitHub Organization Foundations<\/h1>\n\n\n\n
    2. What Is a GitHub Organization?<\/h2>\n\n\n\n
    A GitHub Organization is a shared account used to hold and govern software resources for a team or company.<\/p>\n\n\n\n
    An organization can contain or control:<\/p>\n\n\n\n
      \n
    • Repositories<\/li>\n\n\n\n
    • Teams<\/li>\n\n\n\n
    • Members and owners<\/li>\n\n\n\n
    • Projects<\/li>\n\n\n\n
    • Packages<\/li>\n\n\n\n
    • GitHub Actions<\/li>\n\n\n\n
    • Runners<\/li>\n\n\n\n
    • Secrets and variables<\/li>\n\n\n\n
    • Security controls<\/li>\n\n\n\n
    • GitHub Apps and integrations<\/li>\n\n\n\n
    • Billing and usage<\/li>\n\n\n\n
    • Audit logs<\/li>\n<\/ul>\n\n\n\n
      An organization is normally not a login identity<\/strong>. People sign in with their own GitHub accounts and receive organization, team, repository, or delegated administrative permissions.<\/p>\n\n\n\n
      3. The Organization Administration Mental Model<\/h2>\n\n\n
      flowchart<\/span> TD<\/span>\n    U<\/span>[Users]<\/span> --<\/span>> T<\/span>[Teams and Roles]<\/span>\n    T<\/span> --<\/span>> R<\/span>[Repository Access]<\/span>\n    R<\/span> --<\/span>> P<\/span>[Policies and Rulesets]<\/span>\n    P<\/span> --<\/span>> A<\/span>[Actions and Security]<\/span>\n    A<\/span> --<\/span>> L<\/span>[Audit and Monitoring]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
      Think of GitHub organization administration in layers:<\/p>\n\n\n\n
        \n
      1. Identity<\/strong>\u00a0\u2014 Who is the user or automation?<\/li>\n\n\n\n
      2. Role or team<\/strong>\u00a0\u2014 What group or administrative responsibility do they have?<\/li>\n\n\n\n
      3. Repository access<\/strong>\u00a0\u2014 Which repositories can they access and at what level?<\/li>\n\n\n\n
      4. Policy<\/strong>\u00a0\u2014 What actions remain allowed even after access is granted?<\/li>\n\n\n\n
      5. Automation and security<\/strong>\u00a0\u2014 What can workflows, runners, secrets, Apps, and tokens do?<\/li>\n\n\n\n
      6. Audit<\/strong>\u00a0\u2014 Can you explain who changed what and when?<\/li>\n<\/ol>\n\n\n\n
        This model is more useful than memorizing the GitHub Settings menu.<\/p>\n\n\n\n
        4. Organization vs Personal Account<\/h2>\n\n\n\n
        Capability<\/th>Personal account<\/th>Organization<\/th><\/tr><\/thead>
        Login identity<\/td>Yes<\/td>Normally no<\/td><\/tr>
        Own repositories<\/td>Yes<\/td>Yes<\/td><\/tr>
        Teams<\/td>No<\/td>Yes<\/td><\/tr>
        Central repository governance<\/td>Limited<\/td>Yes<\/td><\/tr>
        Organization roles<\/td>No<\/td>Yes<\/td><\/tr>
        Organization Actions policy<\/td>No<\/td>Yes<\/td><\/tr>
        Central security controls<\/td>No<\/td>Yes<\/td><\/tr>
        Organization audit log<\/td>No<\/td>Yes<\/td><\/tr>
        Billing delegation<\/td>Personal<\/td>Owners \/ billing managers<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
        5. Organization Owners<\/h2>\n\n\n\n
        Organization owners have very broad administrative authority.<\/p>\n\n\n\n
        Typical owner capabilities include:<\/p>\n\n\n\n
          \n
        • Managing organization settings<\/li>\n\n\n\n
        • Managing membership<\/li>\n\n\n\n
        • Managing teams and roles<\/li>\n\n\n\n
        • Accessing all organization repositories<\/li>\n\n\n\n
        • Configuring policies<\/li>\n\n\n\n
        • Managing application access<\/li>\n\n\n\n
        • Reviewing audit information<\/li>\n\n\n\n
        • Performing organization lifecycle operations<\/li>\n<\/ul>\n\n\n\n
          Recommended ownership model<\/h3>\n\n\n\n
          Use at least two capable owners for continuity<\/strong>, while keeping the owner population small.<\/p>\n\n\n
          2\u20134 trusted owners\n        |\n        +-- Security administration -> delegated security role\/team\n        +-- CI\/CD administration -> delegated CI\/CD role\n        +-- Billing -> billing manager\n        +-- GitHub Apps -> App Manager\n        +-- Normal development -> teams + repository roles\n<\/code><\/span><\/pre>\n\n\n
          Do not solve every administration requirement by making someone an owner.<\/p>\n\n\n\n
          Essential rule<\/h3>\n\n\n\n
          \n
          Owner is a break-glass\/high-authority role, not the default senior-engineer role.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
          \n\n\n\n
          Module 2 \u2014 People, Teams, and Roles<\/h1>\n\n\n\n
          6. The Main Human Access Types<\/h2>\n\n\n\n
          Type<\/th>Meaning<\/th>Typical use<\/th><\/tr><\/thead>
          Owner<\/td>Full organization administration<\/td>Small trusted admin group<\/td><\/tr>
          Member<\/td>Normal organization participant<\/td>Employees and regular contributors<\/td><\/tr>
          Outside collaborator<\/td>Access to selected repositories without normal membership<\/td>Contractors, vendors, auditors<\/td><\/tr>
          Billing manager<\/td>Billing administration without full organization ownership<\/td>Finance \/ procurement<\/td><\/tr>
          Team maintainer<\/td>Delegated management of a team<\/td>Engineering lead \/ manager<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
          7. Members vs Outside Collaborators<\/h2>\n\n\n\n
          A member<\/strong> belongs to the organization and can participate in teams and organization workflows.<\/p>\n\n\n\n
          An outside collaborator<\/strong> normally receives access only to specific repositories.<\/p>\n\n\n\n
          Example<\/h3>\n\n\n\n
          A contractor needs access to one repository for six weeks.<\/p>\n\n\n\n
          Better model:<\/p>\n\n\n
          Contractor\n   |\n   +-- Outside collaborator\n           |\n           +-- payments-api : Write\n<\/code><\/span><\/pre>\n\n\n
          Avoid making the contractor a full member unless they genuinely need organization-wide membership capabilities.<\/p>\n\n\n\n
          8. Teams \u2014 The Preferred Access Boundary<\/h2>\n\n\n\n
          Teams are the most important tool for scalable GitHub access management.<\/p>\n\n\n\n
          Without teams:<\/p>\n\n\n
          Alice -> repo-a\nBob   -> repo-a\nCarol -> repo-a\nAlice -> repo-b\nBob   -> repo-b\n...\n<\/code><\/span><\/pre>\n\n\n
          With teams:<\/p>\n\n\n
          Alice ----+\nBob ------+--> payments-team --> payments repositories\nCarol ----+\n<\/code><\/span><\/pre>\n\n\n
          Why teams are better<\/h3>\n\n\n\n
            \n
          • Easier onboarding<\/li>\n\n\n\n
          • Easier offboarding<\/li>\n\n\n\n
          • Easier access review<\/li>\n\n\n\n
          • Easier repository ownership<\/li>\n\n\n\n
          • Easier CODEOWNERS integration<\/li>\n\n\n\n
          • Easier permission changes<\/li>\n\n\n\n
          • Less direct-user permission drift<\/li>\n<\/ul>\n\n\n\n
            9. Example Team Structure<\/h2>\n\n\n
            engineering\n\u251c\u2500\u2500 platform\n\u2502   \u251c\u2500\u2500 sre\n\u2502   \u2514\u2500\u2500 developer-experience\n\u251c\u2500\u2500 backend\n\u251c\u2500\u2500 mobile\n\u2514\u2500\u2500 security\n<\/code><\/span><\/pre>\n\n\n
            Use hierarchy only when it represents a meaningful organizational or permission relationship.<\/p>\n\n\n\n
            Do not create deep team trees just because GitHub supports them.<\/p>\n\n\n\n
            10. Team Repository Permissions<\/h2>\n\n\n\n
            GitHub’s standard repository roles are:<\/p>\n\n\n\n
            Role<\/th>What it is for<\/th><\/tr><\/thead>
            Read<\/td>View and discuss code<\/td><\/tr>
            Triage<\/td>Manage issues and pull requests without code write access<\/td><\/tr>
            Write<\/td>Normal developer contribution and push access<\/td><\/tr>
            Maintain<\/td>Repository operations without the most sensitive admin actions<\/td><\/tr>
            Admin<\/td>Full repository administration<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            Practical mapping<\/h3>\n\n\n
            platform-readers  -> Read\nplatform-dev      -> Write\nplatform-maint    -> Maintain\nplatform-admin    -> Admin only when necessary\n<\/code><\/span><\/pre>\n\n\n
            Least-privilege question<\/h3>\n\n\n\n
            Before granting a role, ask:<\/p>\n\n\n\n
            \n
            What is the lowest role that allows this person or team to do their job?<\/p>\n<\/blockquote>\n\n\n\n
            If Write<\/code> works, do not grant Admin<\/code>.<\/p>\n\n\n\n
            11. Base Repository Permission<\/h2>\n\n\n\n
            Base permission is the default repository access granted to organization members.<\/p>\n\n\n\n
            A conservative model is:<\/p>\n\n\n
            Base permission: None or Read\nNormal developer access: through teams\nAdmin access: exceptional and reviewed\n<\/code><\/span><\/pre>\n\n\n
            Effective access<\/h3>\n\n\n
            flowchart<\/span> TD<\/span>\n    B<\/span>[Base Permission]<\/span> --<\/span>> E<\/span>[Effective Repository Access]<\/span>\n    T<\/span>[Team Permission]<\/span> --<\/span>> E<\/span>\n    D<\/span>[Direct Grant]<\/span> --<\/span>> E<\/span>\n    E<\/span> --<\/span>> G<\/span>[Repository Rules Still Apply]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Permission tells GitHub what the user is allowed to attempt.<\/p>\n\n\n\n
            Rulesets and other governance can still restrict what the user may actually do.<\/p>\n\n\n\n
            12. Delegated Administration<\/h2>\n\n\n\n
            Not every administrative function needs organization ownership.<\/p>\n\n\n\n
            Use delegated roles where supported:<\/p>\n\n\n\n
            Responsibility<\/th>Better role<\/th><\/tr><\/thead>
            Security administration<\/td>Security Manager<\/td><\/tr>
            Billing<\/td>Billing Manager<\/td><\/tr>
            Actions \/ CI administration<\/td>CI\/CD administrative role<\/td><\/tr>
            GitHub App registration<\/td>App Manager<\/td><\/tr>
            Moderation<\/td>Moderator<\/td><\/tr>
            Team membership<\/td>Team Maintainer<\/td><\/tr>
            Repository operations<\/td>Maintain \/ Admin repository role<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            Essential rule<\/h3>\n\n\n\n
            \n
            Use owner only when the job genuinely requires organization-wide authority.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
            \n\n\n\n
            Module 3 \u2014 Repository Access and Governance<\/h1>\n\n\n\n
            13. Repository Lifecycle<\/h2>\n\n\n\n
            Repositories move through a lifecycle:<\/p>\n\n\n
            flowchart<\/span> LR<\/span>\n    C<\/span>[Create]<\/span> --<\/span>> A<\/span>[Active]<\/span>\n    A<\/span> --<\/span>> X<\/span>[Archive]<\/span>\n    X<\/span> --<\/span>> A<\/span>\n    A<\/span> --<\/span>> T<\/span>[Transfer]<\/span>\n    A<\/span> --<\/span>> D<\/span>[Delete]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Important administrative operations include:<\/p>\n\n\n\n
              \n
            • Create<\/li>\n\n\n\n
            • Import<\/li>\n\n\n\n
            • Change visibility<\/li>\n\n\n\n
            • Transfer<\/li>\n\n\n\n
            • Archive \/ unarchive<\/li>\n\n\n\n
            • Delete \/ restore when eligible<\/li>\n<\/ul>\n\n\n\n
              14. Repository Visibility<\/h2>\n\n\n\n
              Visibility<\/th>Main audience<\/th><\/tr><\/thead>
              Public<\/td>Anyone on the internet<\/td><\/tr>
              Private<\/td>Explicitly authorized users, teams, and integrations<\/td><\/tr>
              Internal<\/td>Eligible enterprise users across enterprise organizations<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
              Changing repository visibility can expose much more than source files.<\/p>\n\n\n\n
              Potentially affected data can include:<\/p>\n\n\n\n
                \n
              • Code<\/li>\n\n\n\n
              • Issues<\/li>\n\n\n\n
              • Pull requests<\/li>\n\n\n\n
              • Releases<\/li>\n\n\n\n
              • Actions history<\/li>\n\n\n\n
              • Repository metadata<\/li>\n\n\n\n
              • Pages or package relationships<\/li>\n<\/ul>\n\n\n\n
                Therefore, visibility changes should be treated as a governance decision.<\/p>\n\n\n\n
                15. Member Privileges<\/h2>\n\n\n\n
                Organization settings can govern what normal members may do.<\/p>\n\n\n\n
                Important questions include:<\/p>\n\n\n\n
                  \n
                • Can members create repositories?<\/li>\n\n\n\n
                • Can they create public repositories?<\/li>\n\n\n\n
                • Can they change repository visibility?<\/li>\n\n\n\n
                • Can they delete repositories?<\/li>\n\n\n\n
                • Can they transfer repositories?<\/li>\n\n\n\n
                • Can they create teams?<\/li>\n\n\n\n
                • Can they install or request GitHub Apps?<\/li>\n<\/ul>\n\n\n\n
                  Sensible starting point for a governed company organization<\/h3>\n\n\n\n
                  Capability<\/th>Starting position<\/th><\/tr><\/thead>
                  Create private repositories<\/td>Allow only if self-service creation is intentional<\/td><\/tr>
                  Create public repositories<\/td>Restrict unless open-source publishing is expected<\/td><\/tr>
                  Change visibility<\/td>Restricted \/ governed<\/td><\/tr>
                  Delete repositories<\/td>Restricted and auditable<\/td><\/tr>
                  Transfer outside organization<\/td>Restricted<\/td><\/tr>
                  Install GitHub Apps<\/td>Approved process<\/td><\/tr>
                  Create teams<\/td>Centralized or intentionally delegated<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                  The objective is not to lock everything down.<\/p>\n\n\n\n
                  The objective is to make high-risk actions deliberate<\/strong> while allowing routine engineering work to remain fast.<\/p>\n\n\n\n
                  16. Pull Request Governance<\/h2>\n\n\n\n
                  Common protections for important branches include:<\/p>\n\n\n\n
                    \n
                  • Require pull requests before merge<\/li>\n\n\n\n
                  • Require approvals<\/li>\n\n\n\n
                  • Require CODEOWNER review<\/li>\n\n\n\n
                  • Require status checks<\/li>\n\n\n\n
                  • Dismiss stale approvals when appropriate<\/li>\n\n\n\n
                  • Restrict force pushes<\/li>\n\n\n\n
                  • Restrict branch deletion<\/li>\n\n\n\n
                  • Require signed commits when needed<\/li>\n\n\n\n
                  • Use merge queue when appropriate<\/li>\n<\/ul>\n\n\n\n
                    For multiple repositories, prefer organization-level rulesets<\/strong> instead of configuring protections independently on every repository.<\/p>\n\n\n\n
                    \n\n\n\n
                    Module 4 \u2014 Rulesets and Custom Properties<\/h1>\n\n\n\n
                    17. Why Rulesets Matter<\/h2>\n\n\n\n
                    Rulesets let administrators apply repository policy centrally.<\/p>\n\n\n\n
                    Without rulesets:<\/p>\n\n\n
                    repo-a -> branch settings\nrepo-b -> branch settings\nrepo-c -> branch settings\nrepo-d -> branch settings\n<\/code><\/span><\/pre>\n\n\n
                    Over time, these settings drift.<\/p>\n\n\n\n
                    With organization rulesets:<\/p>\n\n\n
                    Organization policy\n       |\n       +--> matching repository A\n       +--> matching repository B\n       +--> matching repository C\n<\/code><\/span><\/pre>\n\n\n
                    18. Typical Ruleset Controls<\/h2>\n\n\n\n
                    Rulesets can enforce controls such as:<\/p>\n\n\n\n
                      \n
                    • Pull request required<\/li>\n\n\n\n
                    • Approval required<\/li>\n\n\n\n
                    • CODEOWNER review<\/li>\n\n\n\n
                    • Required status checks<\/li>\n\n\n\n
                    • No force push<\/li>\n\n\n\n
                    • No branch deletion<\/li>\n\n\n\n
                    • Signed commits<\/li>\n\n\n\n
                    • Linear history<\/li>\n\n\n\n
                    • Merge queue where applicable<\/li>\n\n\n\n
                    • Tag restrictions<\/li>\n\n\n\n
                    • Push restrictions<\/li>\n<\/ul>\n\n\n\n
                      19. What Are Custom Properties?<\/h2>\n\n\n\n
                      Custom properties are structured metadata attached to repositories.<\/p>\n\n\n\n
                      Useful examples:<\/p>\n\n\n\n
                      Property<\/th>Example values<\/th><\/tr><\/thead>
                      owner_team<\/code><\/td>platform<\/code>, payments<\/code>, mobile<\/code><\/td><\/tr>
                      service_tier<\/code><\/td>tier-1<\/code>, tier-2<\/code>, tier-3<\/code><\/td><\/tr>
                      data_classification<\/code><\/td>public<\/code>, internal<\/code>, confidential<\/code><\/td><\/tr>
                      production<\/code><\/td>true<\/code>, false<\/code><\/td><\/tr>
                      lifecycle<\/code><\/td>active<\/code>, maintenance<\/code>, deprecated<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                      20. Properties + Rulesets = Dynamic Governance<\/h2>\n\n\n\n
                      This is one of the most useful GitHub organization patterns.<\/p>\n\n\n\n
                      Example:<\/p>\n\n\n
                      Repository: payments-api\nservice_tier = tier-1<\/span>\nowner_team   = payments\nproduction   = true<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                      Then create a ruleset that says:<\/p>\n\n\n
                      If service_tier = tier-1<\/span>\nthen\n  require<\/span> pull request\n  require<\/span> approvals\n  require<\/span> CI checks\n  block force push\n  block default<\/span>-branch deletion\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                      Now every repository classified as tier-1<\/code> can receive the same policy automatically.<\/p>\n\n\n\n
                      21. Recommended Rollout<\/h2>\n\n\n\n
                        \n
                      1. Define only a few high-value properties.<\/li>\n\n\n\n
                      2. Set values on test repositories.<\/li>\n\n\n\n
                      3. Create a ruleset targeting those repositories.<\/li>\n\n\n\n
                      4. Test normal development behavior.<\/li>\n\n\n\n
                      5. Test admin and emergency behavior.<\/li>\n\n\n\n
                      6. Review bypass permissions.<\/li>\n\n\n\n
                      7. Expand the target set gradually.<\/li>\n<\/ol>\n\n\n\n
                        Avoid<\/h3>\n\n\n\n
                          \n
                        • Hundreds of free-text properties<\/li>\n\n\n\n
                        • Bypass access for large groups<\/li>\n\n\n\n
                        • Organization-wide enforcement without testing<\/li>\n\n\n\n
                        • Required status checks whose workflow names are inconsistent<\/li>\n\n\n\n
                        • Using repository naming alone as your governance database<\/li>\n<\/ul>\n\n\n\n
                          \n\n\n\n
                          Module 5 \u2014 GitHub Actions Administration Essentials<\/h1>\n\n\n\n
                          22. Why Actions Is an Organization Administration Concern<\/h2>\n\n\n\n
                          GitHub Actions is an execution platform.<\/p>\n\n\n\n
                          It can:<\/p>\n\n\n\n
                            \n
                          • Run arbitrary code<\/li>\n\n\n\n
                          • Use repository permissions<\/li>\n\n\n\n
                          • Read secrets<\/li>\n\n\n\n
                          • Publish packages<\/li>\n\n\n\n
                          • Call cloud APIs<\/li>\n\n\n\n
                          • Deploy applications<\/li>\n\n\n\n
                          • Access internal networks through runners<\/li>\n<\/ul>\n\n\n\n
                            Therefore, Actions must be governed like other production automation systems.<\/p>\n\n\n\n
                            23. The Five Actions Control Layers<\/h2>\n\n\n
                            flowchart<\/span> TD<\/span>\n    P<\/span>[Actions Policy]<\/span> --<\/span>> W<\/span>[Workflow Permissions]<\/span>\n    W<\/span> --<\/span>> C<\/span>[Allowed Actions]<\/span>\n    C<\/span> --<\/span>> R<\/span>[Runners]<\/span>\n    R<\/span> --<\/span>> S<\/span>[Secrets and OIDC]<\/span>\n    S<\/span> --<\/span>> M<\/span>[Audit and Usage]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                            Layer 1 \u2014 Is Actions allowed?<\/h3>\n\n\n\n
                            An organization can allow, limit, or disable Actions according to policy.<\/p>\n\n\n\n
                            Layer 2 \u2014 What may GITHUB_TOKEN<\/code> do?<\/h3>\n\n\n\n
                            A strong baseline is:<\/p>\n\n\n
                            Default<\/span> GITHUB_TOKEN: restricted \/ read-oriented\nWorkflow: request extra permissions explicitly\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                            Example:<\/p>\n\n\n
                            name<\/span>: test\n\non:\n  push:\n    branches: [main]\n\npermissions:\n  contents: read\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\/checkout@<FULL_COMMIT_SHA>\n      - run: npm ci\n      - run: npm test\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                            The workflow requests only the permission it needs.<\/p>\n\n\n\n
                            Layer 3 \u2014 Which Actions are trusted?<\/h3>\n\n\n\n
                            Possible organization strategies include:<\/p>\n\n\n\n
                            Maturity<\/th>Example policy<\/th><\/tr><\/thead>
                            Basic<\/td>Allow GitHub and verified actions<\/td><\/tr>
                            Controlled<\/td>Allow approved third-party actions<\/td><\/tr>
                            Higher assurance<\/td>Allowlist plus immutable SHA pinning<\/td><\/tr>
                            Regulated<\/td>Approved reusable workflows and controlled runner groups<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                            Third-party Actions are code dependencies and should be reviewed accordingly.<\/p>\n\n\n\n
                            Layer 4 \u2014 Where does the workflow run?<\/h3>\n\n\n\n
                            Runner types include:<\/p>\n\n\n\n
                              \n
                            • GitHub-hosted runners<\/li>\n\n\n\n
                            • Larger GitHub-hosted runners<\/li>\n\n\n\n
                            • Self-hosted runners<\/li>\n\n\n\n
                            • Autoscaled or ephemeral self-hosted runners<\/li>\n<\/ul>\n\n\n\n
                              Runner groups can restrict which repositories or workflows may use a runner set.<\/p>\n\n\n\n
                              Example trust separation:<\/p>\n\n\n
                              general-ci       -> normal builds and<\/span> tests\ninternal-ci      -> private<\/span> internal workloads\nstaging-deploy   -> selected deployment workflows\nprod-deploy      -> tightly restricted production deployment workflows\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                              Do not give every repository access to a privileged production runner.<\/p>\n\n\n\n
                              Layer 5 \u2014 How are credentials provided?<\/h3>\n\n\n\n
                              Prefer:<\/p>\n\n\n
                              GitHub permissions -> GITHUB_TOKEN\nCloud credentials  -> OIDC where practical\nShared configuration -> organization variables\nSecrets -> minimum required repository scope\n<\/code><\/span><\/pre>\n\n\n
                              24. Organization Secrets vs Variables<\/h2>\n\n\n\n
                              Secrets<\/h3>\n\n\n\n
                              Use for sensitive values.<\/p>\n\n\n\n
                              Examples:<\/p>\n\n\n\n
                                \n
                              • API tokens<\/li>\n\n\n\n
                              • Passwords<\/li>\n\n\n\n
                              • Signing material<\/li>\n<\/ul>\n\n\n\n
                                Scope secrets only to repositories that require them.<\/p>\n\n\n\n
                                Example:<\/p>\n\n\n
                                gh secret set<\/span> DEPLOY_TOKEN \\\n  --org acme \\\n  --visibility selected \\\n  --repos api,worker\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                Variables<\/h3>\n\n\n\n
                                Use for non-secret configuration.<\/p>\n\n\n
                                gh variable set<\/span> DEFAULT_REGION \\\n  --org acme \\\n  --body \"ap-northeast-1\" \\\n  --visibility selected \\\n  --repos api,worker\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                Essential rule<\/h3>\n\n\n\n
                                \n
                                A shared organization secret creates a shared blast radius. Scope it deliberately.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
                                25. OIDC Instead of Long-Lived Cloud Keys<\/h2>\n\n\n\n
                                GitHub Actions can use OpenID Connect to request short-lived cloud credentials.<\/p>\n\n\n\n
                                Conceptually:<\/p>\n\n\n
                                Workflow\n   |\n   +--> GitHub OIDC token\n            |\n            +--> Cloud IAM trust policy\n                      |\n                      +--> Short-lived credentials\n<\/code><\/span><\/pre>\n\n\n
                                This is generally safer than copying long-lived AWS, Azure, or GCP keys into many repository secrets.<\/p>\n\n\n\n
                                The cloud trust policy should restrict which organization, repository, branch, environment, or workflow may receive credentials.<\/p>\n\n\n\n
                                \n\n\n\n
                                Module 6 \u2014 Security, Apps, Tokens, and Audit<\/h1>\n\n\n\n
                                26. Authentication Security<\/h2>\n\n\n\n
                                At minimum, organization administrators should understand:<\/p>\n\n\n\n
                                  \n
                                • Two-factor authentication<\/li>\n\n\n\n
                                • SAML SSO in enterprise environments<\/li>\n\n\n\n
                                • SCIM provisioning in enterprise environments<\/li>\n<\/ul>\n\n\n\n
                                  For this Essentials course, remember the distinction:<\/p>\n\n\n
                                  2FA  -> strengthens user login\nSAML -> enterprise authentication \/ SSO\nSCIM -> user provisioning and deprovisioning lifecycle\n<\/code><\/span><\/pre>\n\n\n
                                  SAML and SCIM are important enterprise subjects, but they require their own implementation lesson.<\/p>\n\n\n\n
                                  27. Programmatic Access Hierarchy<\/h2>\n\n\n\n
                                  When software needs access to GitHub, prefer the narrowest appropriate mechanism.<\/p>\n\n\n\n
                                  A practical preference order is:<\/p>\n\n\n\n
                                    \n
                                  1. GitHub App installation token for service automation<\/li>\n\n\n\n
                                  2. GITHUB_TOKEN<\/code>\u00a0inside GitHub Actions when sufficient<\/li>\n\n\n\n
                                  3. OIDC for external cloud credentials<\/li>\n\n\n\n
                                  4. Fine-grained PAT for narrow human or automation use<\/li>\n\n\n\n
                                  5. Classic PAT only when a required integration still depends on it<\/li>\n<\/ol>\n\n\n\n
                                    28. Why GitHub Apps Are Preferred for Services<\/h2>\n\n\n\n
                                    GitHub Apps can provide:<\/p>\n\n\n\n
                                      \n
                                    • Granular permissions<\/li>\n\n\n\n
                                    • Selected repository access<\/li>\n\n\n\n
                                    • Short-lived installation tokens<\/li>\n\n\n\n
                                    • Webhooks<\/li>\n\n\n\n
                                    • Independent application identity<\/li>\n\n\n\n
                                    • Better ownership than a personal account token<\/li>\n<\/ul>\n\n\n\n
                                      Avoid this pattern:<\/p>\n\n\n
                                      Owner's personal PAT -> production automation\n<\/code><\/span><\/pre>\n\n\n
                                      Prefer:<\/p>\n\n\n
                                      GitHub App -> selected repositories -> required permissions only\n<\/code><\/span><\/pre>\n\n\n
                                      29. Audit Log<\/h2>\n\n\n\n
                                      The organization audit log helps answer:<\/p>\n\n\n\n
                                        \n
                                      • Who changed this setting?<\/li>\n\n\n\n
                                      • Who added or removed this user?<\/li>\n\n\n\n
                                      • Who changed a role?<\/li>\n\n\n\n
                                      • Who created or transferred this repository?<\/li>\n\n\n\n
                                      • Who changed an Actions policy?<\/li>\n\n\n\n
                                      • Who installed or changed an integration?<\/li>\n<\/ul>\n\n\n\n
                                        Typical event data includes:<\/p>\n\n\n\n
                                          \n
                                        • Actor<\/li>\n\n\n\n
                                        • Action<\/li>\n\n\n\n
                                        • Resource<\/li>\n\n\n\n
                                        • Repository or organization<\/li>\n\n\n\n
                                        • Timestamp<\/li>\n\n\n\n
                                        • Additional context depending on event and plan<\/li>\n<\/ul>\n\n\n\n
                                          Useful CLI starter commands<\/h3>\n\n\n
                                          export<\/span> ORG=\"acme\"<\/span>\n\ngh auth status\n\ngh api \"\/orgs\/$ORG\"<\/span>\n\ngh api --paginate \"\/orgs\/$ORG\/members\"<\/span>\n\ngh api --paginate \"\/orgs\/$ORG\/teams\"<\/span>\n\ngh api \"\/orgs\/$ORG\/actions\/permissions\"<\/span>\n\ngh api \"\/orgs\/$ORG\/properties\/schema\"<\/span>\n\ngh api --paginate \"\/orgs\/$ORG\/audit-log\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                          Use the audit log whenever an organization setting appears to have \u201cchanged by itself.\u201d<\/p>\n\n\n\n
                                          Often the real problem is that multiple people or automation systems are modifying the same configuration.<\/p>\n\n\n\n
                                          30. Security Baseline Checklist<\/h2>\n\n\n\n
                                          For a normal engineering organization, start with:<\/p>\n\n\n\n
                                            \n
                                          • [ ] At least two organization owners<\/li>\n\n\n\n
                                          • [ ] Owner population kept small<\/li>\n\n\n\n
                                          • [ ] Strong authentication required according to organization plan\/model<\/li>\n\n\n\n
                                          • [ ] Team-based repository access<\/li>\n\n\n\n
                                          • [ ] Conservative base repository permission<\/li>\n\n\n\n
                                          • [ ] Public repository creation restricted when not required<\/li>\n\n\n\n
                                          • [ ] Repository visibility changes controlled<\/li>\n\n\n\n
                                          • [ ] Rulesets protecting important branches<\/li>\n\n\n\n
                                          • [ ] Default\u00a0GITHUB_TOKEN<\/code>\u00a0permissions conservative<\/li>\n\n\n\n
                                          • [ ] Third-party Actions controlled<\/li>\n\n\n\n
                                          • [ ] Organization secrets scoped narrowly<\/li>\n\n\n\n
                                          • [ ] OIDC preferred for cloud deployments<\/li>\n\n\n\n
                                          • [ ] GitHub Apps preferred over shared PATs<\/li>\n\n\n\n
                                          • [ ] Outside collaborators reviewed<\/li>\n\n\n\n
                                          • [ ] Audit log used for high-risk changes<\/li>\n<\/ul>\n\n\n\n
                                            \n\n\n\n
                                            Module 7 \u2014 10-Minute Hands-On Essentials Lab<\/h1>\n\n\n\n
                                            31. Scenario<\/h2>\n\n\n\n
                                            You are administering a training organization named:<\/p>\n\n\n
                                            acme-engineering\n<\/code><\/span><\/pre>\n\n\n
                                            The organization contains two repositories:<\/p>\n\n\n
                                            payments-api\npayments-web\n<\/code><\/span><\/pre>\n\n\n
                                            Five developers work on both repositories.<\/p>\n\n\n\n
                                            Your job is to build a simple but scalable access and governance model.<\/p>\n\n\n\n
                                            32. Lab Step 1 \u2014 Create a Team<\/h2>\n\n\n\n
                                            Create:<\/p>\n\n\n
                                            payments\n<\/code><\/span><\/pre>\n\n\n
                                            Add the five developers.<\/p>\n\n\n\n
                                            Make one senior engineer a team maintainer<\/strong> rather than an organization owner.<\/p>\n\n\n\n
                                            33. Lab Step 2 \u2014 Assign Repository Access<\/h2>\n\n\n\n
                                            Grant the payments<\/code> team:<\/p>\n\n\n
                                            Write -> payments-api\nWrite -> payments-web\n<\/code><\/span><\/pre>\n\n\n
                                            Remove redundant direct developer grants where safe to do so.<\/p>\n\n\n\n
                                            Expected result<\/h3>\n\n\n\n
                                            Repository access is now controlled mainly through team membership.<\/p>\n\n\n\n
                                            34. Lab Step 3 \u2014 Add Repository Metadata<\/h2>\n\n\n\n
                                            Create a custom property:<\/p>\n\n\n
                                            service_tier\n<\/code><\/span><\/pre>\n\n\n
                                            Values:<\/p>\n\n\n
                                            tier-1\ntier-2\ntier-3\n<\/code><\/span><\/pre>\n\n\n
                                            Assign:<\/p>\n\n\n
                                            payments-api -> tier-1\npayments-web -> tier-1\n<\/code><\/span><\/pre>\n\n\n
                                            35. Lab Step 4 \u2014 Protect Tier-1 Repositories<\/h2>\n\n\n\n
                                            Create a test organization ruleset that targets the two tier-1 repositories.<\/p>\n\n\n\n
                                            Protect the default branch with:<\/p>\n\n\n\n
                                              \n
                                            • Pull request required<\/li>\n\n\n\n
                                            • At least one approval<\/li>\n\n\n\n
                                            • CI check required if a stable test check exists<\/li>\n\n\n\n
                                            • Force push restricted<\/li>\n\n\n\n
                                            • Branch deletion restricted<\/li>\n<\/ul>\n\n\n\n
                                              Test this on a disposable training repository before broad enforcement.<\/p>\n\n\n\n
                                              36. Lab Step 5 \u2014 Check Actions Policy<\/h2>\n\n\n\n
                                              Review:<\/p>\n\n\n\n
                                                \n
                                              • Whether Actions is enabled<\/li>\n\n\n\n
                                              • What third-party Actions are allowed<\/li>\n\n\n\n
                                              • Default\u00a0GITHUB_TOKEN<\/code>\u00a0permissions<\/li>\n\n\n\n
                                              • Whether organization secrets are broader than necessary<\/li>\n<\/ul>\n\n\n\n
                                                Do not change production settings in a training exercise.<\/p>\n\n\n\n
                                                37. Lab Step 6 \u2014 Verify Through CLI<\/h2>\n\n\n
                                                export<\/span> ORG=\"acme-engineering\"<\/span>\n\ngh auth status\ngh api \"\/orgs\/$ORG\"<\/span>\ngh api --paginate \"\/orgs\/$ORG\/teams\"<\/span>\ngh api \"\/orgs\/$ORG\/actions\/permissions\"<\/span>\ngh api \"\/orgs\/$ORG\/properties\/schema\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                Expected outcome<\/h3>\n\n\n\n
                                                You should now be able to explain this chain:<\/p>\n\n\n
                                                User\n -> Team\n -> Repository role\n -> Custom property\n -> Ruleset\n -> Actions policy\n -> Audit\n<\/code><\/span><\/pre>\n\n\n
                                                That chain is the core of GitHub Organization Administration.<\/p>\n\n\n\n
                                                \n\n\n\n
                                                5-Minute Review<\/h1>\n\n\n\n
                                                38. The Seven Rules to Remember<\/h2>\n\n\n\n
                                                Rule 1 \u2014 Keep Owners Rare<\/h3>\n\n\n\n
                                                Use multiple owners for continuity, but do not turn owner into the normal admin role.<\/p>\n\n\n\n
                                                Rule 2 \u2014 Prefer Teams Over Direct User Grants<\/h3>\n\n\n\n
                                                Team membership is easier to onboard, review, and revoke.<\/p>\n\n\n\n
                                                Rule 3 \u2014 Use the Lowest Repository Role That Works<\/h3>\n\n\n\n
                                                Do not grant Admin<\/code> when Write<\/code> or Maintain<\/code> is sufficient.<\/p>\n\n\n\n
                                                Rule 4 \u2014 Centralize Policy with Rulesets<\/h3>\n\n\n\n
                                                Repository-by-repository configuration creates drift.<\/p>\n\n\n\n
                                                Rule 5 \u2014 Classify Repositories with Custom Properties<\/h3>\n\n\n\n
                                                Metadata such as owner, tier, and classification lets policy scale dynamically.<\/p>\n\n\n\n
                                                Rule 6 \u2014 Treat Actions as Privileged Automation<\/h3>\n\n\n\n
                                                Control actions, token permissions, runners, secrets, and cloud access.<\/p>\n\n\n\n
                                                Rule 7 \u2014 Audit High-Risk Changes<\/h3>\n\n\n\n
                                                An organization should be able to answer who changed access, policy, repositories, and integrations.<\/p>\n\n\n\n
                                                \n\n\n\n
                                                39. Common Anti-Patterns<\/h2>\n\n\n\n
                                                Anti-pattern<\/th>Why it is a problem<\/th>Better approach<\/th><\/tr><\/thead>
                                                Too many owners<\/td>Large blast radius<\/td>Delegated roles<\/td><\/tr>
                                                Direct access everywhere<\/td>Hard to review\/remove<\/td>Teams<\/td><\/tr>
                                                Admin for every developer<\/td>Unnecessary destructive capability<\/td>Write \/ Maintain<\/td><\/tr>
                                                Uncontrolled public repositories<\/td>Data exposure risk<\/td>Creation and visibility policy<\/td><\/tr>
                                                Branch settings configured manually in every repo<\/td>Configuration drift<\/td>Organization rulesets<\/td><\/tr>
                                                No repository ownership metadata<\/td>No accountable team<\/td>owner_team<\/code> custom property<\/td><\/tr>
                                                Unrestricted third-party Actions<\/td>Supply-chain exposure<\/td>Approved \/ allowlisted actions<\/td><\/tr>
                                                Broad GITHUB_TOKEN<\/code><\/td>Workflow compromise gains more power<\/td>Read-oriented default + explicit permissions<\/td><\/tr>
                                                Shared owner PAT in automation<\/td>Poor auditability and excessive privilege<\/td>GitHub App<\/td><\/tr>
                                                Long-lived cloud credentials<\/td>Credential leakage\/rotation burden<\/td>OIDC<\/td><\/tr>
                                                Sensitive persistent runner for untrusted code<\/td>Network\/credential exposure<\/td>Isolated or ephemeral runners<\/td><\/tr>
                                                No audit review<\/td>Suspicious changes are hard to explain<\/td>Audit process<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                \n\n\n\n
                                                40. Troubleshooting Essentials<\/h2>\n\n\n\n
                                                Problem<\/th>First thing to check<\/th><\/tr><\/thead>
                                                Member cannot access repository<\/td>Team membership and repository role<\/td><\/tr>
                                                User has too much access<\/td>Base permission, teams, direct grants, delegated roles<\/td><\/tr>
                                                Ruleset does not apply<\/td>Ruleset target conditions and custom property values<\/td><\/tr>
                                                Ruleset blocks unexpectedly<\/td>All matching organization\/repository rules<\/td><\/tr>
                                                Required check never appears<\/td>Workflow trigger and exact check name<\/td><\/tr>
                                                Actions workflow cannot run<\/td>Organization\/repository Actions policy<\/td><\/tr>
                                                GitHub API returns permission denied<\/td>GITHUB_TOKEN<\/code> or token permissions<\/td><\/tr>
                                                Organization secret unavailable<\/td>Secret repository visibility\/scope<\/td><\/tr>
                                                Job stays queued<\/td>Runner label, group access, online capacity<\/td><\/tr>
                                                GitHub App gets 403<\/td>App permissions and installation repository scope<\/td><\/tr>
                                                Setting changed unexpectedly<\/td>Audit log and other automation\/IaC owners<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                \n\n\n\n
                                                41. Quick Reference Cheat Sheet<\/h2>\n\n\n\n
                                                Main administration locations<\/h3>\n\n\n\n
                                                Need<\/th>Common organization area<\/th><\/tr><\/thead>
                                                Members and owners<\/td>People<\/td><\/tr>
                                                Teams<\/td>Teams<\/td><\/tr>
                                                Repository inventory<\/td>Repositories<\/td><\/tr>
                                                Organization settings<\/td>Settings<\/td><\/tr>
                                                Repository permissions<\/td>People \/ Teams \/ Repository access<\/td><\/tr>
                                                Rulesets<\/td>Repository \/ Rules \/ Rulesets settings<\/td><\/tr>
                                                Custom properties<\/td>Repository custom properties<\/td><\/tr>
                                                Actions policy<\/td>Actions settings<\/td><\/tr>
                                                Runners<\/td>Actions -> Runners \/ Runner groups<\/td><\/tr>
                                                Secrets and variables<\/td>Secrets and variables<\/td><\/tr>
                                                GitHub Apps \/ OAuth \/ PAT policy<\/td>Third-party access \/ Developer settings<\/td><\/tr>
                                                Authentication<\/td>Authentication security<\/td><\/tr>
                                                Audit<\/td>Audit log \/ Logs<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                GitHub’s navigation changes over time, so learn the concept names<\/strong>, not only the exact sidebar position.<\/p>\n\n\n\n
                                                Repository roles<\/h3>\n\n\n
                                                Read     -> consume and discuss\nTriage   -> manage issues\/PRs without code write\nWrite    -> normal development\nMaintain -> repository operations\nAdmin    -> full repository administration\n<\/code><\/span><\/pre>\n\n\n
                                                Essential CLI commands<\/h3>\n\n\n
                                                <em<\/span>><\/span># Authentication<\/em<\/span>><\/span>\ngh auth status\n\n<em<\/span>><\/span># Organization metadata<\/em<\/span>><\/span>\ngh api \"\/orgs\/$ORG\"\n\n<em<\/span>><\/span># Members<\/em<\/span>><\/span>\ngh api --paginate \"\/orgs\/$ORG\/members\"\n\n<em<\/span>><\/span># Teams<\/em<\/span>><\/span>\ngh api --paginate \"\/orgs\/$ORG\/teams\"\n\n<em<\/span>><\/span># Actions policy<\/em<\/span>><\/span>\ngh api \"\/orgs\/$ORG\/actions\/permissions\"\n\n<em<\/span>><\/span># Custom properties<\/em<\/span>><\/span>\ngh api \"\/orgs\/$ORG\/properties\/schema\"\n\n<em<\/span>><\/span># Audit log<\/em<\/span>><\/span>\ngh api --paginate \"\/orgs\/$ORG\/audit-log\"\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                \n\n\n\n
                                                42. Knowledge Check<\/h2>\n\n\n\n
                                                  \n
                                                1. Why is a GitHub Organization not normally a login account?<\/li>\n\n\n\n
                                                2. Why should an organization have more than one owner but still keep owner access rare?<\/li>\n\n\n\n
                                                3. What is the difference between a member and an outside collaborator?<\/li>\n\n\n\n
                                                4. Why are teams better than repeated direct repository permissions?<\/li>\n\n\n\n
                                                5. What is the difference between Write, Maintain, and Admin?<\/li>\n\n\n\n
                                                6. What does base repository permission do?<\/li>\n\n\n\n
                                                7. Why should public repository creation usually be governed?<\/li>\n\n\n\n
                                                8. Why are organization rulesets more scalable than configuring branch protection manually in every repository?<\/li>\n\n\n\n
                                                9. How can a\u00a0service_tier<\/code>\u00a0custom property drive policy?<\/li>\n\n\n\n
                                                10. Why should default\u00a0GITHUB_TOKEN<\/code>\u00a0permissions be conservative?<\/li>\n\n\n\n
                                                11. What problem do runner groups solve?<\/li>\n\n\n\n
                                                12. Why should organization secrets be scoped to selected repositories when possible?<\/li>\n\n\n\n
                                                13. Why is OIDC usually preferable to long-lived cloud credentials?<\/li>\n\n\n\n
                                                14. Why is a GitHub App usually preferable to an owner’s PAT for service automation?<\/li>\n\n\n\n
                                                15. When would you use the organization audit log?<\/li>\n<\/ol>\n\n\n\n
                                                  Fast answers<\/h3>\n\n\n\n
                                                    \n
                                                  1. Users normally authenticate with personal or enterprise-managed identities; the organization is the shared resource\/governance boundary.<\/li>\n\n\n\n
                                                  2. Multiple owners provide continuity; too many owners increase administrative blast radius.<\/li>\n\n\n\n
                                                  3. A member belongs to the organization; an outside collaborator normally receives access only to selected repositories.<\/li>\n\n\n\n
                                                  4. Teams centralize access lifecycle and are easier to audit.<\/li>\n\n\n\n
                                                  5. Write supports normal development, Maintain adds repository operations, and Admin provides full repository administration.<\/li>\n\n\n\n
                                                  6. It establishes default repository access for organization members.<\/li>\n\n\n\n
                                                  7. Public creation can unintentionally expose company information or code.<\/li>\n\n\n\n
                                                  8. Rulesets provide centralized, reusable, targetable policy and reduce drift.<\/li>\n\n\n\n
                                                  9. A ruleset can target all repositories whose\u00a0service_tier<\/code>\u00a0equals a chosen value.<\/li>\n\n\n\n
                                                  10. A compromised workflow should not automatically receive write authority.<\/li>\n\n\n\n
                                                  11. They control which repositories\/workflows can use particular runners and help create trust boundaries.<\/li>\n\n\n\n
                                                  12. Broad secrets create a broad blast radius.<\/li>\n\n\n\n
                                                  13. OIDC provides short-lived cloud credentials with claim-based trust instead of copying permanent keys.<\/li>\n\n\n\n
                                                  14. GitHub Apps support granular permissions, selected repositories, and short-lived installation tokens.<\/li>\n\n\n\n
                                                  15. To investigate and verify administrative and access changes.<\/li>\n<\/ol>\n\n\n\n
                                                    \n\n\n\n
                                                    43. What to Learn Next<\/h2>\n\n\n\n
                                                    After mastering this two-hour Essentials guide, continue in this order:<\/p>\n\n\n\n
                                                      \n
                                                    1. Security configurations, Dependabot, code scanning, secret scanning, and push protection<\/li>\n\n\n\n
                                                    2. SAML SSO and SCIM<\/li>\n\n\n\n
                                                    3. GitHub Apps and webhook design<\/li>\n\n\n\n
                                                    4. Advanced Actions runner governance and OIDC trust design<\/li>\n\n\n\n
                                                    5. Billing, usage, and cost controls<\/li>\n\n\n\n
                                                    6. REST API, GraphQL, and\u00a0gh api<\/code><\/li>\n\n\n\n
                                                    7. Terraform for GitHub organization configuration<\/li>\n\n\n\n
                                                    8. Audit export \/ SIEM integration<\/li>\n\n\n\n
                                                    9. Organization migration and recovery<\/li>\n\n\n\n
                                                    10. Copilot, agent, MCP, and AI governance where used<\/li>\n<\/ol>\n\n\n\n
                                                      \n\n\n\n
                                                      44. Essential Production Baseline<\/h2>\n\n\n\n
                                                      Use this as the final classroom takeaway.<\/p>\n\n\n
                                                      GitHub Organization\n|\n|-- 2<\/span>+ trusted owners, small owner group\n|\n|-- People\n|   |-- Members\n|   |-- Outside collaborators only when appropriate\n|   `-- Strong authentication\n|\n|-- Teams\n|   `<\/span>-- Normal repository access comes through teams\n|\n|-- Repository permissions\n|   |-- Conservative base permission\n|   |-- Least privilege roles\n|   `-- Public \/ delete \/ transfer controls\n|\n|-- Repository governance\n|   |-- Custom properties\n|   |-- Organization rulesets\n|   `<\/span>-- Required PR and CI controls for<\/span> important repos\n|\n|-- GitHub Actions\n|   |-- Controlled actions\n|   |-- Restricted GITHUB_TOKEN\n|   |-- Runner trust boundaries\n|   |-- Scoped secrets\n|   `-- OIDC for cloud access\n|\n|-- Programmatic access\n|   |-- GitHub Apps preferred\n|   |-- Fine-grained tokens when required\n|   `<\/span>-- No shared owner credentials\n|\n`-- Audit\n    `<\/span>-- High-risk changes are reviewable and explainable\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                      If students understand this model, they understand the essential operating system of GitHub Organization Administration<\/strong>.<\/p>\n\n\n\n
                                                      \n\n\n\n
                                                      45. Selected Official References<\/h2>\n\n\n\n
                                                      Use the full reference guide for the complete source list. The most important official documentation for this Essentials course includes:<\/p>\n\n\n\n