GH-100 Practice Questions

Implementing team synchronization requires a foundational strategy before any technical configuration. The priority is to establish a clear and logical mapping between the groups in your identity provider (IdP) and the teams within your GitHub organization. This planning phase is critical for ensuring that the correct permissions and access levels are automatically provisioned and maintained. Without this well-defined alignment, the implementation can lead to incorrect access assignments, security vulnerabilities, and operational chaos, defeating the purpose of centralized identity management.

A. Disabling the audit log stream removes essential visibility for security, compliance, and troubleshooting, which is especially critical during a change in identity management.

B. Prioritizing an infrequent sync schedule over accuracy can lead to significant delays in updating permissions, creating security risks from stale access rights.

C. Allowing manual updates on GitHub contradicts the core principle of team synchronization, which is to use the IdP as the single source of truth for membership.

1. GitHub Docs

"Managing team memberships with an identity provider": This document outlines the process of connecting IdP groups to GitHub teams. The entire procedure is predicated on the administrator knowing which IdP group to connect to which GitHub team

reinforcing that this mapping is a prerequisite. The documentation states

"You can connect one IdP group to one GitHub team." This highlights the need for a clear one-to-one alignment strategy.

Reference Section: "Connecting an identity provider group to a team"

2. GitHub Docs

"About team synchronization": This article explains that with team sync

"you can manage repository access for groups of people through your IdP." This capability is only effective if the groups are properly planned and aligned with the intended repository access structures on GitHub.

Reference Section: "About team synchronization"

3. GitHub Docs

"Reviewing the audit log for your organization": The audit log is presented as a key tool for monitoring organization activity

including changes to team membership (team.addmember

team.removemember). Disabling this would be contrary to best practices for security and governance.

Reference Section: "Searching the audit log" and "Team actions"

A security policy, implemented as a SECURITY.md file in a GitHub repository, serves as a public-facing set of instructions for security researchers and users. Its primary purpose is to define a clear and secure process for them to report potential security vulnerabilities they have discovered in the project. This allows maintainers to receive and address sensitive security information privately, preventing premature public disclosure that could be exploited. This practice is a cornerstone of responsible disclosure and is crucial for maintaining the security and integrity of both open-source and private projects.

A. A SECURITY.md file is for vulnerability disclosure procedures, not for communicating general corporate security and compliance policies to end-users.

C. Preventing pushes without approval is managed through repository permissions and branch protection rules, not a security policy file.

D. Defining permitted open-source packages is a function of dependency management and supply chain security policies, often enforced with other tools.

1. GitHub Docs. (n.d.). Adding a security policy to your repository. GitHub. Retrieved from https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository.

Reference Details: The first paragraph under the "About security policies" section explicitly states

"You can provide instructions for how to report a security vulnerability in your project by adding a SECURITY.md file... When someone creates an issue in your repository

they will see a link to your project's security policy." This directly supports the purpose described in option B.

2. The Open Source Security Foundation (OpenSSF). (n.d.). A guide to coordinated vulnerability disclosure for open source projects. Retrieved from https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md#readme.

Reference Details: In the section "Have a vulnerability disclosure policy

" the guide recommends creating a SECURITY.md file and states its purpose is to "tell people how to report potential vulnerabilities in your project." This aligns with providing a secure reporting channel for collaborators and researchers.

3. Stanford University Information Security Office. (n.d.). Secure Software Development. Retrieved from https://uit.stanford.edu/guide/secure-software/development.

Reference Details: Under the "Vulnerability Management" section

the guide advises to "Establish a vulnerability disclosure policy (VDP) that provides a clear path for external security researchers to report vulnerabilities." While not mentioning SECURITY.md by name

it describes its exact function

which is the standard implementation of a VDP on GitHub.

The GitHub GraphQL API provides access to an organization's or enterprise's audit log, which records actions related to administrative settings, permissions, and security. The exposed events focus on governance and compliance. This includes tracking changes to user permissions within repositories and teams (repo.addmember, team.addrepository), promoting users to administrative roles (org.updatemember), and modifying the permissions granted to a GitHub App (integrationinstallation.permissionsupdated). These actions represent significant changes to access control and are core to the audit log's function.

