I85PREP
⌘ K
GitHub Administration study materials
GitHub Administration study resources

GitHub Administration practice questions

One question at a time. Build your GitHub Administration understanding.

First 50 of 190 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1GitHub enterprise administration, identity and repository controls

Which GitHub deployment option keeps repositories on customer-owned infrastructure that the customer patches and upgrades?

  1. GitHub Enterprise Cloud
  2. GitHub Enterprise Server Correct answer.
  3. GitHub Team
  4. GitHub Free for Organizations

Explanation

GitHub Enterprise Server (GHES) is a self-hosted appliance that runs on the customer's own VMware, Hyper-V, AWS, Azure, or Google Cloud infrastructure. The customer owns patching, backups, and upgrades. GitHub Enterprise Cloud (GHEC) is a SaaS offering hosted by GitHub. Team and Free are SaaS plans on GitHub.com.

Question 2GitHub enterprise administration, identity and repository controls

Which GitHub Enterprise Cloud feature provisions and centrally controls every user account through your identity provider, with users existing only within your enterprise?

  1. SAML SSO with linked GitHub.com accounts
  2. Enterprise Managed Users (EMU) Correct answer.
  3. OAuth App authorization
  4. Organization-level 2FA enforcement

Explanation

Enterprise Managed Users (EMU) provisions all user accounts through SCIM from your IdP, and those users live only inside your enterprise on a separate ghe.com host. They cannot contribute to public repositories or merge identities with personal github.com accounts. Standard SAML SSO links existing personal github.com accounts to your enterprise instead of creating dedicated managed identities.

Question 3GitHub enterprise administration, identity and repository controls

Which role can manage and pay for an organization's subscription without being granted access to repositories or code?

  1. Organization owner
  2. Billing manager Correct answer.
  3. Outside collaborator
  4. Security manager

Explanation

The Billing manager role exists specifically so finance staff can manage the organization's billing plan, payment method, and invoices without seeing private code or having any repository access. Organization owners have full administrative access including code. Outside collaborators only have access to specific repositories they are added to. Security managers can read all repositories and manage security alerts but do not own billing.

Question 4GitHub enterprise administration, identity and repository controls

Which GitHub Enterprise Cloud option allows a customer to keep repository content, issues, pull requests, and most metadata stored in the European Union?

  1. GHEC EU data residency on ghe.com Correct answer.
  2. EMU on github.com
  3. GitHub Enterprise Server with EU IP allow lists
  4. Setting the user's profile timezone to Europe

Explanation

GitHub Enterprise Cloud with EU data residency provisions an enterprise on the ghe.com host and stores repository content and most metadata in EU data centers. EMU on github.com is an identity model, not a data residency option. GHES with IP allow lists is self-hosted, not GHEC. A user's profile timezone has no effect on data location.

Question 5GitHub enterprise administration, identity and repository controls

Which feature lets an enterprise on GitHub Enterprise Cloud delegate user provisioning so that users are completely managed in Microsoft Entra ID with no personal github.com account linkage?

  1. Standard SAML SSO
  2. Enterprise Managed Users (EMU) with Entra ID Correct answer.
  3. OAuth App with Entra ID
  4. GitHub Connect

Explanation

Enterprise Managed Users with Entra ID provisions and authenticates managed user identities entirely from the IdP and disallows personal github.com account linkage. Standard SAML SSO links existing github.com accounts. OAuth Apps are an authorization mechanism. GitHub Connect bridges GHES and GHEC.

Question 6GitHub enterprise administration, identity and repository controls

An administrator wants to issue a token that can be scoped to a single repository, expires automatically, and requires organization owner approval. Which credential type should they use?

  1. Classic personal access token
  2. Fine-grained personal access token Correct answer.
  3. Deploy key
  4. OAuth App user-to-server token

Explanation

Fine-grained personal access tokens can restrict the resource owner, selected repositories and permissions within the user’s existing authority. The requested expiration and owner-approval behavior must be configured under the actual policy. Current GitHub permits non-expiring choices unless constrained by applicable policy; approval is not universally mandatory for every token.

Question 7GitHub enterprise administration, identity and repository controls

Which standard does GitHub Enterprise use to automatically provision and deprovision user accounts from an external identity provider?

  1. SAML 2.0
  2. OAuth 2.0
  3. SCIM 2.0 Correct answer.
  4. OpenID Connect

