GH-200 · Domain 4: Manage GitHub Actions for the enterprise · 24% of the exam
Task 4.1: Distribute and govern actions and workflows
Sharing actions and reusable workflows inside an organization or enterprise, allowed actions policies, workflow permissions defaults, fork pull request policies and required workflows in rulesets.
Study it
Sharing and governing actions and workflows across an enterprise
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the GitHub documentation page that proves it.
Question 1 · choose 2
An organization's workflows may use only actions from the organization itself, actions created by GitHub, and a vendor's scanner action at one approved commit. Every other action must be blocked. Its repositories don't use workflow dependency lockfiles. Which two settings under Policies achieve this? (Choose TWO.)
AAllow the organization's own actions and select non-organization ones, with Allow actions created by GitHub checked
BAdd the vendor action with its full commit SHA, such as vendor/scan@a824008..., to the allowed list
CAllow all actions and reusable workflows, with the vendor action listed first
DAllow only the organization's own actions and reusable workflows
ERequire actions, including those created by GitHub, to be pinned to a full-length commit SHA, with no other change
Show the answer and why
AAllow the organization's own actions and select non-organization ones, with Allow actions created by GitHub checked
Correct
That policy allows local actions and lets you add GitHub-created actions and specific others.
BAdd the vendor action with its full commit SHA, such as vendor/scan@a824008..., to the allowed list
Correct
An entry with a SHA allows that action only at that commit.
CAllow all actions and reusable workflows, with the vendor action listed first
Incorrect
Allowing all actions doesn't block the other third-party actions.
DAllow only the organization's own actions and reusable workflows
Incorrect
That leaves out actions the stem must allow, such as the vendor's scanner.
ERequire actions, including those created by GitHub, to be pinned to a full-length commit SHA, with no other change
Incorrect
Pinning decides how actions are referenced, not which actions are allowed.
Choosing Allow OWNER, and select non-OWNER, actions and reusable workflows allows the organization's actions and offers further options: allow actions created by GitHub, allow Marketplace actions by verified creators, and allow or block specified actions with OWNER/REPOSITORY@TAG-OR-SHA entries. A SHA entry restricts the action to that commit.
An enterprise has 20 organizations whose repositories are internal or private. A shared deploy action lives in a private repository in the platform organization, and internal repositories in other organizations can't use it. No repository may become public. What should the platform team do?
AMove the action to an internal repository and allow access from repositories in the enterprise
BKeep it private and allow access from repositories in the platform organization, not the enterprise
CPublish it to GitHub Marketplace and allow verified creators
DCopy the action into an internal .github repository in each organization
Show the answer and why
AMove the action to an internal repository and allow access from repositories in the enterprise
Correct
Actions in an internal repository can be shared with internal and private repositories across the enterprise.
BKeep it private and allow access from repositories in the platform organization, not the enterprise
Incorrect
Actions in private repositories can't be used by internal repositories, and this setting reaches only one organization.
CPublish it to GitHub Marketplace and allow verified creators
Incorrect
Verified creator status is granted by GitHub to partner organizations, so that option wouldn't cover the team's own action.
DCopy the action into an internal .github repository in each organization
Incorrect
Twenty copies must be kept in sync, and .github holds templates and community files, not shared actions.
Within an enterprise, actions and reusable workflows in an internal or private repository can be shared by allowing access to the repository. Actions in internal repositories can't be used in public repositories, and actions in private repositories can't be used in public or internal repositories, so an action for internal repositories across organizations belongs in an internal repository.
Contractors open pull requests from forks of an organization's private repositories. CI must run on those pull requests after a maintainer approves, but must never get secrets or a write token. Which fork pull request settings fit?
ARun workflows from fork pull requests, with Require approval for fork pull request workflows
BRun workflows from fork pull requests together with Send secrets to workflows from pull requests
CSend write tokens to workflows from pull requests, with approval required
DRequire approval for all external contributors in the public fork pull request settings
Show the answer and why
ARun workflows from fork pull requests, with Require approval for fork pull request workflows
Correct
Fork runs then use a read-only token and no secrets, and wait for a writer's approval.
BRun workflows from fork pull requests together with Send secrets to workflows from pull requests
Incorrect
Sending secrets breaks the rule that fork runs never get secrets.
CSend write tokens to workflows from pull requests, with approval required
Incorrect
Write tokens are exactly what the fork runs must not get.
DRequire approval for all external contributors in the public fork pull request settings
Incorrect
That setting governs public repositories; private forks have their own policies.
For private repositories, Run workflows from fork pull requests allows fork pull request runs with a read-only GITHUB_TOKEN and no access to secrets. Send write tokens and Send secrets widen that access, and Require approval for fork pull request workflows makes runs from collaborators without write permission wait for approval.
An organization owner wants to allow all actions, but the option is unavailable in the organization's Actions settings. The organization belongs to an enterprise. What is the likely reason?
AThe organization is on GitHub Team instead of GitHub Enterprise Cloud
BOwners must ask GitHub Support to allow all actions
CA repository in the organization has Actions disabled
DAn enterprise policy restricts actions for its organizations
Show the answer and why
AThe organization is on GitHub Team instead of GitHub Enterprise Cloud
Incorrect
Allowed actions policies exist on every plan.
BOwners must ask GitHub Support to allow all actions
Incorrect
The setting is self-service when no higher policy applies.
CA repository in the organization has Actions disabled
Incorrect
One repository's setting doesn't lock the organization's policy.
DAn enterprise policy restricts actions for its organizations
Correct
An overriding enterprise policy can stop organizations from changing these settings.
Enterprise owners can enforce policies for GitHub Actions in all of the enterprise's organizations. When an overriding enterprise policy applies, organization owners might not be able to manage those settings.
An organization's allowed list is approaching its limit because it names each repository of a partner organization, whose names all start with partner-. What does GitHub document for this?
AKeep adding entries; the list has no limit
BReplace the entries with a wildcard such as partner-org/partner-*
CMove the entries to the Allow Marketplace actions by verified creators option
DCreate a second organization with its own list
Show the answer and why
AKeep adding entries; the list has no limit
Incorrect
The list can't hold more than 1,000 entries.
BReplace the entries with a wildcard such as partner-org/partner-*
Correct
Specified actions can't exceed 1,000, and * patterns match many repositories in one entry.
CMove the entries to the Allow Marketplace actions by verified creators option
Incorrect
That option allows all verified creators; it doesn't take a list.
DCreate a second organization with its own list
Incorrect
That splits governance without solving the limit.
Specified actions and reusable workflows can't be set to more than 1,000 entries. The * wildcard matches patterns, for example space-org*/* or */octocat**@*, and commas separate entries.
A new organization has never changed its Actions settings. What is the default?
AActions is disabled until an owner enables it
BOnly actions from the organization can run
CActions is enabled on all repositories
DOnly GitHub-created actions can run
Show the answer and why
AActions is disabled until an owner enables it
Incorrect
Actions is enabled by default.
BOnly actions from the organization can run
Incorrect
By default workflows can also run actions from public repositories.
CActions is enabled on all repositories
Correct
By default GitHub Actions is enabled on all repositories and organizations.
DOnly GitHub-created actions can run
Incorrect
That is an optional restriction.
By default, GitHub Actions is enabled on all repositories and organizations, and workflows can run actions and reusable workflows from the repository and any public repository. Owners can disable Actions or limit what runs.
An organization turns on Allow actions created by GitHub. Which actions does this cover?
AEvery action in GitHub Marketplace
BActions with the verified creator badge
CActions stored in the organization's own repositories
DActions in the actions and github organizations
Show the answer and why
AEvery action in GitHub Marketplace
Incorrect
Marketplace actions come from many creators.
BActions with the verified creator badge
Incorrect
Those are covered by a separate option.
CActions stored in the organization's own repositories
Incorrect
Those are already allowed by the policy.
DActions in the actions and github organizations
Correct
Actions created by GitHub are located in those two organizations.
Allow actions created by GitHub permits the actions located in the actions and github organizations. Verified creators' Marketplace actions and specific other actions have their own options.
A public repository in an organization keeps the default fork approval setting. Whose pull requests from forks wait for approval before their workflows run?
AEvery contributor, including organization members
BNobody, until an owner turns approvals on
CFirst-time contributors to the repository
DOnly users whose accounts are less than a week old
Show the answer and why
AEvery contributor, including organization members
Incorrect
The default doesn't hold back every fork pull request.
BNobody, until an owner turns approvals on
Incorrect
Approval for first-time contributors is on by default.
CFirst-time contributors to the repository
Correct
By default, all first-time contributors require approval.
DOnly users whose accounts are less than a week old
Incorrect
The default looks at contributions to the repository, not account age.
Workflows on pull requests to public repositories from some outside contributors don't run automatically. By default, all first-time contributors require approval, and owners can choose a stricter or looser policy.
An organization ruleset that requires a ci.yml workflow ran in Evaluate mode for a week. On an open pull request, the ruleset workflow ran and passed during that week. The owners now set the ruleset to Active. What does that pull request need, as far as this rule is concerned, before it can merge?
AA new run of ci.yml started after the ruleset became Active
BNothing more, because the passing run from Evaluate mode counts
CA new commit on the pull request so that the ruleset checks it again
DAn organization owner's bypass for the week of Evaluate mode
Show the answer and why
AA new run of ci.yml started after the ruleset became Active
Incorrect
GitHub documents that no new workflow run is needed after the switch.
BNothing more, because the passing run from Evaluate mode counts
Correct
A ruleset workflow that passed in Evaluate mode lets the pull request merge once the ruleset is Active, without a new run.
CA new commit on the pull request so that the ruleset checks it again
Incorrect
The earlier passing run already satisfies the rule.
DAn organization owner's bypass for the week of Evaluate mode
Incorrect
Bypass lets chosen actors skip a rule; nothing here needs skipping.
Rulesets that require workflows can start in Evaluate mode. If a ruleset workflow runs in Evaluate mode and passes, you can set the ruleset to Active and merge the pull request without triggering a new workflow run.