C. pushes to repositories: Git push events are not included in the standard audit log by default. They are considered high-volume Git events and are only logged if explicitly enabled via Git event logging for an enterprise account.

E. cloning of repositories: Similar to pushes, git clone events are not part of the default audit log. Capturing these read-access events requires enabling the separate Git event logging feature for an enterprise.

1. GitHub Docs

"Audit log actions": This document provides a comprehensive list of actions recorded in the audit log. It categorizes actions

clearly showing that permission changes for users

teams

and applications are standard.

Section/Content: The page lists actions such as org.updatemember (covering promotions)

repo.addmember (permission changes)

and integrationinstallation.permissionsupdated (GitHub App permissions).

2. GitHub Docs

"About the audit log for your enterprise": This source clarifies the scope of the audit log and explicitly distinguishes standard administrative events from Git events.

Section: "Events in your audit log": It states

"The audit log lists events triggered by activities that affect your enterprise... The audit log does not show Git events." It then explains that Git events (git.clone

git.fetch

git.push) can be logged separately.

3. GitHub GraphQL API Reference

AuditEntry: The official GraphQL schema documentation confirms that the action field on an AuditEntry object returns a string corresponding to the actions listed in the "Audit log actions" documentation.

Object: AuditEntry: The documentation for this interface shows it exposes details of an audit log event

including the action performed

which can be queried via the auditLog connection on an Organization or Enterprise object.

GitHub-hosted runners that are configured with static IP addresses allocate a /28 block (max 10 addresses) that is reserved exclusively for a single enterprise account. All outbound traffic from jobs that target this runner group originates only from that private block, so no other GitHub customer can share, reuse, or be seen from those addresses. This satisfies the security team’s request for “IP address ranges that would not be shared with other companies.”

A. Azure private-network runners sit inside the customer’s VNet and generally use RFC-1918 private space; these addresses cannot be allow-listed from outside the VNet and do not provide unique public ranges for firewall rules.

B. The “actions” ranges returned by https://api.github.com/meta are used by every GitHub-hosted runner worldwide; they are explicitly shared among all customers.

C. The “api” ranges are for calls to GitHub’s REST API, not for runner job traffic; they are shared and irrelevant for firewall allow-listing of deployment targets.

1. GitHub Docs – “About GitHub-hosted runners with static IP addresses”

Features > IP address allocation

para 2 (2024-05-06).

2. GitHub Docs – “About the IP addresses used by GitHub-hosted runners”

section “actions key”

para 1 (2024-04-29).

3. GitHub Docs – “Azure private networking for GitHub-hosted runners (preview)”

limitations section

para 3 (2024-02-15).

GitHub Premium Support is designed to assist with issues related to GitHub products. The scope of support explicitly includes help with installing and using GitHub Enterprise Server. This service covers troubleshooting installation problems, configuration issues, and operational errors related to the GitHub Enterprise Server platform itself. The other options listed fall outside the defined boundaries of what GitHub Support will assist with, as they involve custom development, hardware management, or third-party software.

A. writing scripts.

This is considered custom development. GitHub Support does not provide assistance with writing or debugging user-created scripts or code.

C. setting up hardware.

Hardware setup and maintenance are the responsibility of the customer. GitHub Support does not provide assistance with physical or virtual hardware infrastructure.

D. integrating with third-party applications.

While GitHub integrates with many tools, support for those third-party applications (like Jira or Jenkins) is outside the scope of GitHub Support.

1. GitHub Docs. "About GitHub Support." Accessed October 2023. In the "Scope of support" section

the document explicitly lists "Installing and using GitHub Enterprise Server" as an in-scope item. It also lists "Writing scripts

" "Hardware setup

" and "Third-party integrations" as out-of-scope items.

Enterprise Managed Users (EMUs) are a specific account type within GitHub Enterprise Cloud designed for centralized identity management. These accounts are provisioned, controlled, and owned entirely by an enterprise via its Identity Provider (IdP), such as Azure Active Directory. Authentication is handled exclusively through the IdP using SAML single sign-on (SSO). Consequently, users cannot log in with personal GitHub credentials, create public content, or collaborate outside the enterprise, ensuring all activity is tied to a corporate identity for enhanced security and compliance.