Explanation

SCIM (System for Cross-domain Identity Management) 2.0 is the protocol GitHub uses to receive create, update, and delete events from identity providers such as Entra ID, Okta, OneLogin, and PingFederate, so user lifecycle changes in the IdP are reflected in the GitHub enterprise. SAML handles authentication, OAuth handles delegated authorization, and OIDC is an authentication layer built on OAuth.

Question 8GitHub enterprise administration, identity and repository controls

An administrator wants new organization members to be added automatically to a team based on their group membership in the IdP. Which feature should they enable?

  1. Team sync Correct answer.
  2. Outside collaborator invitations
  3. Organization base permissions
  4. GitHub Connect

Explanation

Team sync connects an organization team to an IdP group (Entra ID or Okta on github.com, with broader IdP support on GHEC EMU and GHES) so that membership in the IdP group automatically maintains membership in the GitHub team. Outside collaborator invitations are manual repository invitations. Base permissions set the default org-wide repository permission for all members. GitHub Connect bridges GHES and GHEC.

Question 9GitHub enterprise administration, identity and repository controls

Which GitHub feature lets an organization restrict access so that a repository can be cloned and authentication can occur only from a defined set of source IP ranges?

  1. Branch protection rules
  2. IP allow lists Correct answer.
  3. OAuth App restrictions
  4. Repository visibility settings

Explanation

IP allow lists are an enterprise/organization-level setting (available on GitHub Enterprise Cloud) that restrict access to the organization's resources to a defined set of IPv4 and IPv6 CIDR ranges. Branch protection guards merges, OAuth App restrictions control which OAuth Apps may access org resources, and visibility settings control who can see a repository.

Question 10GitHub enterprise administration, identity and repository controls

Which credential type does GitHub recommend for granting an automated system fine-grained, repository-scoped access that does not consume a user license?

  1. Classic personal access token from a service account
  2. Deploy key with read/write
  3. GitHub App installation access token Correct answer.
  4. OAuth App user token

Explanation

A GitHub App is the recommended pattern for automation: the App is installed on selected repositories with fine-grained permissions and produces short-lived installation access tokens. It does not consume a user seat and avoids the need for service-account user identities. Classic PATs from service accounts consume a license and have broad scopes. Deploy keys are limited to a single repository's Git access. OAuth App user tokens act on behalf of a user.

Question 11GitHub enterprise administration, identity and repository controls

Which feature lets an administrator require a specific personal access token policy across an entire enterprise on GitHub Enterprise Cloud?

  1. Enterprise-level personal access token policies Correct answer.
  2. Repository templates
  3. GitHub Apps
  4. OAuth App restrictions

Explanation

On GitHub Enterprise Cloud, enterprise owners can configure personal access token policies at the enterprise level, including whether fine-grained PATs are allowed, maximum lifetime, allowed organizations, and whether organization owners must approve tokens. Repository templates seed repositories. GitHub Apps are an authentication mechanism. OAuth App restrictions only constrain OAuth Apps, not PATs.

Question 12GitHub enterprise administration, identity and repository controls

Among these listed methods, which can authenticate the stated authorized service account’s Git-over-HTTPS access without using its account password?

  1. The user's password
  2. A personal access token used as the password Correct answer.
  3. An SSH key
  4. A SAML assertion

Explanation

Once 2FA is enforced, GitHub no longer accepts the account password for Git operations over HTTPS. The service account must instead use a personal access token (or fine-grained PAT) as the password. SSH is a separate transport. SAML assertions are presented in a browser flow, not on the Git command line.

Question 13GitHub enterprise administration, identity and repository controls

Which of the following best describes a GitHub App's installation access token?

  1. A long-lived token issued to a user that can be reused indefinitely
  2. A short-lived token (about one hour) generated from the App's private key for a specific installation Correct answer.
  3. A device-flow code displayed to the user
  4. A SAML assertion forwarded by the IdP

Explanation

A GitHub App generates a JWT signed with its private key, exchanges it for an installation access token scoped to a specific installation, and uses that token for API calls. The installation access token is short-lived (approximately one hour) and is not bound to a user. It is not a SAML assertion or a device-flow code.

Question 14GitHub enterprise administration, identity and repository controls

