GitHub Administration Exam — LMR (last minute revision)

Vijay Borkar (VBCloudboy)

22 min readJun 9, 2024

my notes…

About GitHub Actions

Actions are the mechanism used to provide workflow automation within the GitHub environment. Often used to build continuous integration (CI) and continuous deployment (CD) solutions
Defined in YAML and stay within GitHub repositories
Actions are executed on “runners,” either hosted by GitHub or self-hosted

Explore Actions flow — Training | Microsoft Learn

GitHub tracks events that occur. Events can trigger the start of workflows. Workflows can also start on cron-based schedules and can be triggered by events outside of GitHub. They can also be manually triggered. Workflows are the unit of automation which contain Jobs. Jobs use Actions to get work done.
Workflows are written in YAML and live within a GitHub repository at the place .github/workflows.
If we take an example workflow where the workflow’s include several standard syntax elements as shown below:

Understand Workflows — Training | Microsoft Learn

Name: is the name of the workflow. It's optional but is highly recommended. It appears in several places within the GitHub UI. On: is the event or list of events that will trigger the workflow. Jobs: is the list of jobs to be executed. Workflows can contain one or more jobs. Runs-on: tells Actions which runner to use. Steps: It's the list of steps for the job. Steps within a job execute on the same runner. Uses: tells Actions, which predefined action needs to be retrieved. For example, you might have an action that installs node.js. Run: tells the job to execute a command on the runner. For example, you might execute an NPM command.
Events are implemented by the on clause in a workflow definition where there are several types of events that can trigger workflows like: Scheduled events, Code events, Manual events, Webhook events, External events.

Code events will trigger most actions. It occurs when an event of interest occurs in the repository.

Scheduled events: With this type of trigger, a cron schedule needs to be provided.

Manual event are a unique event that is used to trigger workflow runs manually. We should use the workflow_dispatch event. Our workflow must be in the default branch for the repository. Webhook events workflows can be executed when a GitHub webhook is called. External Events can be on repository_dispatch. That allows events to fire from external systems.
A job is a set of steps that will be run in order on a runner. Steps within a job execute on the same runner and share the same filesystem. The logs produced by jobs are searchable, and artifacts produced can be saved. By default, if a workflow contains multiple jobs, they run in parallel. Sometimes you might need one job to wait for another job to complete. You can do that by defining dependencies between the jobs.
GitHub runners are compute resources that execute GitHub Actions workflows, It allow developers to perform build, test, and deployment tasks directly within from GitHub repositories.
Two main types of GitHub runners: GitHub-hosted runners are virtualized or containerized compute resources provided and managed by GitHub. Self-hosted runners are physical, virtualized, or containerized compute resources that GitHub users and organizations provision and manage themselves. GitHub strongly recommends against using self-hosted runners in public repos.

Release Management for Actions : Tags allow you to specify the precise versions that you want to work. You can specify a requested SHA-based hash for an action. It ensures that the action hasn’t changed. A common way to request actions is to refer to the branch you want to work with. You’ll then get the latest version from that branch. That means you’ll benefit from updates, but it also increases the chance of code-breaking.

Manage GitHub Actions in the enterprise

GitHub Actions enables developers to automate, customize, and execute their software development workflows right within their GitHub repository. Three key features of GitHub Actions: actions and workflows, runners, and encrypted secrets.
If you want stricter control over the public actions that should be made available in your enterprise, you can manually download and sync actions into your enterprise instance using the actions-sync tool.
GitHub-authored actions come automatically bundled with Enterprise Server, and are captured at a point in time from the GitHub Marketplace. They include actions/checkout, actions/upload-artifact, actions/download-artifact, actions/labeler and various actions/setup- actions, among others.
Best Practice recommend you to document the following in a GitHub wiki or as a markdown file in a repository accessible to all within an organization: Repositories for storage, Files/folders naming conventions, Location of shared components, Plans for ongoing maintenance, Contribution guidelines.
GitHub Actions workflows can be executed by two types of runners: GitHub-hosted runners or self-hosted runners.
If you need to use an IP address allowlist for your organization or a specialized hardware configuration for running your workflows, use a self-hosted runner.