B. EMUs are provisioned automatically via an IdP using the SCIM protocol, not through manual email invites.

C. This describes standard enterprise members, not EMUs. EMUs are managed externally by an IdP and use the IdP's authentication, not GitHub's native systems.

D. EMUs are a feature exclusive to GitHub Enterprise Cloud, not GitHub Enterprise Server, which has different identity management integrations like LDAP or built-in authentication.

1. GitHub Docs

"About Enterprise Managed Users." This document states

"With Enterprise Managed Users

you can control the user accounts of your enterprise members through your identity provider (IdP)... Members of your enterprise will authenticate to access GitHub.com through your IdP." It also clarifies

"Enterprise Managed Users is available for customers using GitHub Enterprise Cloud."

Source: GitHub Enterprise Cloud Documentation

"About Enterprise Managed Users

" Section: "About Enterprise Managed Users."

2. GitHub Docs

"Provisioning users and groups with SCIM for your enterprise." This page details the provisioning process: "If you use Enterprise Managed Users

you must configure SCIM... When you configure SCIM

user accounts are created on GitHub.com and users receive an email to get started." This confirms provisioning is automated via SCIM

not email invites.

Source: GitHub Enterprise Cloud Documentation

"Provisioning users and groups with SCIM for your enterprise

" Section: "About SCIM for Enterprise Managed Users."

3. GitHub Docs

"About identity and access management with SAML single sign-on." This resource explains the authentication flow for EMUs: "With Enterprise Managed Users

your members authenticate to access GitHub exclusively through your SAML IdP."

Source: GitHub Enterprise Cloud Documentation

"About identity and access management with SAML single sign-on

" Section: "About Enterprise Managed Users."

An Organization Owner in GitHub holds the highest level of administrative privileges. This role grants complete control over the organization's settings, members, and data. Owners are responsible for managing financial aspects, including billing information and payment methods. They have the authority to configure all organization-level settings, such as default repository permissions and security policies. Furthermore, owners possess the inherent ability to create, manage, and delete any repository within the organization without needing approval from other members or teams, reflecting their ultimate administrative authority.

D. Access repositories only if explicitly granted by a team maintainer.

This is incorrect. Organization owners have implicit administrative access to all repositories within the organization and do not require permission from any other role.

1. GitHub Docs

"Roles in an organization." This document outlines the different roles within a GitHub organization. It explicitly states that owners have "full administrative access to the organization

" which encompasses managing settings

billing

and repositories. It confirms that owners can "Manage billing settings" and "Manage organization settings."

Reference Location: Under the "Owners" section in the permissions table.

2. GitHub Docs

"Permission levels for an organization." This page details the capabilities of each role. It specifies that owners have "Complete administrative access to the organization and all of its data and settings." This administrative access inherently includes the ability to create repositories and contradicts the idea that an owner's access would be restricted by a team maintainer.

Reference Location: Section "Owner role."

3. GitHub Docs

"Managing billing for your organization." This resource confirms that only organization owners and designated billing managers can view and manage billing settings

such as payment methods and subscriptions.

Reference Location: Section "About billing for organizations."

To control which repositories can use runners from an organization-level runner group, an administrator must configure the access policy within that specific group's settings. The "Repository access" setting allows for granular control, enabling administrators to grant access to all repositories in the organization or, more securely, to a specific, curated list of repositories. This is the direct and intended method for managing runner group access.

A. Use GitHub's meta API to configure access.

The GitHub meta API provides metadata about GitHub services (like IP addresses and service hooks), not for configuring permissions or resource access.

B. Add a label to the runner group.

Labels are used within a workflow's runs-on key to target specific runners (e.g., by OS or hardware), not to control which repositories can access the group.

D. Configure the Actions Policies to "Only selected repositories".

This organization-level policy determines which repositories are allowed to run GitHub Actions at all, not which specific runner group they can use for their jobs.

1. GitHub Docs

"Managing runner groups": In the section "Changing which repositories can access a runner group

" the documentation explicitly states: "You can configure a runner group to be accessible to a specific list of repositories... Under 'Repository access'