Which administrative role in an organization can manage security alerts (Dependabot, code scanning, secret scanning) across all repositories without being an organization owner?

  1. Triage
  2. Security manager Correct answer.
  3. Outside collaborator
  4. Billing manager

Explanation

The Security manager role is granted to a team and gives that team read access to all the organization's repositories plus the ability to manage security alerts and security settings without making them organization owners. Triage is a repository role. Outside collaborators are non-members. Billing managers handle billing only.

Question 15GitHub enterprise administration, identity and repository controls

Which feature lets an administrator define a child team that automatically inherits its parent team's repository access?

  1. Nested teams Correct answer.
  2. Outside collaborator groups
  3. Team mentions
  4. Discussions categories

Explanation

Nested teams can inherit repository access from the parent team under the supported team structure. Notification behavior is a separate setting and should not be assumed to inherit identically. Check actual eligible team type, memberships and effective permissions before asserting access or administrative authority.

Question 16GitHub enterprise administration, identity and repository controls

Which scope of a fine-grained personal access token controls reading and writing of repository contents?

  1. Repository permission: 'Contents' Correct answer.
  2. Repository permission: 'Metadata'
  3. Account permission: 'Email addresses'
  4. Repository permission: 'Actions'

Explanation

Fine-grained PATs use granular permissions. The 'Contents' repository permission controls Git contents read/write. 'Metadata' is required for any repository access (read-only). 'Email addresses' is an account permission unrelated to repository content. 'Actions' controls workflow runs and artifacts.

Question 17GitHub enterprise administration, identity and repository controls

Which of these is a key reason to prefer GitHub Apps over OAuth Apps for organization integrations?

  1. GitHub Apps require less configuration in the IdP
  2. GitHub Apps have fine-grained, installation-scoped permissions and act with their own identity Correct answer.
  3. OAuth Apps cannot use HTTPS
  4. OAuth Apps are deprecated and will be removed in 2027

Explanation

GitHub Apps install on selected repositories with fine-grained permissions, generate short-lived installation tokens, and act with their own identity (not on behalf of a user). OAuth Apps act on behalf of a user with that user's scopes, which is broader and less auditable. The other statements are incorrect: OAuth Apps use HTTPS and have not been announced for removal in 2027.

Question 18GitHub enterprise administration, identity and repository controls

An organization on GitHub Enterprise Cloud uses SAML SSO. A user with an active linked identity is failing to push over HTTPS using a classic PAT. What is the most likely cause?

  1. The PAT is missing the 'workflow' scope
  2. The PAT has not been authorized for SSO with the organization Correct answer.
  3. The repository is archived
  4. The organization disabled HTTPS

Explanation

When SAML SSO is enforced, personal access tokens must be explicitly authorized for use with each organization that requires SSO. Until the token is SSO-authorized, API and Git operations against that organization are rejected. 'workflow' scope is for GitHub Actions, archived repos still allow read but the question is about push fail mode, and HTTPS is not user-disable-able.

Question 19GitHub enterprise administration, identity and repository controls

Which capability is unique to GitHub Apps (versus OAuth Apps) when calling the GitHub API?

  1. Acting on behalf of a user
  2. Acting with their own bot identity using short-lived installation tokens Correct answer.
  3. Listing repositories
  4. Reading public events

Explanation

GitHub Apps act with their own bot identity (e.g., 'app/bot[bot]') using short-lived installation access tokens scoped to the installation's repositories and permissions. OAuth Apps act on behalf of a user with that user's scopes. Both can list repositories or read public events.

Question 20GitHub enterprise administration, identity and repository controls

Which administrative role can install GitHub Apps on an organization?

  1. Outside collaborator
  2. Organization owner (and members the owner has delegated) Correct answer.
  3. Billing manager
  4. Triage role on a single repository

Explanation

Installing a GitHub App on an organization requires organization owner privileges (or an explicitly delegated installation flow). Outside collaborators have no organization-level rights, billing managers handle billing only, and Triage is a repository role.

Question 21GitHub enterprise administration, identity and repository controls

A repository already enforces required code-owner review on its protected branch. Which listed mapping identifies the eligible platform team for files under/infra?

  1. A push ruleset blocking changes to /infra
  2. A CODEOWNERS entry mapping /infra to the platform team Correct answer.
  3. A required status check for an infra workflow
  4. An organization-level branch protection rule

Explanation