Enterprise Cloud and Enterprise Server offer multiple features enabling you to customize your self-hosted runners for your enterprise use. Some of these features include labels, proxy servers, and IP allowlists.
Self-hosted runners automatically receive default labels when they are added to GitHub Actions. Custom labels can come in handy when you need to run jobs on runners that have specific capabilities. These default labels indicate the operating system and hardware architecture of the runner as shown in the table below:

To communicate with GitHub via a proxy server, both Enterprise Cloud and Enterprise Server enable you to change proxy configurations using the following environment variables. Proxy environment variables are read when the self-hosted runner application starts, so you must set the environment variables before configuring or starting the application. If your proxy configuration changes, you must restart the self-hosted runner application.
Troubleshooting a self-hosted runner Review the activities and automatic updates of the runner in the Runner_ files in the _diag folder. Review the status of the jobs the runner executed in the Worker_ files in the _diag folder.

Secrets are encrypted environment variables you can create to store tokens, credentials, or any other type of sensitive information your GitHub Actions workflows and actions might rely on. Once created, they become available to use in the workflows and actions that have access to the organization, repository, or repository environment where they are stored.
Anyone with collaborator access to the repositories with access to a secret or variable can use it for Actions. They are not passed to workflows that are triggered by a pull request from a fork.
In workflows, to access an encrypted secret, you must use the secrets context in your workflow file. For example:

To access an encrypted secret in an action, you must specify the secret as an input parameter in the action.yml metadata file. For example:

Intro 2 GitHub

GitHub provides an AI-powered developer platform to build, scale, and deliver secure software. GitHub is a cloud-based platform that uses Git, a distributed version control system, at its core. The GitHub platform simplifies the process of collaborating on projects and provides a website, command-line tools, and overall flow that allows developers and users to work together.

Repository: A repository contains all of your project’s files and each file’s revision history. It is one of the essential parts that helps you collaborate with people. You can use repositories to manage your work, track changes, store revision history and work with others.
In order to add a file to a repository you must first have minimum Write access within the repository you want to add a file.
Similarly to repositories, gists are a simplified way to share code snippets with others. Every gist is a Git repository, which you can fork and clone and can be either public or secret.
Every repository on GitHub.com comes equipped with a section for hosting documentation, called a wiki. You can use your repository’s wiki to share long-form content about your project, such as how to use it, how you designed it, or its core principles. While a README file quickly tells what your project can do, you can use a wiki to provide additional documentation.
Branches are an essential part to the GitHub experience because they’re where we can make changes without affecting the entire project we’re working on. Your branch is a safe place to experiment with new features or fixes. If you make a mistake, you can revert your changes or push more changes to fix the mistake. Your changes won’t update on the default branch until you merge your branch.
A commit is a change to one or more files on a branch. Every time a commit is created, it’s assigned a unique ID and tracked, along with the time and contributor. Commits provide a clear audit trail for anyone reviewing the history of a file or linked item, such as an issue or pull request.
A pull request is the mechanism used to signal that the commits from one branch are ready to be merged into another branch. The team member submitting the pull request requests one or more reviewers to verify the code and approve the merge. These reviewers have the opportunity to comment on changes, add their own, or use the pull request itself for further discussion.
The GitHub flow can be defined as a lightweight workflow that allows for safe experimentation. You can test new ideas and collaboration with your team by using branching, pull requests, and merging.
GitHub Issues were created to track ideas, feedback, tasks, or bugs for work on GitHub. Issues can be created in various ways, so you can choose the most convenient method for your workflow.
Discussions are for conversations that need to be accessible to everyone and aren’t related to code. Discussions enable fluid, open conversation in a public forum.
GitHub Pages is a static site-hosting service that takes HTML, CSS, and JavaScript files straight from a repository on GitHub. Optionally, you can run the files through a build process and publishes a website. You can use GitHub Pages to publicize and host a website about yourself, your organization, or your project directly from a repository on GitHub.com.

Intro 2 GitHub Products

3 types of GitHub accounts: Personal, Organization & Enterprise

There are several free GitHub products, in addition to the paid ones: GitHub Free for personal accounts and organizations, GitHub Pro for personal accounts, GitHub Team, GitHub Enterprise.

There are multiple ways to access your GitHub account aside from github.com. GitHub Mobile and GitHub Desktop allow you to have a seamless experience while accessing your account on the go.

