GitHub Foundations · 15% of the exam

Project Management and GitHub Administration: free practice questions

5 sample questions from our 23-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real GitHub exam.

1. A security engineer is investigating a suspicious activity in a GitHub Enterprise organization. They need to see a record of when a specific user's organization membership was changed to 'owner' in the last 30 days. Where should the engineer look?

  • A. The repository's Insights tab under Contributors
  • B. The organization's Audit Log, filtering by the `org.update_member` event✓ Correct
  • C. The user's personal Security log in their profile settings
  • D. The enterprise account's Billing section
Explanation

The organization's Audit Log is the correct location. The `org.update_member` event is recorded whenever an organization member's role is changed (e.g., from member to owner or vice versa), and the log can be filtered by event type, actor, and date range. The repository Insights tab shows contribution statistics like commits and pull requests, not organization-level membership changes. A user's personal Security log records actions on their own account (e.g., logins, SSH key additions) rather than organization-level administrative events. The Billing section tracks spending and payment information, not membership role changes.

2. A security team wants to audit which organization members have accepted or not yet accepted their invitations to join the GitHub organization, and export this data over the past 90 days for a compliance report. The team wants to use a scriptable, automatable method. Which approach is MOST appropriate?

  • A. Use the GitHub Audit Log API with a filter for `org.invite_member` and `org.accept_invitation` events, then export the results programmatically✓ Correct
  • B. Download the organization's member list from Settings → Members as a CSV and cross-reference it with a manually maintained invitation spreadsheet
  • C. Use GitHub Insights to view member onboarding trends and export the contribution graph as a compliance artifact
  • D. Query the GitHub REST API `/orgs/{org}/members` endpoint with the `filter=2fa_disabled` parameter to find pending members
Explanation

Using the GitHub Audit Log API with filters for invitation-related events is the most appropriate approach. The audit log captures `org.invite_member` and `org.accept_invitation` events, is queryable via the API, supports time-range filtering (including 90-day windows), and can be exported programmatically — satisfying all requirements for automation and compliance reporting. — Manually downloading a member list and cross-referencing a spreadsheet is not scriptable or automatable, and does not reflect historical invitation states — only the current member roster. — GitHub Insights provides contribution metrics (commits, PRs, code frequency) for members and does not record invitation status, acceptance events, or onboarding history. — The `/orgs/{org}/members` endpoint with `filter=2fa_disabled` returns current members who have 2FA disabled — it is unrelated to invitation status and does not provide historical acceptance data.

3. A developer configures a webhook on a GitHub repository to send push event payloads to an internal CI server. After several successful deliveries, the CI server starts returning HTTP 500 errors. The developer wants to investigate the failed deliveries without triggering new pushes. What is the BEST approach?

  • A. Delete and recreate the webhook with a new secret to reset the delivery queue
  • B. Navigate to the repository's webhook settings, view recent deliveries, inspect the payload and response, and use the 'Redeliver' button to retry failed deliveries✓ Correct
  • C. Check the repository's audit log for webhook failure events and rerun the last workflow
  • D. Disable the webhook, fix the CI server, and re-enable it; GitHub will automatically replay all missed deliveries
Explanation

Viewing recent deliveries and using the Redeliver button is the best approach. GitHub's webhook settings page shows a log of recent delivery attempts, including the full request payload, response headers, and response body. The Redeliver button allows the developer to resend a specific payload without needing to trigger a new push event — ideal for debugging. — Deleting and recreating the webhook would lose the delivery history and does not help debug the existing failures; it also does not replay missed events. — The audit log records security and administrative events, not webhook payload details or CI server responses; it cannot be used to retry webhook deliveries. — GitHub does NOT automatically replay missed webhook deliveries when a webhook is re-enabled. Any deliveries that failed while the webhook was disabled are lost unless manually redelivered.

4. A GitHub Enterprise Cloud organization enforces SAML SSO. A new employee successfully authenticates via the IdP and is provisioned into the organization via SCIM. Later, the employee's account is deprovisioned in the IdP. What is the MOST LIKELY immediate outcome for the employee's GitHub organization membership?

  • A. The employee retains full organization access until an organization Owner manually removes them
  • B. The employee's external identity is unlinked from their GitHub account, and SCIM removes them from the organization automatically✓ Correct
  • C. The employee's GitHub account is permanently deleted from GitHub.com
  • D. The employee loses access only to private repositories but can still view public repositories in the organization
Explanation

When SCIM is configured, the identity provider manages the user lifecycle end-to-end. When the employee's account is deprovisioned in the IdP, SCIM sends a deprovision request to GitHub, which unlinks the SAML external identity and removes the user from the organization automatically — without requiring manual Owner intervention. The employee's GitHub.com personal account itself is NOT deleted; SCIM only manages organization membership, not the underlying GitHub account. Retaining full access until manual removal describes the behavior when SCIM is NOT configured; with SCIM, the process is automated. Selective loss of private repository access is not how SAML/SCIM deprovisioning works — membership in the organization is revoked entirely.

5. A platform team wants to install an integration that acts autonomously — running scheduled jobs to triage stale issues, posting comments, and managing labels across all 50 repositories in their organization — using its own distinct identity (not tied to any individual user account). Which type of GitHub integration is BEST suited for this use case?

  • A. OAuth App, because it can act on behalf of any user in the organization
  • B. GitHub App, because it can be installed at the organization level and acts under its own bot identity✓ Correct
  • C. A personal access token (PAT) scoped to the organization
  • D. A deploy key configured on each repository
Explanation

GitHub Apps are specifically designed for this scenario. They can be installed organization-wide (covering all repositories at once), act under their own bot identity independent of any individual user, use fine-grained permission scopes, and authenticate via short-lived JWTs and installation tokens — making them ideal for automated, server-side integrations. OAuth Apps act on behalf of a specific authenticated user, meaning their actions are attributed to that user and tied to user session tokens; they are not suitable for autonomous, identity-independent automation. A personal access token is tied to an individual user account, creating a dependency on that user's account status and violating least-privilege principles. Deploy keys provide Git push/pull access to a single repository only and cannot perform API actions like posting comments or managing labels.

18 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free