With the required review rule explicitly supplied, a valid CODEOWNERS entry maps the infrastructure path to an eligible team. CODEOWNERS alone requests the relevant review; actual enforcement also depends on branch/ruleset configuration, base-branch content, team permissions and bypass conditions. No repository policy is changed here.

Question 22GitHub enterprise administration, identity and repository controls

A team wants to enforce branch protection consistently across many repositories without configuring each repository individually. Which feature should they use?

  1. Repository templates
  2. Repository rulesets at the organization level Correct answer.
  3. Custom repository roles
  4. GitHub Actions required workflows

Explanation

Repository rulesets defined at the organization (or enterprise) level can target multiple repositories and branches via name patterns and apply a single, centrally managed set of rules such as required pull requests, required status checks, signed commits, and restricted pushes. Templates only seed new repositories. Custom roles control permissions, not branch policy. Required workflows enforce CI workflows but not branch rules.

Question 23GitHub enterprise administration, identity and repository controls

Which built-in repository role is the lowest level that can manage issues and pull requests (assign, close, label) without being able to push code or change settings?

  1. Read
  2. Triage Correct answer.
  3. Write
  4. Maintain

Explanation

The Triage role grants permissions to manage issues and pull requests (label, assign, close, mark as duplicate) without granting push access or repository administration. Read is read-only and cannot manage issues. Write grants push and merge plus issue management. Maintain grants additional configuration without controlling sensitive admin areas.

Question 24GitHub enterprise administration, identity and repository controls

Which repository visibility option is available only to organizations on GitHub Enterprise Cloud or Enterprise Server and makes a repository visible to all enterprise members?

  1. Public
  2. Private
  3. Internal Correct answer.
  4. Limited

Explanation

Internal repositories are an enterprise-only visibility level: every member of the enterprise can read and (depending on permissions) contribute to internal repositories, enabling 'inner source' across an organization. Public is open to everyone, private is restricted to explicitly granted users or teams, and Limited is not a real visibility level.

Question 25GitHub enterprise administration, identity and repository controls

Which protection rule, when enabled in a repository ruleset, ensures that all commits merged into the default branch are cryptographically signed by a verified key?

  1. Require linear history
  2. Require signed commits Correct answer.
  3. Require status checks to pass
  4. Restrict pushes that create matching refs

Explanation

The 'Require signed commits' rule (available in branch protection rules and repository rulesets) blocks merges or pushes that include unsigned or unverified commits. Linear history blocks merge commits, status checks gate merges on workflows, and the push restriction prevents creating new matching branches/tags but does not check signatures.

Question 26GitHub enterprise administration, identity and repository controls

Which feature serializes pull request merges into the default branch so that each is rebased and re-tested against the latest base before merging?

  1. Auto-merge
  2. Merge queue Correct answer.
  3. Squash merge
  4. Required status checks

Explanation

A merge queue can test queued changes against the relevant base and earlier queued changes before the configured merge method is applied. It does not universally mean every change is rebased, and its operation depends on supported rules and required checks. Test status is not a complete correctness or security guarantee.

Question 27GitHub enterprise administration, identity and repository controls

What does setting an organization's base permission to 'Read' do?

  1. Grants every member read access to all of the organization's repositories Correct answer.
  2. Grants every member read access to public repositories only
  3. Removes write permissions from existing teams
  4. Forces every repository to be public

Explanation

Base permissions are the default permission an organization member receives on every repository in the organization (other than ones they are explicitly demoted from). Setting it to Read gives every org member at least read access to all org repositories. Existing higher team or direct grants stay, and visibility is not changed.

Question 28GitHub enterprise administration, identity and repository controls

Which combination of features lets an administrator restrict who can publish releases on a repository and require external review before each release deploys?

  1. A repository ruleset with restricted tag creation, plus an environment with required reviewers used by the release workflow Correct answer.
  2. Branch protection on main and CODEOWNERS
  3. Repository visibility set to internal
  4. Disabling the Releases tab

Explanation

A tag ruleset can restrict who can create release tags, and a deployment environment with required reviewers (used by the workflow that publishes the release) gates the release on human approval. Branch protection on main does not control who can publish a release. Visibility doesn't gate releases. Disabling the Releases tab is not a granular control.

Question 29GitHub enterprise administration, identity and repository controls