GitHub bills separately for each account. This means that you receive a separate bill for your personal account and for each organization or enterprise account you own.
The bill for each account is a combination of charges for your subscriptions and usage-based billing. Subscriptions include your account’s plan, such as GitHub Pro or GitHub Team, as well as paid products that have a consistent monthly cost, such as GitHub Copilot and apps from GitHub Marketplace. Usage-based billing applies when the cost of a paid product depends on how much you use the product. For example, the cost of GitHub Actions depends on how many minutes your jobs spend running and how much storage your artifacts use.

Intro 2 GitHub Administration

As a GitHub administrator, your goal is to keep everything working smoothly for your users.
In GitHub, organize users into teams within your organization to manage access and facilitate collaboration. Teams allow for detailed permission control over repositories and provide a platform for member communication.
GitHub allows you to sync your teams with identity provider (IdP) groups such as Microsoft Entra ID. When you synchronize a GitHub team with Microsoft Entra ID, you can replicate changes to GitHub automatically, which reduces the need for manual updates and custom scripts.
Team maintainers or repository admins in GitHub can: Form and manage teams, including parent-child team structures. Modify team details, like renaming or deleting teams. Adjust membership, adding or removing organization members and syncing with IdP groups. Control access for outside collaborators in team repositories. Manage communication, enabling or disabling team discussions. Set visibility and profile pictures for the team. Automate code reviews and schedule reminders for pull requests.
Some best practices for setting up teams on GitHub: Create nested teams to reflect your group or company’s hierarchy within your GitHub organization. Create teams based on interests or specific technology (JavaScript, data science, etc.) to help streamline PR review processes. Individuals can choose to join these teams according to their interests or skills. Enable team synchronization between your identity provider (IdP) and GitHub to allow organization owners and team maintainers to connect teams in your organization with IdP groups.
Owners and administrators can manage member access to the organization’s data and repositories with sophisticated security and administrative features.
At the enterprise level, members of an enterprise with the owner permissions can: Enable SAML single sign-on for their enterprise account, allowing each enterprise member to link their external identity on your identity provider (IdP) to their existing GitHub account. Set up billing or assign a billing manager for all organizations in the enterprise.
Several options for authenticating with GitHub: Username and password, Personal access tokens, SSH keys, Deploy keys, Two-factor authentication, SAML SSO, LDAP,
GitHub offers limited support for all identity providers that implement the SAML 2.0 standard with official support for several popular identity providers including: Active Directory Federation Services (AD FS), Microsoft Entra ID, Okta, OneLogin, PingOne
The different ways that users can authenticate themselves with GitHub: Repository permissions, Team permissions, Organization permissions, Enterprise permissions.
Repository Permission Level: There are five repository-level permissions; Read — Recommended for non-code contributors who want to view or discuss your project. Triage — Recommended for contributors who need to proactively manage issues and pull requests without write access. Write — Recommended for contributors who actively push to your project. Maintain — Recommended for project managers who need to manage the repository without access to sensitive or destructive actions. Admin — Recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository.
Team Permission Level: There are two levels of permissions at the team level: Member — Team members have the same set of abilities as organization members. Maintainer — Team maintainers can do everything team members can, plus:
- Change the team’s name, description, and visibility
- Request that the team change parent and child teams
- Set the team profile picture
- Edit and delete team discussions
- Add and remove organization members from the team
- Promote team members to also have the team maintainer permission
- Remove the team’s access to repositories
- Manage code review assignment for the team
- Manage scheduled reminders for pull requests
Organization Permission Level: There are multiple levels of permissions at the organizational level; Owner — Organization owners can do everything that organization members can do, and they can add or remove other users to and from the organization. This role should be limited to no less than two people in your organization. Member — Organization members can create and manage organization repositories and teams. Moderator — Organization moderators can block and unblock nonmember contributors, set interaction limits, and hide comments in public repositories that the organization owns. Billing manager — Organization billing managers can view and edit billing information. Security managers — Organization security managers can manage security alerts and settings across your organization. They can also read permissions for all repositories in the organization. Outside collaborator — Outside collaborators, such as a consultant or temporary employee, can access one or more organization repositories. They aren’t explicit members of the organization.
Enterprise Permission Level: There are three levels of permission at the enterprise level; Member — Enterprise members have the same set of abilities as organization members. Billing manager — Enterprise billing managers can only view and edit your enterprise’s billing information and add or remove other billing managers. Owner — Enterprise owners have complete control over the enterprise and can take every action, including:
- Managing administrators
- Adding and removing organizations to and from the enterprise
- Managing enterprise settings
- Enforcing policies across organizations
- Managing billing settings
Adding a CODEOWNERS file to your repository, you can assign team members or entire teams as code owners who are responsible for code in the repository. When someone opens a pull request that modifies code that belongs to a code owner, the code owner is automatically requested as a reviewer. You can create the CODEOWNERS file in either the root of the repository or in the docs or .github folder.

