Explanation:
A support bundle is a collection of logs, diagnostics, and system information from the GHES appliance, used for troubleshooting by GitHub Support. It is generated directly from the appliance's administrative shell or management console, not from within the GitHub application's web interface or via API. Therefore, direct filesystem access to the server is required.

Correct Option:

C. Administrator SSH access to the appliance
The ghe-support-bundle command must be executed via SSH on the GHES appliance's administrative shell. This is the primary and documented method. Support bundles contain sensitive system data and logs that are only accessible at the server infrastructure level, which web-based administrator accounts or API tokens cannot directly reach.

Incorrect Options:

A. Approval from GitHub Support
While you submit the bundle to GitHub Support for analysis, their prior approval is not a technical requirement to generate the file. The generation is a local administrative action.

B. A custom GitHub Action in the root repo
GitHub Actions run in a containerized environment on runners and have no permission or access to the underlying host server's system files and logs needed for the support bundle.

D. A GitHub App with read:org permissions
GitHub Apps operate via the GitHub API and are restricted to repository, organization, and user-level data. They cannot access the underlying server's operating system diagnostics, logs, or configuration files.

Reference:
GitHub Docs: "Troubleshooting - Providing data to GitHub Support - Generating a support bundle." The documentation explicitly states to use SSH to access the appliance and run the ghe-support-bundle command.

Explanation:
The question tests the core architectural difference between standard, federated accounts and Enterprise Managed Users (EMUs). Standard accounts are user-owned identities linked to an enterprise, while EMUs shift identity management entirely to the enterprise's Identity Provider (IdP). This changes the authentication flow and account lifecycle.

Correct Option:

A. EMUs are fully controlled by an IdP and cannot log in with personal credentials
IdP Control: The lifecycle (creation, suspension, deletion) of an EMU account is governed by SCIM provisioning from the enterprise's IdP (e.g., Azure AD, Okta).

Authentication: EMUs must authenticate via the enterprise's SAML single sign-on (SSO) identity provider. They cannot use a password or personal credentials to log in directly to GitHub.com.

Incorrect Options:

B. EMUs can only be created using email invites
This is false. EMUs are not created via email invites. They are provisioned automatically via SCIM when a user is assigned to the GitHub Enterprise application in the IdP. Email invites are a method for standard accounts.

C. EMUs are managed in GitHub and use GitHub authentication

This is the exact opposite of the truth. This describes standard accounts. EMUs are managed in the IdP, and they use IdP authentication (SAML SSO), not native GitHub authentication.

D. EMUs are only available for GitHub Enterprise Server
This is incorrect. EMUs are a feature of GitHub Enterprise Cloud. They are not available for the self-hosted GitHub Enterprise Server, which uses SAML SSO for authentication but does not support SCIM-driven full lifecycle management.

Reference:
GitHub Docs: "About Enterprise Managed Users." The documentation states: "Enterprise Managed Users are... centrally managed through your identity provider (IdP)" and "With Enterprise Managed Users, your IdP becomes the source of truth for authentication and user information."

Explanation:
The question focuses on forensic traceability in GitHub's audit log. When API access occurs, the audit log captures specific fields that link an action to an actor. For token-based access, identifying the specific token, its owner (user or machine), and the source of the request is critical for security investigations and accountability.

Correct Option:

D. The token ID, requesting IP address, and associated user

Token ID: Uniquely identifies the specific Personal Access Token (PAT), OAuth token, or GitHub App installation token used.

Requesting IP Address: Provides the source location of the API request, crucial for identifying suspicious access from unexpected regions.

Associated User: Shows which user account (for PATs) or GitHub App (for installation tokens) owns and authorized the token, establishing responsibility.

Incorrect Options:

A. The token's permissions and the geographic region of access
While important context, permissions define what the token can do, not who used it. The geographic region is inferred from the IP address but is not a specific audit log field; the raw IP is the evidential data point.

B. The token expiration date
The expiration date is a security attribute of the token itself but does not appear in individual audit log entries for API calls. It does not help identify who used the token at a specific time.

C. The GitHub Actions runner name
This is irrelevant for general API token usage. A runner name would only appear in audit logs for Actions workflow events, not for direct API calls made with a token from a user or application.

