Hard — GH-200 Practice Quiz

Question 1

Your CI workflow builds and caches Node dependencies using a key derived from package-lock.json. The workflow triggers on both pull_request from forks and push to main. A security reviewer warns that a malicious contributor could poison the shared cache. What is the MOST accurate description of GitHub Actions cache scoping that mitigates this concern, and what remaining precaution is still required?

Accepted Answer

Caches created by a workflow run on a pull_request from a fork are written to a scope isolated to that PR's ref and cannot overwrite the base branch cache; you should still avoid restoring caches that could contain attacker-controlled build artifacts into privileged jobs.

Answer

All caches are globally shared across every branch and PR, so the only mitigation is to disable caching entirely for pull_request events.

Answer

Fork PR caches automatically overwrite the main branch cache under the same key, so you must add the run ID to every cache key to keep them unique.

Answer

Cache access is controlled solely by GITHUB_TOKEN permissions, so setting permissions: read-all fully prevents any cache poisoning from fork PRs.

Question 2

You maintain a Docker container action that builds from a `Dockerfile` in the repository root. It works on your local machine and on self-hosted ARM64 runners, but every run on the standard GitHub-hosted `ubuntu-latest` runner fails immediately during the container build step with an 'exec format error' when the entrypoint script is invoked. The action.yml declares `runs.using: docker` and `runs.image: Dockerfile`. What is the most likely cause and appropriate fix?

Accepted Answer

The Dockerfile base image was built only for arm64; specify a base image with linux/amd64 support since GitHub-hosted ubuntu runners are x86_64.

Answer

The action.yml is missing a `runs.args` key, which is required for Docker actions to pass the entrypoint; add it to resolve the format error.

Answer

Docker container actions are not supported on `ubuntu-latest`; convert the action to a composite action to run on hosted runners.

Answer

The `runs.image` must point to a pre-published registry image such as `docker://` rather than a local Dockerfile when running on hosted runners.

Question 3

Your enterprise has a self-hosted runner group named 'gpu-builders' created at the enterprise level, currently granted to two organizations. A third organization, 'ml-research', is onboarded and needs to run jobs on these runners. After the enterprise owner adds 'ml-research' to the runner group's organization access list, the org admin reports that no repositories in 'ml-research' can queue jobs to 'gpu-builders'. What additional step is required?

Accepted Answer

The 'ml-research' org admin must configure repository access for the runner group within the organization's settings, since org-level repo access is managed separately from enterprise-level org access.

Answer

The enterprise owner must add each repository in 'ml-research' individually to the enterprise runner group's access list.

Answer

The runners must be re-registered with a new registration token scoped to the 'ml-research' organization.

Answer

The enterprise owner must change the runner group visibility to 'All organizations' because selected-org groups cannot be shared beyond two organizations.

Question 4

As a GitHub Enterprise admin, you need to monitor how frequently a specific self-hosted runner group is being used across all organizations and identify which repositories consume the most minutes on those runners. You want a programmatic, near-real-time signal that a job has been queued for or assigned to a runner in that group, so you can feed the data into a custom dashboard. Which approach best meets this requirement?

Accepted Answer

Subscribe to the workflow_job webhook event, which fires with queued, in_progress, and completed actions and includes runner and labels information you can correlate to the runner group.

Answer

Poll the 'List self-hosted runners in a group for an organization' REST endpoint on a short interval and count runners whose status is 'online'.

Answer

Enable the workflow_run webhook event and parse the payload's runner_group_id field for each completed run.

Answer

Query the toolcache directory on each runner via SSH to determine how many jobs have executed since the last image refresh.

Question 5

Your team maintains a popular JavaScript action distributed via the GitHub Marketplace. After GitHub's immutable-actions feature is enabled for your repository and you publish a new release, a downstream consumer reports that their workflow now resolves your action from the GitHub Container Registry (ghcr.io) rather than fetching the Git ref from the repository. The consumer asks what practical change immutable actions introduce for how they should reference your action. Which statement best describes the correct implication for the consumer?

Accepted Answer

