GitHub Administration — Practice Set 1

Question 1

A company is setting up GitHub Enterprise Cloud with Enterprise Managed Users (EMU). How does an EMU account differ from a personal GitHub account?

Accepted Answer

Enterprise Managed Users are fully controlled by the enterprise identity provider — accounts are created, updated, and deprovisioned by the enterprise via SCIM, not by individual users. EMU accounts are scoped to the enterprise: they cannot follow users, star repositories, or contribute to repositories outside the enterprise's organizations. This is the key difference from personal GitHub accounts, which are fully independent. Personal accounts require email verification, not EMU accounts managed by the IdP.

Question 2

An organization wants to enforce SAML SSO so that members must authenticate through the company's identity provider before accessing organization resources. After enabling SAML SSO, what happens to members who have not yet authorized their personal access tokens (PATs) through SAML?

Accepted Answer

When SAML SSO is enforced, API access to organization resources via PATs also requires SAML authorization. Users must explicitly authorize each PAT for the SSO-protected organization in their GitHub account settings. PATs that have not been SSO-authorized will receive a 403 error when used against that organization's resources. Existing PATs are not automatically revoked — only unauthorized ones stop working. There is no automatic conversion to OAuth tokens.

Question 3

An enterprise uses Okta as its identity provider and wants GitHub teams to be automatically kept in sync with Okta groups. Which GitHub feature enables this automatic team membership synchronization?

Accepted Answer

Team synchronization (available with SAML SSO + supported IdPs like Azure AD/Entra ID or Okta) allows GitHub to automatically add or remove team members based on the user's group membership in the identity provider, managed via SCIM. This eliminates the need for manual team management. Branch protection rules control merge requirements, not identity. A custom Actions workflow is a workaround but not the native solution. SAML SSO authenticates users but does not by itself sync team membership — SCIM and team sync are required.

Question 4

A GitHub organization has five repositories. An administrator wants a specific external collaborator to have triage access to two repositories but no access to the other three. What is the correct approach?

Accepted Answer

External collaborators are not organization members and must be added to repositories individually. Adding them directly to a repository with the Triage permission gives scoped access to only that repository. Organization membership roles (A) apply to members, not external collaborators. Teams require the user to be an organization member first — external collaborators cannot be added to teams. Granting the Owner role (D) would give full organization access, which is excessive.

Question 5

An enterprise administrator needs to audit which organization members have admin access to a sensitive repository and verify that no unauthorized users have been granted access in the last 30 days. What is the most effective approach?

Accepted Answer

The definitive way to audit access is to combine the current collaborator list (Settings > Collaborators and teams) with the enterprise/organization audit log, which records all permission-change events including member additions with timestamps, actors, and affected resources. Filtering for the last 30 days gives a clear picture of recent changes. Self-reporting (B) is unreliable. A daily workflow (C) shows current state but not historical changes. Branch protection (D) does not enumerate who has admin access.

Question 6

A GitHub Enterprise administrator receives a support ticket about an issue that requires GitHub Support involvement. Before contacting GitHub Support, what artifact should the administrator generate to help diagnose server-side issues?

Accepted Answer

Support bundles are the standard diagnostic artifact for GitHub Enterprise Server issues — they contain system logs, configuration metadata, and diagnostic information that GitHub Support uses to investigate problems. They are generated from the management console (site admin panel) or via the `ghe-support-bundle` CLI command. Audit log CSV exports show user activity but not system diagnostics. Network captures are rarely the first step and are not specific to GitHub issues. Workflow run logs address CI/CD issues, not platform-level problems.

Question 7

A company is evaluating GitHub Enterprise deployment options. They need data residency in the European Union and want all user accounts managed by their identity provider with no personal GitHub.com accounts. Which deployment model best fits these requirements?

Accepted Answer

GitHub Enterprise Cloud with Data Residency allows organizations to store their data in a specific geographic region (including the EU). Combined with Enterprise Managed Users, all accounts are fully controlled by the enterprise IdP — no personal GitHub.com accounts are involved. GHES on-premises (A) provides data residency but requires the company to manage infrastructure. GHEC with personal accounts + SAML (B) does not enforce data residency by default. IP allow lists (D) restrict network access but do not address data residency or account management.