GitHub Best Practices — Maintain a secure repository

GitHub offers various automated features that allow you to efficiently administer a secure repository without slowing everyone down throughout the entire development process.
From the Security tab, you can add features to your GitHub workflow to help avoid vulnerabilities in your repository and codebase.
Security policies that allow you to specify how to report a security vulnerability in your project by adding a SECURITY.md file to your repository.
Dependabot alerts that notify you when GitHub detects that your repository is using a vulnerable dependency or malware.
Security advisories that you can use to privately discuss, fix, and publish information about security vulnerabilities in your repository. GitHub Security Advisories allow repository maintainers to privately discuss and fix a security vulnerability in a project.
Code scanning that helps you find, triage, and fix vulnerabilities and errors in your code.
Keep sensitive files out of your repository with .gitignore and avoid risk to build and maintain .gitignore files. These files instruct client tools, such as the git command line utility, to ignore paths and patterns when aggregating files for a commit.

You can create a branch protection rule to enforce certain workflows for one or more branches. For example, you can require an approving review or passing status checks for all pull requests merged into the protected branch.
GitHub scans common package manifests, such as package.json, requirements.txt, and others. These graphs allow project owners to recursively track all of the dependencies their project relies on.
GitHub provides Dependabot alerts that watch your dependency graphs for you. It then cross-references target versions with versions on known vulnerability lists. When a risk is discovered, the project is alerted. Input for the analysis comes from GitHub Security Advisories.
Dependabot scans for dependency alerts and creates pull requests so that a contributor can validate the update and merge the request.
Code scanning analyze and find security vulnerabilities and errors in the code in a GitHub repository. Code scanning can be use to find, triage, and prioritize fixes for existing problems or potential security vulnerabilities. It’s also useful to help prevent developers from introducing any new security problems into the code.
Code scanning has ability to use CodeQL. CodeQL lets you query code as data, which lets you create custom queries or use queries maintained by the open-source community. Code scanning gives you the freedom to customize and maintain how the code within your repository is being scanned.
Secret scanning looks for known secrets or credentials committed within the repository. This scanning is done to prevent the use of fraudulent behavior and to secure the integrity of any sensitive data. By default, secret scanning occurs on public repositories and you can enable secret scanning on private repositories by repository administrators or organization owners.
When secret scanning detects a set of credentials, GitHub notifies the service provider who issued the secret. The service provider validates the credential. Then, it decides whether they should revoke the secret, issue a new secret, or reach out to you directly. The action depends on the associated risks to you or the service provider.

GitHub’s Basic Security tools — Manage Sensitive Data and Security policies.

To give people instructions for reporting security vulnerabilities in your project, you can add a SECURITY.md file to your repository. SECURITY.md is the primary document for communicating security information. It’s a Markdown file in a repository’s root, docs, or .github folder.
We can add other community health documentation at the organization level or in their user account. GitHub supports the following community health documentation:

Security settings available to administrators are Access restrictions, security documentation, advisories, Dependabot alerts and security updates, Dependabot version updates, and the GitHub dependency graph are available for all repositories.
Code scanning alerts, secret scanning alerts, and dependency review provide further automation to the security process.
Administrators are responsible for publishing security advisories. GitHub’s system for publishing security advisories guides the administrator through the process of writing comprehensive documentation.
As an administrator responsible for managing security policies and settings in GitHub, you might face the challenge of controlling how collaborators interact with specific branches and tags in your repositories. This is where repository rulesets come into play.
Repository rulesets provide a powerful way to control how users can interact with certain branches and tags in a repository. By creating rulesets, you can define a named list of rules that govern various actions, such as pushing commits, deleting or renaming tags, and more. Rulesets work alongside branch-protection and tag-protection rules, allowing you to have fine-grained control over your repository’s behavior.
There’s a limit of 75 rulesets per repository. For example, you could set up a ruleset for your repository’s feature branch that requires signed commits and blocks force pushes for all users except repository administrators.
Rulesets work alongside any branch protection rules and tag protection rules in a repository. Many of the rules you can define in rulesets are similar to protection rules, and you can start using rulesets without overriding any of your existing protection rules. Additionally, you can import existing tag protection rules into repository rulesets. This will implement the same tag protections you currently have in place for your repository.
Unlike protection rules, multiple rulesets can apply at the same time, so you can be confident that every rule targeting a branch or tag in your repository will be evaluated when someone interacts with that branch or tag.
Rulesets have statuses, so you can easily manage which rulesets are active in a repository without needing to delete rulesets.
Anyone with read access to a repository can view the active rulesets for the repository. This means a developer can understand why they have hit a rule, or an auditor can check the security constraints for the repository, without requiring admin access to the repository.
There are many rules you can apply to a ruleset to protect targeted branches and tags in a repository. Here is the Rules section for a tag ruleset for reference.