Once published as an immutable action, a given released version tag cannot be moved or overwritten, so consumers can safely pin to that semantic version tag knowing its contents will never change.

Answer

Immutable actions require consumers to reference the action by its ghcr.io image digest instead of the standard owner/repo@ref syntax in the uses field.

Answer

Immutable actions eliminate the need for version pinning entirely because GitHub now guarantees all tags, including branch names, are frozen at first use.

Answer

After immutable publishing, moving major-version tags (like v1) are no longer supported at all, forcing consumers to switch exclusively to full commit SHAs.

Question 6

A developer defines the following matrix strategy in a workflow job named `test`:

```yaml
jobs:
  test:
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
        node: [16, 18, 20]
        include:
          - os: ubuntu-latest
            node: 20
            experimental: true
    runs-on: ${{ matrix.os }}
```

In the Actions UI checks list, one variant appears as `test (ubuntu-latest, 20, true)` and shows a red X, while `test (ubuntu-latest, 20)` is not listed separately. What does this tell you about the failed variant?

Accepted Answer

The `include` entry merged its `experimental: true` value into the existing ubuntu-latest/node-20 combination, so that single job carries all three axis values and is the one that failed.

Answer

The `include` entry created an additional 7th job separate from the base 6, and both the merged job and the original ubuntu-latest/node-20 job failed.

Answer

The `experimental: true` flag caused GitHub to run the ubuntu-latest/node-20 job in a special sandbox that is expected to fail and can be ignored.

Answer

The variant name shows `true` because `fail-fast` was triggered, marking the ubuntu-latest/node-20 job as experimental after the first failure.

Question 7

A workflow calls an internal API using a token stored in the repository secret API_TOKEN. A developer wants to derive a shortened 'client key' from the token at runtime (the first 12 characters) and print it to the log for debugging, while ensuring GitHub still masks the full secret. Which approach correctly prevents the full secret from leaking in logs?

Accepted Answer

Compute the substring in a step and register it with the workflow command `echo "::add-mask::$CLIENT_KEY"` before echoing it, keeping the full secret in an environment variable set from the secret.

Answer

Reference ${{ secrets.API_TOKEN }} directly in a run step's echo command, since GitHub only masks secrets that are never printed.

Answer

Store the token in GITHUB_ENV so it becomes an environment variable, which automatically disables masking but makes debugging output safe.

Answer

Print the token using `${{ toJSON(secrets) }}` because the toJSON function encodes secrets in a masked, non-reversible format.

Question 8

Your team builds a container image in a GitHub Actions workflow and generates a build provenance attestation using the actions/attest-build-provenance action. A separate deployment workflow, running on a self-hosted runner in your production cluster, must refuse to deploy any image whose provenance cannot be confirmed as built by your organization's repository. Which approach correctly enforces this in the deployment workflow?

Accepted Answer

Run `gh attestation verify oci:// --repo /` and fail the job if the command returns a non-zero exit code before proceeding to deploy

Answer

Add the `id-token: write` permission to the deployment job so the runner can automatically validate provenance during image pull

Answer

Check that the artifact attestation file was uploaded as a workflow artifact in the build run and download it before deploying

Answer

Re-run actions/attest-build-provenance in the deployment workflow to regenerate the attestation and compare its digest to the image

Question 9

Your team maintains a public repository that receives many pull requests from forks. You need a workflow that automatically labels incoming PRs based on which files changed, and the labeling step requires write access to the repository's issues/PRs. A security review flags that using the standard 'pull_request' event does not grant sufficient token permissions for PRs originating from forks. Which trigger and configuration correctly allows the labeling job to run with write access while handling fork PRs?

Accepted Answer

Use the 'pull_request_target' event, which runs in the context of the base repository and provides a token with write permissions; scope permissions with 'permissions: pull-requests: write' and avoid checking out untrusted PR code.

Answer

Use the 'pull_request' event and add 'permissions: write-all' at the workflow level to force the fork PR token to gain write access.

Answer

Use the 'workflow_dispatch' event so a maintainer manually triggers labeling, since fork PRs can never receive a write-scoped token under any event.

Answer