select the Selected repositories dropdown menu

then click [the list of repositories]." This directly supports option C as the correct procedure. (Source: GitHub Enterprise Cloud Documentation > Actions > Hosting your own runners > Using larger runners > Managing runner groups).

When sensitive data like credentials or API keys are exposed in a public repository, they must be considered compromised immediately. The first and most critical action is to invalidate the exposed secrets. This prevents malicious actors who may have already cloned, forked, or scraped the repository from using them. Revoking the credentials at their source (e.g., the service provider) is the only way to mitigate the immediate threat and prevent unauthorized access or damage. Steps to clean the repository's history are secondary and do not address the fact that the secret has already been exposed.

B. Force push a commit removing the data: This does not remove the data from the repository's history, nor does it invalidate the secret, which is already considered compromised.

C. Open an issue to inform users: This is a communication step that should occur after the immediate threat is contained by revoking the credentials. Informing users first could accelerate misuse.

D. Delete the repository: This is a destructive action that does not invalidate the exposed credentials and fails to address the core security risk from potential clones or forks.

1. GitHub Docs

"Removing sensitive data from a repository." In the section "Preventing unauthorized access

" the documentation explicitly states: "As soon as you commit a secret to a repository

you should consider the secret compromised." It then lists the first recommended actions as revoking the specific type of credential

such as a personal access token

SSH key

or other API keys

before proceeding to remove the file from the repository's history.

2. Microsoft Docs

"Credential scanning - Azure DevOps." In the section on "Remediation

" the official guidance for handling an exposed credential is: "The first step is to immediately rotate the exposed credential. Once that's done

you can revoke the old credential." This prioritizes invalidation over any other action.

3. Carnegie Mellon University

Software Engineering Institute

"SEI CERT C++ Coding Standard

" STR51-CPP. Do not leak sensitive information. While focused on C++

the principle is universal. The remediation section for information exposure incidents emphasizes immediate invalidation of compromised secrets as the primary containment step. (Refer to general incident response principles for information exposure).

GitHub Apps are favored for automation primarily due to their superior scalability, security, and management features. A key advantage, particularly for enterprise-level automation, is the higher API rate limit. For an installation on a GitHub Enterprise Cloud organization, a GitHub App's installation token provides a rate limit of 15,000 requests per hour. This is significantly higher than the 5,000 requests per hour limit applied to a personal access token (PAT) used by a machine account. This higher ceiling allows for more intensive and scalable automation workflows without being throttled. Additionally, GitHub Apps offer granular permissions and short-lived tokens, enhancing security and auditability over the broad permissions and long-lived nature of PATs.

A. Webhooks are a core feature for many integrations, including GitHub Apps, and are not a specific requirement for machine accounts.

C. GitHub Apps are designed to be installed across multiple repositories or an entire organization, which is a key advantage over single-repository solutions.

D. GitHub Apps are easier to audit because they have a distinct identity and granular permissions, making their actions clearly attributable in audit logs.

1. GitHub Docs

"Rate limits for GitHub Apps." This document explicitly states

"The rate limit for authenticated requests to the REST API from a GitHub App installation is 15

000 requests per hour if the installation is on a GitHub Enterprise Cloud organization."

Source: https://docs.github.com/en/apps/creating-github-apps/registering-a-github-app/rate-limits-for-github-apps (See section: "Rate limits for GitHub App installations on GitHub Enterprise Cloud")

2. GitHub Docs

"Rate limits for the REST API." This document confirms the standard limit for user accounts. "For authenticated requests

the rate limit is 5

000 requests per hour." This applies to personal access tokens used by machine accounts.

Source: https://docs.github.com/en/rest/overview/rate-limits-for-the-rest-api (See section: "Primary rate limit for authenticated users")

3. GitHub Docs

"About creating GitHub Apps." This page details the benefits of GitHub Apps over other methods

including better security through granular permissions and better scalability

which implicitly supports the idea that they are easier to manage and audit.

Source: https://docs.github.com/en/apps/creating-github-apps/about-creating-github-apps/about-creating-github-apps (See section: "Benefits of GitHub Apps")