Organization’s log records actions taken by organization members. The log is available to organization owners, and records information about actions that affect the organization including: The repository in which the action was performed, The user that performed the action, The action that was performed, Which country/region in which the action took place, The date and time of the action.
You can access the audit log through GitHub.com, GitHub Enterprise Server, or GitHub AE to review actions from the past 90 days.
The GraphQL API is available for organizations using GitHub Enterprise, and can retrieve information about actions up to 120 days old. It can monitor: Access to our organization or repository settings, Changes in permissions, Added or removed users in an organization, repository, or team, Users being promoted to admin, Changes to permissions of a GitHub App. It can’t provide information about Git events.
The Rest API is available for organizations that use GitHub Enterprise Cloud, and can retrieve information about actions up to 90 days old. It can monitor the same actions as the GraphQL API, as well as Git events. However, information about Git events only remains in the log for seven days.

Identities on GitHub — Authentication & Authorization

An important component of an enterprise security strategy is SAML SSO. It provides a link between the IdP authorization and access to service providers (SaaS). This form of authentication allows users to sign in to all their applications with one set of credentials. Through SAML, the IdP authenticates users and grants authorization to services like GitHub.
list of the SAML IdPs that GitHub currently supports: Active Directory Federation Services (AD FS), Microsoft Entra ID, Okta, OneLogin, PingOne, Shibboleth.
There are two recommended authentication methods you can implement when authenticating your users on GitHub: SAML SSO and multifactor authentication, also known as 2FA or MFA.
After you enforce authentication for an organization, GitHub will then remove any members of the organization that haven’t authenticated successfully with your SAML IdP.
In your GitHub enterprise, your users have three ways that they can authenticate with 2FA: security keys, TOTP, and SMS.
Grant a user access to a GitHub organization that uses SAML single sign-on (SSO) by authenticating through the identity provider (IdP). But after you authenticate the user with the IdP successfully from GitHub, you must now authorize any personal access token, SSH key, or OAuth App that you’d like the user to use to access your organization’s resources.
SAML single sign-on (SSO) gives organization owners and enterprise owners on GitHub a way to control and secure access to organization resources like repositories, issues, and pull requests.
SAML SSO in your organization, you can implement SCIM or System for Cross-domain Identity Management. SCIM lets you add, manage, or remove organization member access within GitHub. SCIM was developed to allow synchronization of information between an IdP and multiple applications.
SCIM is a protocol that tells the directory an account has been created and allows you to automate the exchange of user identity information between systems.
To access your organization’s protected resources using the API and Git on the command line, your users will need to authorize and authenticate with a PAT (personal access token) or SSH key. Users can authorize an existing PAT or SSH key, or create a new PAT or SSH key and then authorize it. As the administrator, you’re able to review each personal access token and SSH key that a member has authorized for API and Git access.
To provision new users without an invitation from an organization owner, you can use the URL https://github.com/orgs/ORGANIZATION/sso/sign_up, replacing ORGANIZATION with the name of your organization.
Keep in mind that not all SAML identity providers are currently supported by GitHub for SCIM. Following is a list of the GitHub supported identity providers for SCIM: Microsoft Entra ID, Okta, OneLogin.
Your support request is possibly out of GitHub Support’s scope if the request is primarily about: Third-party integrations, Hardware setup, CI/CD, such as Jenkins, Writing scripts, Configuration of external authentication systems, such as SAML identity providers, Open-source projects.
If your company is using Microsoft Entra ID or Okta as your IdP for your enterprise in GitHub’s cloud, you can use team synchronization to manage team membership within each organization through IdP groups. With team synchronization enabled, changes made in an IdP group are automatically reflected on GitHub.
Team synchronization is also available for organizations and enterprise accounts that use GitHub Enterprise Cloud. Enterprise Managed Users is a feature of GitHub Enterprise Cloud that provides even greater control over enterprise members and resources.
When you use Enterprise Managed Users, all members are provisioned and managed through your IdP. Users don’t create their own accounts on GitHub. You can manage organization and team membership by using groups on your IdP.
Managed user accounts are restricted to their enterprise and can’t push code, collaborate, or interact with users, repositories, or organizations outside of their enterprise.
Exceeding these limits can lead to unexpected performance, and might cause synchronization failures.

