A developer leaves a company on Friday, but a deployment credential they created can still publish code on Monday. Disabling the human account was necessary, yet the enterprise has overlooked machine identities, stored secrets or an automation workflow. GitHub administration is a problem of establishing control over people, repositories and systems that act on their behalf.<\/p>\n
GitHub GH-100, GitHub Enterprise Administrator<\/em>, assesses identity and access, enterprise governance, secure development, Actions administration and monitoring. The July 2026 study guide includes both GitHub Enterprise Cloud and Server considerations. The GH-100 exam<\/a> page belongs beside controlled administration exercises using test organizations and deliberately limited accounts.<\/p>\n Organization membership, enterprise settings and identity-provider integration influence who can access repositories, but not every credential belongs to a human user. Personal access tokens, deploy keys, GitHub Apps and workflow credentials create different control surfaces. An enterprise administrator must understand where access is granted, how to inventory it and how to revoke it when ownership changes. Removing one account does not guarantee that every secret it once touched is harmless. Repository permissions affect the blast radius of security incidents; GitHub GH-500 security remediation<\/a> follows the separate work of responding to alerts and exposed secrets. The collaboration primitives behind those governance rules are introduced in GitHub GH-900 collaboration fundamentals<\/a>, from branches to pull requests.<\/p>\n Take a fictional team that has two private repositories, a shared runner and an external service that files issues. Map its human roles and machine identities before a developer’s departure. Then identify who can revoke tokens, rotate credentials, review installations and audit access. The same exercise exposes an important distinction between authentication, which establishes identity, and authorization, which determines the operations that identity may perform.<\/p>\n Enterprise policy must accommodate different teams without allowing every repository to invent its own security minimum. Rulesets, branch protections and review requirements can reduce accidental high-risk changes. However, overly broad restrictions can push teams into unsafe exceptions. Define a small set of essential controls and document the approved process for emergency changes, including who may authorize a bypass and how its use is recorded.<\/p>\n In a sample organization, require review for protected branches and place sensitive deployment environments behind appropriate approvals. Try opening a pull request that lacks required status checks, then inspect which policy prevents merging. Follow the effective configuration from enterprise to organization to repository. A policy that appears correct in a settings screenshot may be ineffective if the repository or branch is outside its actual scope.<\/p>\n A workflow runs code, downloads dependencies and may receive credentials. On self-hosted runners, untrusted jobs can affect infrastructure you maintain, so runner placement and lifecycle matter. GitHub-hosted runners offer a different operational trade-off, but workflows still require careful token permissions, protected secrets and controlled third-party actions. The administrator’s responsibility includes policies for allowed actions and reusable workflows across the enterprise.<\/p>\n Imagine a public pull request that triggers a job with access to an internal package registry. Ask which events should run privileged steps, whether a forked contribution can reach secrets and what permissions the default workflow token receives. Review action version pinning and deployment approvals. The GH-100 perspective is broader than authoring YAML: it concerns how enterprise-level defaults and isolation rules prevent one insecure workflow from becoming an organization-wide weakness.<\/p>\n Code scanning, secret scanning and dependency alerts are useful only if teams can triage and address them. Enterprise administrators may define feature availability and oversight while development teams investigate individual findings. That division of work should be explicit. Measure not just the number of alerts but their severity, ownership, age and whether high-risk repositories receive the promised controls.<\/p>\n Run a tabletop exercise for an exposed access token. Identify how the alert arrives, who can revoke the token, how to determine whether it was used and which workflow must be redeployed with a replacement credential. Record the incident without exposing the secret in tickets or logs. Security policy should make the next incident easier to handle, not simply generate a larger dashboard that nobody checks.<\/p>\n An administrator cannot maintain control through static configuration alone. Organizations change, contractors arrive, repositories are archived and integrations gain privileges. Audit logs and usage reporting help reconstruct what changed and evaluate adoption, but retention and visibility limits should be understood. Set a review rhythm for privileged membership, organization settings, runner inventory and exceptions to standard rules.<\/p>\n To prepare for GH-100, design an enterprise change: introduce a new department, migrate repositories, enforce protections and demonstrate controlled developer access without obstructing normal work. Trace the decision through identity, policy, Actions and auditing. The strongest answer to an administration scenario is one that preserves collaboration while making authority, accountability and recovery testable.<\/p>\n","protected":false},"excerpt":{"rendered":" A developer leaves a company on Friday, but a deployment credential they created can still publish code on Monday. Disabling the human account was\u2026<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[709],"tags":[],"class_list":["post-28316","post","type-post","status-publish","format-standard","hentry","category-devops"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\tPeople and automation need separate offboarding<\/h2>\n
Repository governance should be predictable<\/h2>\n
Actions runners expand the trust boundary<\/h2>\n
Security features require operational owners<\/h2>\n
Audit evidence closes the loop<\/h2>\n