Use the 'pull_request' event with 'secrets: inherit' so the fork PR inherits the base repository's write-scoped GITHUB_TOKEN.

Question 10

A public repository runs a CI workflow triggered on pull_request. The security team is concerned that contributors submitting pull requests from forks could exfiltrate repository secrets or run malicious code with elevated permissions. The team wants forked PRs to still get automated build/test feedback, but any workflow run that needs secrets or write access must not execute automatically for first-time or untrusted contributors. Which configuration best addresses this concern with the least additional custom scripting?

Accepted Answer

Enable the repository setting 'Require approval for all outside collaborators' (or 'first-time contributors') under fork pull request workflows so no forked run executes until a maintainer approves; note that pull_request runs from forks still receive NO Actions secrets and a read-only GITHUB_TOKEN, so any step that genuinely needs secrets or write access must use a separate trusted/privileged pattern rather than the fork PR run.

Answer

Switch the workflow trigger to pull_request_target so the workflow runs in the base repository context, and check out the PR head SHA before building and testing it.

Answer

Store the secrets as plaintext repository variables instead of encrypted secrets, since variables are not exposed to forked pull requests.

Answer

Grant the GITHUB_TOKEN permissions: write-all in the workflow so forked PR builds can complete, and rely on branch protection to catch malicious changes at merge time.

Question 11

A platform team maintains a reusable workflow (build.yml) invoked via workflow_call. The reusable workflow builds an artifact and computes a version string that the calling workflow needs to use in a later deployment job. Inside build.yml, a step named 'compute' writes 'ver=1.4.2' to $GITHUB_OUTPUT in job 'package'. Which combination correctly exposes this value so the caller's downstream job can reference it?

Accepted Answer

In build.yml, add a top-level 'on.workflow_call.outputs.version' mapped to "${{ jobs.package.outputs.buildver }}", set 'package' job's 'outputs.buildver: ${{ steps.compute.outputs.ver }}', then in the caller read 'needs.<callerjob>.outputs.version'.

Answer

In build.yml, set only the step output; the caller can directly read 'needs.build.outputs.ver' because step outputs automatically propagate across workflow boundaries.

Answer

Have build.yml write the value to $GITHUB_ENV; environment variables set in a reusable workflow are inherited by the caller's jobs automatically.

Answer

Upload the version as an artifact in build.yml and reference it in the caller with 'needs.<callerjob>.outputs.version' without any 'on.workflow_call.outputs' declaration.

Question 12

Your enterprise runs a fleet of self-hosted Linux runners for a large monorepo. Builds frequently call actions/setup-node and actions/setup-python, but you notice these steps download and compile the requested versions on every run, adding several minutes per job. On GitHub-hosted runners these same steps complete almost instantly. What is the most effective way to make the setup-* actions resolve versions instantly on your self-hosted runners?

Accepted Answer

Pre-populate the runner tool cache directory (RUNNER_TOOL_CACHE / hostedtoolcache) with the required Node and Python versions so the setup-* actions find and restore them without downloading

Answer

Add actions/cache steps before each setup-* action to cache the downloaded language runtimes across runs

Answer

Set the fail-fast strategy to false so slow setup steps do not block the rest of the matrix

Answer

Configure an organization allow list that only permits the pinned versions of setup-node and setup-python

Question 13

Your team maintains a 'CI' workflow that runs on every push. You want a separate 'Deploy' workflow to run automatically only after the 'CI' workflow finishes successfully on the main branch, and you must inspect whether that upstream run passed before deploying. Which trigger and condition configuration achieves this?

Accepted Answer

Use `on: workflow_run` with `workflows: ["CI"]` and `types: [completed]`, then gate the deploy job with `if: github.event.workflow_run.conclusion == 'success' && github.event.workflow_run.head_branch == 'main'`

Answer

Use `on: workflow_call` in the Deploy workflow so the CI workflow can invoke it, and check `if: success()` at the job level

Answer

Use `on: push` in the Deploy workflow with `needs: CI` to establish a dependency on the CI workflow

Answer

Use `on: workflow_run` with `types: [requested]` and gate with `if: github.event.workflow_run.status == 'completed'`