Which mechanism best protects an organization from a ruleset bypass when a repository admin disables a branch protection rule?

  1. Repository-level branch protection rules only
  2. An organization-level repository ruleset with no bypass list Correct answer.
  3. Disabling the Issues feature
  4. A commit signing requirement on a feature branch

Explanation

Repository rulesets defined at the organization (or enterprise) level apply across many repositories and can be configured with no bypass list, preventing repository admins from disabling them. Repo-level branch protection can be modified by repo admins. Disabling Issues is unrelated. Commit signing on a feature branch does not protect main.

Question 30GitHub enterprise administration, identity and repository controls

Which action best ensures that a stale invitation to an outside collaborator does not silently grant access months later?

  1. Periodically review pending outside collaborator invitations and revoke unaccepted ones Correct answer.
  2. Disable the Issues feature
  3. Enable secret scanning
  4. Switch the repository to internal visibility

Explanation

Outside collaborator invitations remain valid until accepted or revoked. The administrative best practice is periodic review and revocation of pending invitations. Disabling Issues, enabling secret scanning, and changing visibility do not address invitation hygiene.

Question 31GitHub enterprise administration, identity and repository controls

Which repository-level setting controls whether forks may be created of a private or internal repository in an organization?

  1. Allow forking under repository settings, plus organization-level fork policy Correct answer.
  2. Branch protection rule
  3. GHCR package visibility
  4. Repository topics

Explanation

Repositories have an 'Allow forking' setting under repository settings, and the organization can set a default for whether private/internal repositories may be forked. Branch protection, GHCR visibility, and topics are unrelated.

Question 32GitHub enterprise administration, identity and repository controls

Which feature lets an enterprise allow only signed commits on protected branches across many repositories at once?

  1. Repository ruleset at organization or enterprise level requiring signed commits Correct answer.
  2. CODEOWNERS file in each repository
  3. Repository templates
  4. Outside collaborators

Explanation

An organization or enterprise repository ruleset can require signed commits and target multiple repositories and branches via name patterns. CODEOWNERS routes review on file paths, templates only seed new repositories, and outside collaborators are individual access grants.

Question 33GitHub enterprise administration, identity and repository controls

Which feature should an administrator use to ensure that the same set of branch protection rules is applied to a newly created repository at creation time?

  1. Repository ruleset targeting all repositories matching a name pattern at the organization level Correct answer.
  2. A nightly cron workflow
  3. Personal access tokens
  4. GitHub Sponsors

Explanation

An organization-level ruleset that targets repositories by name pattern (including '*') automatically applies its rules to every matching repository, including newly created ones. A nightly cron is brittle. PATs and Sponsors are unrelated.

Question 34GitHub enterprise administration, identity and repository controls

Which administrative method should be used to grant a contractor access to exactly one private repository for a fixed period?

  1. Add them as an outside collaborator with the lowest sufficient role and revoke when complete Correct answer.
  2. Add them as an organization owner
  3. Issue them a classic PAT for the organization
  4. Make the repository public

Explanation

Outside collaborators are non-organization members granted access to specific repositories. Adding the contractor as an outside collaborator with the smallest sufficient role (Read, Triage, Write) and revoking on completion is the recommended pattern. Owner is overprivileged. PATs do not grant new access. Making the repo public exposes it to everyone.

Question 35GitHub Actions policy, runner trust and workflow administration

An administrator wants self-hosted runners to be available only to a specific set of repositories within an organization. Which feature should they configure?

  1. Runner labels
  2. Runner groups Correct answer.
  3. Allowed actions policy
  4. Runner registration tokens

Explanation

Runner groups are the access boundary for self-hosted runners. At the organization or enterprise level you put runners into a group and configure which repositories or organizations may target that group. Labels are a routing mechanism within an accessible group, not an access control. Allowed actions policy controls which actions and reusable workflows can be used. Registration tokens add runners but do not grant repositories access.

Question 36GitHub Actions policy, runner trust and workflow administration

Which GitHub Actions feature allows a workflow to deploy to AWS without storing long-lived AWS access keys as secrets?

  1. GITHUB_TOKEN with workflow permissions
  2. OpenID Connect (OIDC) federated identity Correct answer.
  3. An encrypted environment secret
  4. A self-hosted runner with an instance role

Explanation