Question 8

An enterprise administrator notices that the reported consumed licenses are close to the purchased seat count. Which GitHub feature allows them to monitor detailed license consumption and identify unused seats?

Accepted Answer

Enterprise license consumption is tracked in the enterprise account's Billing section, which shows the number of seats used vs. purchased and can export a license usage report listing all license holders. This allows admins to identify users who have licenses but are inactive. Traffic insights (A) show repository visit metrics. Dependabot alerts (C) relate to security vulnerabilities. Actions usage reports (D) show CI/CD minutes, not license seat allocation.

Question 9

A security administrator wants to ensure that no one can push secrets (such as AWS access keys or API tokens) to any repository in their GitHub organization. Which GitHub Advanced Security feature should be enabled?

Accepted Answer

Secret scanning with push protection detects known secret patterns (tokens, keys, credentials) in code being pushed and blocks the push before the secret reaches the repository history. Dependabot (A) manages dependency vulnerabilities. CodeQL (C) performs static analysis for code security vulnerabilities but does not detect secrets in the same push-blocking manner. PR review requirements (D) slow down changes for human review but do not automatically detect secrets.

Question 10

An organization wants to automatically receive pull requests that update vulnerable dependencies to safe versions. Which GitHub feature creates these automated fix PRs?

Accepted Answer

Dependabot security updates is the native GitHub feature that automatically opens pull requests to update dependencies with known security vulnerabilities to the minimum safe version. It integrates with the GitHub Advisory Database. A custom Actions workflow (A) can accomplish something similar but requires maintenance and is not the native solution. CodeQL analyzes code logic, not dependency versions. Secret scanning addresses credentials, not dependency vulnerabilities.

Question 11

An enterprise security team wants all repositories to have branch protection, required code owners review, and no direct pushes to `main`. Rather than configuring each repository individually, how can an administrator enforce these rules organization-wide?

Accepted Answer

Repository rulesets (available at organization and enterprise levels) allow administrators to define rules that apply automatically to all repositories — or a filtered subset — without requiring per-repository configuration. Rules can enforce branch protection, required approvals, and push restrictions. Template repositories (C) only apply configuration to new repositories, not existing ones. The member privileges setting (D) can set some defaults but does not provide the granular ruleset capabilities. Manual emails (A) are not scalable and not enforceable.

Question 12

A compliance officer needs a log of all administrative actions taken on the organization's repositories over the past 6 months — including who changed permissions, who created or deleted repositories, and who changed branch protection rules. Which GitHub feature provides this?

Accepted Answer

The organization audit log (accessible via Settings > Audit log or the API) records administrative actions including repository creation/deletion, permission changes, branch protection changes, and more — each with the actor's identity, timestamp, and affected resource. The commit history (A) shows code changes, not admin actions. Actions run history (C) shows CI/CD executions. Insights (D) shows code contribution metrics, not admin events.

Question 13

A developer at a regulated company accidentally pushed an AWS secret access key to a public repository. Secret scanning detected it and GitHub notified AWS, who revoked the key. The administrator needs to implement a process so this never happens again. Which combination of controls is most effective?

Accepted Answer

Push protection (blocking the push before it reaches the repository) combined with developer education to use proper secrets management (GitHub Actions secrets, Azure Key Vault, AWS Secrets Manager, etc.) addresses both the technical control and the root cause. Making repositories private (B) reduces exposure but does not prevent accidental commits. GPG signing (C) provides non-repudiation but does not detect or block secrets. Requiring reviewers on config files (D) adds a human gate but reviewers may not notice obfuscated secrets and the secret is already in the push.

Question 14

A development team wants to integrate a third-party CI/CD tool with their GitHub organization via a GitHub App. An administrator is reviewing the proposed installation. What is the key difference between a GitHub App and an OAuth App in terms of permissions and access scope?

Accepted Answer