Reference:
GitHub Docs: "Reviewing the audit log for your organization - Using the audit log API." The API response schema for audit log events includes key actor fields such as actor (user), actor_id, and details within the documentation_url payload that can include the token's unique fingerprint and the source IP address (@octo-org/hello-world #4 was approved by monalisa from IP xxx.xxx.xxx.xxx).

Explanation:
The question asks where to view and control user and team permissions for a specific repository. This is a core repository administration task focused on access control, distinct from deployment settings, automation logs, or branch security rules. The correct tool is the dedicated access management interface within the repository's settings.

Correct Option:

C. Repository Settings > Manage Access
This is the direct administrative panel for repository collaborators.

It provides a complete list of individuals, teams, and apps with access, displaying their permission level (e.g., Read, Write, Admin).

From here, you can invite new collaborators and change or remove existing permissions, fulfilling the request to review and manage access.

Incorrect Options:

A. GitHub Pages Settings
This area configures the source branch and build settings for publishing a static website. It does not show a list of users or their repository permissions.

B. GitHub Actions Logs
These logs show the execution history and output of workflow runs. They are used for debugging automation, not for reviewing user access controls.

D. Branch Protection Rules
These rules enforce workflows on specific branches (e.g., requiring pull request reviews or status checks). They control how changes are merged, not who has general access to the repository.

Reference:
GitHub Docs: "Managing an individual's access to an organization repository." The documentation directs administrators to navigate to the repository, click Settings > Collaborators and teams (often labeled "Manage access") to see and manage people and teams with access.

Explanation:
The question is about implementing fine-grained access control for shared GitHub Actions runners at the organization level. Organization runner groups are collections of self-hosted runners intended to be shared across multiple repositories. The default setting allows access from all repositories, but administrators can restrict access to an approved list.

Correct Option:

C. Configure repository access in the runner group settings.
This is the direct and primary administrative method. Within an organization's Settings > Actions > Runner groups, selecting a specific group provides a "Repository access" section.

Here, you can change the access policy from "All repositories" to "Selected repositories" and then explicitly add the specific repositories that are allowed to use runners in that group.

This configuration enforces the restriction at the runner group level itself.

Incorrect Options:

A. Use GitHub's meta API to configure access.
While technically possible via the REST API (/orgs/{org}/actions/runner-groups/{runner_group_id}/repositories), this is not the standard or simplest administrative method. The question asks for what needs to be done, implying the standard procedure, not the implementation tool.

B. Add a label to the runner group.
Labels are used within workflows (runs-on: [self-hosted, my-label]) to target specific runners, not to define which repositories are allowed to use the runner group. Labels control runner selection after repository access is already granted.

D. Configure the Actions Policies to "Only selected repositories".
This describes a policy setting that applies to GitHub-hosted runners or overall Actions permissions, not to self-hosted runner groups. This setting is found in Settings > Actions > General under "Actions permissions," but it controls whether repositories can use Actions at all, not their access to specific organization runner groups.

Reference:
GitHub Docs: "Managing access to organization runners - Using runner groups at the organization level." The documentation explicitly states: "You can configure an organization runner group so that it's accessible to a specific list of repositories... by choosing Selected repositories."

Explanation:
The GitHub Audit Log GraphQL API exposes a subset of the nearly 100+ event types available in the web UI or REST API. The schema is focused on security, compliance, and administrative events related to organizations, members, and integrations, rather than granular repository development activity.

Correct Options:

A. changes in permissions
This refers to events like org.update_member (when an organization owner changes a member's role) or team.update_member_role. These permission changes are core administrative actions and are exposed via the GraphQL API under the AuditEntry interface.

B. changes to permissions of a GitHub App
Events like oauth_application.create or github_app.update are included. Configuring or updating a GitHub App's permissions is a critical security event for organization resources and is available in the GraphQL audit log.

D. cloning of repositories
The event repo.clone (audited when Git clone operations occur) is specifically exposed via the GraphQL API. This tracks access to repository source code, which is a key security and compliance data point.

Incorrect Options:

B. pushes to repositories
This is NOT exposed by the GraphQL audit log API. While repo.push events are logged in the web UI and REST API, they are excluded from the GraphQL schema, which omits high-volume, development-specific events to focus on governance and security.

Promoting users to administrators
This IS exposed and would be correct, but it is likely a mislabeled part of option A. If considered a separate choice, it refers to the org.update_member event (changing role to owner) and is part of the GraphQL API.

Reference:
GitHub Docs: "Using the Audit Log API - Supported Git events / Audit log GraphQL API." The documentation explicitly lists the subset of audit log actions available in the GraphQL API, including:

org.update_member (covers permission changes and admin promotion)

oauth_application.create / github_app.update (covers app permission changes)

repo.clone
It also explicitly states that repo.push events are not available in the GraphQL API.

Explanation:
The SCIM (System for Cross-domain Identity Management) protocol automates user identity lifecycle management between an Identity Provider (IdP) and GitHub Enterprise Cloud. Its core functions are provisioning (creating accounts), updating profiles, and de-provisioning (deactivating/suspending accounts) based on the IdP's directory. It does not handle repository-level configurations or generate credentials.

Correct Options:

A. SCIM synchronizes changes to user attributes from the identity provider to GitHub.
If a user's name, email, or group membership changes in the IdP, SCIM automatically pushes those updates to the corresponding user's identity in GitHub, ensuring profile information remains synchronized.

B. SCIM deactivates GitHub accounts when users are deleted from the identity provider.
This is a core de-provisioning function. When a user is unassigned from the GitHub app or deleted in the IdP, SCIM sends a command to suspend (deactivate) their managed user account in GitHub, revoking access.

D. SCIM automates user provisioning when new users are added to the identity provider.
This is the core provisioning function. When a new user is assigned to the GitHub Enterprise Cloud application in the IdP, SCIM automatically creates and links a corresponding Enterprise Managed User account in GitHub.

Incorrect Options:

C. SCIM automatically deletes organization repositories when administrators are removed.
SCIM manages user identities, not repository resources. Removing a user's admin role or account does not trigger any action against repositories they owned or created.

E. SCIM generates authentication tokens for accessing GitHub's REST API.
SCIM is for identity lifecycle management, not authentication or credential generation. Authentication is handled separately by SAML SSO. Tokens (like PATs) are created by users within GitHub.

F. SCIM configures repository permissions based on user roles within the organization.
SCIM can sync IdP groups to GitHub Enterprise teams, which can have repository access. However, SCIM itself does not configure repository permissions. That mapping is done in GitHub by team administrators after the group/team sync.

Reference:
GitHub Docs: "Configuring SCIM provisioning for Enterprise Managed Users." The documentation states: "SCIM... adds, manages, and removes team members' access... When you assign the application to a user on your IdP, the IdP will prompt GitHub Enterprise Cloud to create an account... If you unassign the user from the application on your IdP, the IdP communicates with GitHub to deactivate the user's account."

Explanation:
The question focuses on the automated workflow for secret scanning on public repositories. GitHub's secret scanning for public repos has specific integrations with partner service providers. Its primary, automated action is notifying the entity that can actually revoke or rotate the exposed credential, as they are the only ones who can mitigate the security risk.

Correct Option:

A. It alerts the service provider (e.g., AWS, Stripe).
For public repositories, GitHub has a Secret Scanning Partner Program. When a known partner secret (e.g., AWS key, Stripe API token) is detected, GitHub automatically sends an alert to the respective service provider.

The provider can then take action, such as notifying their customer (the secret owner), invalidating the credential, or triggering their own security protocols. This is the most effective way to prevent misuse.

Incorrect Options:

B. It immediately blocks the commit to protect the secret.
Secret scanning runs after a commit is pushed. It does not block pushes in real-time. For proactive blocking, organizations must implement pre-receive hooks or other pre-commit checks, not rely on the default secret scanning service.

C. It deletes the secret from the repository automatically.
GitHub does not automatically alter repository history or delete content. The exposed secret remains in the Git history. Mitigation requires manual action by the repository administrator (e.g., rotating the secret and rewriting history with git filter-repo).

D. It notifies the admin via webhook.
While this can be configured for organizations using webhooks for alerting, it is not the primary or default action for public repos. The default and defining action for public repo scanning is the partner alert. Admin notifications are a configurable secondary step.

Reference:
GitHub Docs: "About secret scanning - Secret scanning for public repositories." The documentation states: "For public repositories, scanning covers secrets in the entire repository... we send a message to the service provider who issued the secret. The service provider validates the secret and then decides whether they should revoke the secret, issue a new secret, or contact you directly."

Explanation:
This question tests understanding of two key GitHub automation platforms: GitHub Apps (autonomous integrations) and GitHub Actions (CI/CD workflow automation). They have fundamentally different scopes, event models, and execution environments. The correct answer must highlight a true, defining architectural difference.

Correct Option:

D. GitHub Actions can only be used to respond to events within a single repository while GitHub Apps can respond to events from multiple repositories
GitHub Actions: A workflow is defined in and responds to events (e.g., push, pull_request) from its own repository. It cannot natively listen to events from other repositories.

GitHub Apps: An app is installed on an organization or user account. Once installed, it can listen to events across all repositories it has access to, making it a broad-scope integration tool.

Incorrect Options:

A. GitHub Apps can only be used inside .github/workflows
This is completely false. GitHub Apps are standalone external applications that interact via the GitHub API. Workflow files (/.github/workflows/) are the domain of GitHub Actions. Apps are not defined or run within them.

B. GitHub Actions are limited to reading repository content only
This is incorrect. GitHub Actions workflows, via the GITHUB_TOKEN or custom tokens, can be granted extensive permissions (write) to modify repository content, create releases, post comments, and more, as defined in the workflow's permissions key.

C. GitHub Apps run only on GitHub-provided virtual machines, while GitHub Actions run only on customer-hosted machines
This reverses the concepts. GitHub Actions primarily run on GitHub-hosted runners (or can use self-hosted runners). GitHub Apps are external services that run on infrastructure provided by the app's developer, not on GitHub's or the customer's runners.

Reference:

GitHub Docs:
"About GitHub Actions" explains that workflows are triggered by events in the repository where they are defined.

"About GitHub Apps" explains that they can be installed on organizations and user accounts, subscribing to events for all repositories they have access to, enabling cross-repository automation.

Explanation:
The question asks about the automated mechanism Dependabot uses to propose fixes for vulnerable dependencies. This involves Dependabot's integration with two core GitHub security features: the dependency graph for inventory and Dependabot alerts for vulnerability matching. The process is data-driven and automated, not manual or based on social metrics.

Correct Option:

B. It uses the dependency graph and Dependabot alerts to open PRs for patched versions.
Dependency Graph: This is Dependabot's source of truth. It automatically analyzes a repository's manifest files (e.g., package.json, Gemfile) to build a map of all direct and indirect dependencies.

Dependabot Alerts: When a known vulnerability (CVE or GHSA) affects a dependency in the graph, GitHub generates a Dependabot alert for that repository.

Automated PRs: Dependabot then cross-references the alert with available dependency version information. If a patched, non-breaking version exists (e.g., a minor or patch update), it automatically opens a pull request to update the manifest to that secure version.

Incorrect Options:

A. It waits for manual triage of all CVEs.
This is the opposite of Dependabot's purpose. While manual review of PRs is recommended, the creation of update PRs is fully automated. Dependabot does not wait for human triage to begin its analysis or PR creation.

C. It reads the GitHub Issues and automatically suggests fixes.
Dependabot does not parse Issues for fix suggestions. It operates based on structured security advisories and version metadata from package registries. Issues may contain user discussions, but they are not a source of truth for Dependabot's automated updates.

D. It compares your codebase to the GitHub Trending list.
The Trending list is a social metric for repository popularity. Dependabot's operation is based on dependency manifests and vulnerability databases, not popularity comparisons. This has no bearing on security updates.

Reference:
GitHub Docs: "About Dependabot security updates." The documentation explicitly states: "Dependabot uses the dependency graph and Dependabot alerts to identify vulnerable dependencies... When Dependabot identifies a vulnerable dependency, Dependabot security updates raises a pull request to fix it."