GitHub Actions can act as an OIDC identity provider. The workflow exchanges a short-lived OIDC token for temporary AWS credentials via STS using a configured IAM role trust policy. This eliminates long-lived AWS access keys stored as secrets. GITHUB_TOKEN authenticates against GitHub APIs only. An encrypted secret still stores a long-lived credential. A self-hosted runner with an instance role can work, but the canonical secret-less pattern for GitHub-hosted or generic runners is OIDC.

Question 37GitHub Actions policy, runner trust and workflow administration

Which Actions feature lets administrators require manual approval before a deployment job runs, scoped to a named target like 'production'?

  1. Repository secrets
  2. Environments with required reviewers Correct answer.
  3. Runner groups
  4. Concurrency groups

Explanation

Environments are named deployment targets that can require reviewers, wait timers, and protection rules. A job that targets the 'production' environment will pause and request approval from the configured reviewers before running, and environment secrets are only accessible after approval. Repository secrets do not pause deployments. Runner groups control runner access. Concurrency groups serialize runs but do not gate approvals.

Question 38GitHub Actions policy, runner trust and workflow administration

Which container registry is GitHub's preferred replacement for the legacy docker.pkg.github.com Docker registry?

  1. Docker Hub
  2. GitHub Container Registry (ghcr.io) Correct answer.
  3. Amazon ECR
  4. GitHub Packages npm

Explanation

GitHub Container Registry, hosted at ghcr.io, is GitHub's modern OCI-compliant container registry and is the recommended replacement for the legacy docker.pkg.github.com endpoint. Docker Hub and Amazon ECR are different vendors. GitHub Packages npm is for Node.js packages, not containers.

Question 39GitHub Actions policy, runner trust and workflow administration

Where should an organization secret be stored so that all repositories in the org may use it in workflows without each repository owner re-entering the value?

  1. Environment secret in each repository
  2. Organization-level Actions secret Correct answer.
  3. Repository secret in a shared 'secrets' repository
  4. GitHub App private key

Explanation

An organization-level Actions secret is stored once and made available to selected repositories or to all repositories in the organization. Environment and repository secrets must be configured per repository or per environment. A 'shared secrets' repository is not a real mechanism. A GitHub App private key authenticates an App, not a workflow.

Question 40GitHub Actions policy, runner trust and workflow administration

Which workflow permission setting would you choose to give the GITHUB_TOKEN read-only access by default and require workflows to explicitly opt in to write?

  1. Permissive: read and write
  2. Restricted: read-only by default Correct answer.
  3. Allow only local actions
  4. Disable Actions for the organization

Explanation

GitHub recommends configuring the default GITHUB_TOKEN permissions to read-only at the organization or repository level. Workflows that need write must explicitly request the 'permissions' block with elevated scopes. The other options either grant blanket write, control which actions may run, or disable Actions entirely.

Question 41GitHub Actions policy, runner trust and workflow administration

An organization wants to allow only actions from verified creators plus a small list of specific third-party actions. Which Actions setting should they configure?

  1. Allowed actions and reusable workflows policy Correct answer.
  2. Runner labels
  3. GITHUB_TOKEN permissions
  4. Branch protection rules

Explanation

The 'Allowed actions and reusable workflows' policy lets an admin pick from 'all actions', 'local only', 'GitHub-created and verified creators', or 'only allow select actions and reusable workflows', where you list specific third-party actions by owner or full name. Labels route jobs to runners. Token permissions control API scopes. Branch protection guards merges.

Question 42GitHub Actions policy, runner trust and workflow administration

Which of the following is a valid registry type natively supported by GitHub Packages?

  1. Helm chart registry
  2. Maven registry Correct answer.
  3. PyPI registry
  4. Cargo registry

Explanation

GitHub Packages natively supports npm, Maven, NuGet, RubyGems, and the GitHub Container Registry (Docker/OCI). It does not currently host first-party Helm, PyPI, or Cargo registries. Helm charts can be stored in OCI on GHCR but Helm itself is not a separate registry type in GitHub Packages.

Question 43GitHub Actions policy, runner trust and workflow administration

An organization wants Codespaces to be created only from a defined list of base machine sizes and to charge usage to a single shared organization account. Which combination of settings should an administrator configure?

  1. Per-user spending limits and personal Codespaces
  2. Organization Codespaces policies for machine types and an organization-paid Codespaces billing setting Correct answer.
  3. A self-hosted runner group
  4. A repository ruleset