GitHub Apps use fine-grained, resource-specific permissions (e.g., read access to specific repositories, write to issues only) and authenticate as the app itself, not as a user — this limits blast radius. OAuth Apps operate with broad user-delegated scopes (e.g., `repo`, `admin:org`) and act on behalf of the authorizing user, meaning they inherit the user's full permissions within those scopes. This makes GitHub Apps the preferred choice for integrations from a security posture perspective. OAuth Apps do not require per-call approval. Both app types can read and write. They differ fundamentally in permission model, not just registration.

Question 15

An organization's security policy requires that all personal access tokens (PATs) used to access the organization must expire within 90 days and be approved by an administrator. Which GitHub controls can enforce these requirements? Choose 2.

Accepted Answer

Organizations can set a policy that restricts fine-grained PAT lifetime to a maximum number of days (A) and can require administrator approval before fine-grained PATs are activated for the organization (B). These are native GitHub organization policies. 2FA (C) improves account security but does not limit PAT expiry. A custom audit workflow (D) provides visibility but does not enforce the policy technically. Setting default repository permission to Read (E) affects what unauthenticated/base-level members can see, not PAT expiry.

Question 16

A platform team's security response plan requires that when a critical security advisory is published for a dependency used by the organization's repositories, the affected repositories are automatically notified within 24 hours. Which GitHub feature fulfills this requirement with no custom tooling?

Accepted Answer

Dependabot continuously monitors the dependency graphs of enabled repositories against the GitHub Advisory Database. When a new advisory is published that matches a dependency in use, Dependabot creates a security alert in the repository and notifies administrators — typically within hours of the advisory being published. CodeQL (A) analyzes code logic, not dependency advisories, and requires a scheduled workflow. Secret scanning (C) detects exposed credentials, not CVEs in dependencies. While the `security_advisory` webhook event exists, setting up a workflow to handle it (D) requires custom development, whereas Dependabot is a zero-configuration native feature.

Question 17

An enterprise administrator wants to ensure that every repository's CI/CD workflows use the same approved set of reusable workflow templates. How should these workflows be stored and made available?

Accepted Answer

The recommended enterprise pattern is to maintain reusable workflows in a dedicated central repository (often named something like `.github` or `shared-workflows`). Consuming repositories reference them via `uses: org/central-repo/.github/workflows/workflow.yml@version`. This centralizes governance and ensures updates propagate to all consumers. Copying files (A) into each repo creates divergence over time. Storing in a public repo (C) exposes internal workflows externally. There is no built-in GitHub Actions feature to automatically inject steps enterprise-wide (D).

Question 18

An enterprise policy mandates that only actions from the enterprise's own organizations and GitHub-owned actions can be used in any workflow. A repository admin attempts to add a third-party Marketplace action. What happens?

Accepted Answer

Enterprise Actions policies are enforced at runtime — if a workflow references an action that falls outside the allowed policy (e.g., a third-party Marketplace action when only organization and GitHub-owned actions are permitted), the workflow run fails with a policy violation error. Repository admins cannot override enterprise-level policies. There is no automatic quarantine/sandbox mode. Actions blocked by policy do not generate Security tab alerts; the workflow simply fails.

Question 19

A GitHub Enterprise Cloud organization uses self-hosted runners in an Azure virtual network. Workflows running on these runners need to access an internal API that is not reachable from the public internet. The security team prohibits opening public inbound ports. What is the recommended GitHub-native solution?

Accepted Answer

GitHub Enterprise Cloud supports Azure private networking for self-hosted runners, allowing runner virtual machine scale sets to be deployed within an Azure VNet. This gives workflows running on those runners native access to private Azure resources (like an internal API behind a private endpoint) without exposing anything to the public internet. IP allow lists (A) control inbound access to GitHub, not outbound runner connectivity to internal APIs. OIDC + Private Link (B) handles authentication and private routing separately but doesn't address the runner's network placement as cleanly. Storing the URL as a secret (D) doesn't solve the network reachability problem.

Question 20

An administrator wants to store a database connection string that should be available to all workflows across all repositories in an organization but should not be visible in plaintext to repository maintainers. Which GitHub feature is most appropriate?