Maximum number of members in a GitHub team: 5,000
Maximum number of members in a GitHub organization: 10,000
Maximum number of teams in a GitHub organization: 1,500

Enterprise Support & Adoption — GitHub Administration

Two types of GitHub Enterprise features: upkeep and automation.
You want to build a secure knowledge base by creating limited-access sites on GitHub Pages. You also need to keep track of the number of GitHub Actions minutes that collaborators use. Limited-access GitHub pages are an upkeep feature, and GitHub Actions minutes enable automation.
As an administrator for a GitHub organization is to help minimize the friction users feel when interacting with GitHub. Friction refers to problems like difficulty signing in, finding files in the code base, and sharing project knowledge within the right circles.
Your Enterprise account allows 50,000 minutes of GitHub Actions runtime per month and 50 GB of Actions storage. Check in the settings for Your enterprises to learn how much of that allotment your organizations have that month.
You can install integrations in your personal account or in organizations that you own. You can also install GitHub Apps from a third-party in a specific repository where you have admin permissions or that your organization owns.
Third-party tools usually require permissions at the repository level, and these permissions might change. If a tool’s developer changes its permissions, and the permissions are for a repository only, then you can review and accept the new permissions.
The best way to find trustworthy tools for your Enterprise organization, and to construct workflows from trustworthy tools, is to take advantage of the GitHub Marketplace’s categorization system. Using this system, you can find tools that receive independent security verification.
The verified creator badge, which appears as a check mark next to the publisher’s name in a listing on the GitHub Marketplace, signifies verification status. For GitHub Apps, the badge means that GitHub verified the publisher’s domain and email address, and the publisher requires two-factor authentication for their organization. For GitHub Actions, the badge means that GitHub is in active partnership with the organization.
GitHub Support can help troubleshoot issues that arise on GitHub Enterprise Server for three areas; account, security, and abuse issues.
Human error-related authentication problems are an example of account issues. When a user is locked out of their account and failed to retain keys to back up their two-factor authentication process, GitHub technical support can help you prove the user’s identity.
You can request GitHub support when responding to threat actors hacking an account. If the problem is a security issue, GitHub support technicians can provide help in rolling back damage to organization repositories and settings.
Abuse issues involve responding to violations of the site’s terms of service or organizational policies in GitHub’s social setting — someone is using GitHub’s communication’s features to abuse other users. GitHub support technicians can help you evaluate the situation and can remove harmful content or ban abusive actors.
GitHub Enterprise Server supports the REST and GraphQL APIs. Working with these APIs can automate many administrative tasks. Including, performing changes to the Management Console, configuring Lightweight Directory Access Protocol (LDAP) sync, automating changes to organization members’ access, and managing your enterprise account to monitor and log important changes to the organization.
Use the Enterprise Accounts API and the Audit Log API to help monitor and make changes in your organizations and maintain compliance. These APIs are only available as GraphQL APIs.
Here’s a high-level overview of the differences between managed users and regular users within GitHub Enterprise.

Reference Links for quick access to the information…

GitHub Administration Exam — LMR (last minute revision)

About GitHub Actions

Manage GitHub Actions in the enterprise

Intro 2 GitHub

Intro 2 GitHub Products

Intro 2 GitHub Administration

GitHub Best Practices — Maintain a secure repository

GitHub’s Basic Security tools — Manage Sensitive Data and Security policies.

Identities on GitHub — Authentication & Authorization

Enterprise Support & Adoption — GitHub Administration

Written by Vijay Borkar (VBCloudboy)