Explanation

Organization administrators can create Codespaces policies that restrict allowed machine types, idle timeouts, and retention, and they can configure the organization to pay for member Codespaces created from organization-owned repositories. Per-user spending limits do not centralize billing. Runner groups govern Actions runners. Rulesets govern branches and tags.

Question 44GitHub Actions policy, runner trust and workflow administration

Which Actions setting controls whether GitHub-hosted larger runners may be used by the workflows in an organization?

  1. Repository visibility
  2. Larger runners settings under organization Actions runners Correct answer.
  3. Custom repository roles
  4. GHES backup schedule

Explanation

Larger runners are GitHub-hosted runners with more CPU/RAM/storage that the organization opts into and assigns to repositories or workflows under the organization's Actions runner settings. Visibility, custom roles, and GHES backup are unrelated.

Question 45GitHub Actions policy, runner trust and workflow administration

Which Actions feature can prevent two deployment workflows from running concurrently against the same environment?

  1. Job matrix strategy
  2. Concurrency group Correct answer.
  3. Cache key
  4. Composite action

Explanation

A shared concurrency group can coordinate runs/jobs under the actual repository workflow scope and cancel or queue according to configured behavior. It is not automatically a global lock across unrelated repositories or every deployment system. Environment approvals and target-state verification remain separate controls.

Question 46GitHub Actions policy, runner trust and workflow administration

Which Codespaces feature provisions container images and clones the repository in advance to reduce startup time?

  1. Prebuilds Correct answer.
  2. Devcontainer features
  3. Larger machine types
  4. Repository templates

Explanation

Codespaces prebuilds run on a schedule or on push for a given branch and produce a ready-to-attach Codespace image with the repository cloned and devcontainer setup completed, dramatically reducing first-start time. Devcontainer features add tools to a devcontainer. Larger machines change CPU/RAM but do not pre-create images. Templates seed new repositories.

Question 47GitHub Actions policy, runner trust and workflow administration

Which type of secret can be made available only to workflows running for a specific deployment environment such as 'staging' or 'production'?

  1. Repository secret
  2. Organization secret
  3. Environment secret Correct answer.
  4. Codespaces user secret

Explanation

Environment secrets are scoped to a specific deployment environment in a repository and are only exposed to jobs that target that environment. Repository and organization secrets are broader. Codespaces user secrets are scoped to a user's Codespaces and unrelated to Actions environments.

Question 48GitHub Actions policy, runner trust and workflow administration

Which permission boundary applies to a self-hosted runner registered at the enterprise level versus one registered at the repository level?

  1. They are functionally identical
  2. The enterprise runner can be shared across organizations via runner groups; the repo runner is limited to that repository Correct answer.
  3. The repo runner can run for any repository in the enterprise
  4. Enterprise runners do not require labels

Explanation

A runner registered at the enterprise level can be placed into runner groups that grant access to one or more organizations. A runner registered at a repository is restricted to that repository's workflows. Labels still apply at all levels. The two are not functionally identical, and a repo-level runner cannot run for arbitrary other repositories.

Question 49GitHub Actions policy, runner trust and workflow administration

Which feature is the recommended way to expose a workflow as reusable across many repositories in an organization?

  1. Copy the YAML into each repository
  2. Publish a reusable workflow callable via 'workflow_call' from a central repository Correct answer.
  3. Convert the workflow to a Docker action and publish to GHCR
  4. Use a fork of each repository

Explanation

Reusable workflows defined with the 'workflow_call' trigger live in a central repository and are referenced by other repositories with 'uses: org/repo/.github/workflows/file.yml@ref'. This avoids YAML duplication and centralizes maintenance. Copy/paste, Docker actions, and forking are all worse patterns for this.

Question 50GitHub Actions policy, runner trust and workflow administration

An administrator wants to allow only Codespaces from machines with at least 4 cores. Which Codespaces policy should they configure?

  1. A machine type policy listing only 4-core or larger SKUs Correct answer.
  2. An IP allow list
  3. An organization secret named MIN_CORES
  4. A required workflow for Codespaces

Explanation

Organization Codespaces policies include a machine type policy where the admin selects which sizes (cores/RAM/storage) are permitted. IP allow lists govern access, secrets are values, and required workflows are an Actions concept that does not apply to Codespaces machine sizing.