Accepted Answer

Organization-level encrypted secrets are stored encrypted and are never exposed in plaintext through the GitHub UI or API — only workflow runs can access the value, and it is masked in logs. Configuration variables (`vars`) (A) store non-sensitive values that are visible in plaintext in the UI. Dependabot secrets (C) are specifically for Dependabot workflows, not general CI/CD workflows. There is no cross-repository shared environment variable feature (D) at the organization level — environment secrets are per-repository.

Question 21

A self-hosted runner registered to an organization is experiencing intermittent job failures. An administrator needs to diagnose the issue. Which of the following steps are appropriate for troubleshooting self-hosted runner problems? Choose 2.

Accepted Answer

The runner's `_diag` directory contains detailed application logs that capture connection attempts, job assignment, and execution errors — these are the primary diagnostic source. The organization's Settings > Actions > Runners page shows runner status (online/offline/idle/busy) and recent job assignments, helping to identify patterns. Dependabot alerts (C) relate to code vulnerabilities, not runner health. Contacting Support (D) before reviewing available diagnostics wastes time and is not the recommended first step. `ACTIONS_RUNNER_DEBUG` (E) provides additional debug output in workflow logs, not runner-level diagnostics, and is set as a secret/variable in the repo, not on the runner itself.

Question 22

A development team wants to store API keys used by Dependabot to access private package registries. Where should these secrets be stored so they are available specifically to Dependabot update workflows?

Accepted Answer

Dependabot runs in an isolated environment and does not have access to regular repository secrets for security reasons. Secrets that Dependabot needs (such as credentials for private package registries) must be stored as Dependabot-specific secrets in Settings > Secrets and variables > Dependabot. These are separate from Actions secrets. Referencing `${{ secrets.API_KEY }}` in a Dependabot-triggered workflow (A) will not work because Dependabot cannot read Actions secrets. Plaintext values in `dependabot.yml` (C) would be exposed in the repository. Configuration variables (D) are non-sensitive and not appropriate for API keys.

Question 23

An enterprise administrator wants to investigate whether a specific user performed an action that deleted a repository two days ago. Which tool provides the most direct answer?

Accepted Answer

Repository deletion events are recorded as `repo.destroy` in the GitHub audit log, along with the actor (who did it), timestamp, and repository name. Filtering the audit log by this action and the past 48 hours provides a direct, authoritative answer. Code frequency graphs (A) show commit activity over time, not admin events. The user's public activity feed (C) only shows public contributions, not admin actions. GitHub Support logs (D) are an escalation path, unnecessary when the audit log contains the information.

Question 24

An enterprise has 500 GitHub Enterprise Cloud seats but the billing dashboard shows only 320 active users in the past 90 days. The finance team wants to optimize costs. What should the administrator do to identify and reclaim unused seats?

Accepted Answer

The correct process is to export the license usage report (which includes last login date per user), identify inactive accounts, and coordinate with team leads to confirm they are genuinely unused before removing them. This prevents accidentally removing accounts that are still needed. Immediately deleting 180 accounts (B) risks removing active users or service accounts. Purchasing more seats (C) increases costs without solving the problem. Enabling Actions (D) does not reclaim seats.

Question 25

An administrator is reviewing GitHub Actions usage for the enterprise and notices that Actions minutes consumption has increased 300% month-over-month. Which approaches help identify the root cause and optimize costs? Choose 2.

Accepted Answer

The first step is to identify the source of the increase using the Actions usage report (A), which breaks down consumption by repository and workflow. Once the heavy consumers are identified, workflow optimization (D) — fixing overly broad triggers, adding matrix fail-fast, improving cache hit rates, trimming unnecessary steps — is the targeted fix. Setting spending limits (B) prevents overage charges but doesn't reduce consumption or identify the cause. Disabling Actions entirely (C) halts all CI/CD and is too disruptive. Migrating to self-hosted runners (E) eliminates billed minutes but requires significant infrastructure investment and may not be appropriate for all teams.

GH-100 — GitHub Certified: GitHub Administration