GH-200 sample questions — 25 answered and explained

Event choice for pull requests from forks: pull_request, pull_request_target and workflow_run.

On pull_request runs from forks, the GITHUB_TOKEN is read-only and secrets are withheld, so a write action fails. pull_request_target runs in the base repository's context with write access and secrets, which is unsafe if it builds or runs the fork's code. The standard split is: test untrusted code on pull_request, save results as an artifact, and let a workflow_run workflow (which runs in the base repository's context) download them and post the comment without executing fork code.

1. Explain the 403: fork pull request runs get a read-only token.
2. Note the constraint: fork code must not run with write access or secrets.
3. Reject pull_request_target with a head checkout (runs fork code with write access).
4. Separate untrusted testing from the privileged comment step with workflow_run.

Exam tip: Run fork code under pull_request; do privileged follow-up in a workflow_run workflow that only handles artifacts.

Events triggered by the GITHUB_TOKEN do not create new workflow runs.

To prevent recursive runs, GitHub does not start workflows for events caused by the GITHUB_TOKEN, except workflow_dispatch and repository_dispatch. The tag push works but triggers nothing. Using a GitHub App installation token (or a PAT) for the push makes it a normal event. Extra permissions, a different event type or a needs entry do not change this.

1. Note the tag is created, so the push itself succeeds.
2. Note the difference: developer tags trigger B, GITHUB_TOKEN tags do not.
3. Recall the rule that GITHUB_TOKEN events start no new runs.
4. Push with a different credential, such as a GitHub App token.

Exam tip: Anything the GITHUB_TOKEN does (except dispatch events) starts no new workflow runs.

workflow_run triggers and checking the triggering run's conclusion.

workflow_run starts a workflow when another named workflow is requested, in progress or completed, and branches filters on the branch the triggering workflow ran on. completed includes failed and cancelled runs, so the job must check github.event.workflow_run.conclusion. needs cannot cross workflow files.

1. Pick the event that reacts to another workflow: workflow_run.
2. Pick the activity type that means 'finished': completed.
3. Add a condition so only successful runs deploy.
4. Reject cross-file needs, which is not supported.

Exam tip: workflow_run completed fires on success and failure; check github.event.workflow_run.conclusion before deploying.

Passing secrets to reusable workflows.

A called workflow only receives the secrets its caller passes. The caller can map them one by one under secrets, or use secrets: inherit to pass all its secrets implicitly when the reusable workflow is in the same organization or enterprise. Inputs are for non-secret values, and organization secret policies do not pass secrets into a call.

1. Note the call is within one organization.
2. Note the constraint: do not list secrets one by one.
3. Recall secrets: inherit passes all of the caller's secrets.
4. Reject explicit maps and inputs, which list each value.

Exam tip: Same org or enterprise and no wish to list secrets: use secrets: inherit.

workflow_call input types and required secrets.

workflow_call inputs are limited to boolean, number and string, so a choice input fails validation (the called workflow can check the value itself instead). A secret marked required must be supplied by the caller, either explicitly or with secrets: inherit. Tags, branches and SHAs are all valid refs, defaults need not be required, and runs-on belongs to the called workflow's jobs.

1. Check each workflow_call input type against boolean, number and string.
2. Check every required secret against what the caller passes.
3. Check the uses ref format: SHA, tag or branch are allowed.
4. Confirm runs-on belongs inside the called workflow.

Exam tip: workflow_call inputs: boolean, number or string only; required secrets must be passed or inherited.

Mapping outputs from a reusable workflow back to its caller.

Data leaves a reusable workflow in three hops: a step writes to GITHUB_OUTPUT, the job maps it under outputs, and on.workflow_call.outputs exposes it with a value referencing jobs.<job>.outputs. The caller then treats the whole call as one job and reads needs.<calling-job>.outputs.<workflow-output-name>. Internal job and output names are not visible to the caller.

1. Trace the chain inside build.yml: step meta -> job package output tag -> workflow output image_tag.
2. Identify the job name the caller used for the call: build.
3. Combine them in the needs context: needs.build.outputs.image_tag.
4. Reject names that exist only inside the called workflow.

Exam tip: Callers read needs.<calling-job>.outputs.<workflow_call output>, never the called workflow's internal job names.

On a run's log page, Search logs only includes expanded steps, and only failed steps are expanded automatically.

GitHub's log search covers the steps that are expanded on the page. Failed steps are expanded automatically, so the Deploy step is searched, but the passing integration-test step stays collapsed and is skipped. Expanding that step (or searching the downloaded archive) finds the text. Masking would hide the value everywhere, and neither annotations nor runner diagnostics are what the search box reads.

1. Compare the two sources: the archive has the text, the page search does not.
2. Recall which steps the page search includes: expanded ones.
3. Recall which steps are expanded by default: failed ones.
4. Expand the passing step and search again.

Exam tip: Log search only sees expanded steps; expand a passing step before searching it.

A re-run adds a new attempt to the same workflow run; previous attempts are selected from the Latest dropdown on the run page.

Re-running does not create a separate run: the run keeps its run ID and run number, and github.run_attempt increases. The run page shows the latest attempt by default, and the Latest dropdown to the right of the run name lets you open any earlier attempt and its logs. Artifacts and Insights do not hold attempt logs.

1. Recall that a re-run is an attempt of the same run.
2. Open the run page.
3. Use the Latest dropdown to switch to attempt 1.

Exam tip: Re-runs are attempts of one run; switch attempts from the Latest dropdown.

After a partial re-run, the downloaded log archive includes only the re-run jobs; each attempt's logs remain available per attempt in the UI and through the attempts logs endpoint.

GitHub documents that the log archive for a partially re-run workflow includes only the jobs that were re-run. The first attempt's logs are still kept per attempt: select attempt 1 from the Latest dropdown and download its archive, or call the download workflow run attempt logs endpoint, which returns a short-lived redirect to that attempt's archive. The run-level logs endpoint returns the current partial archive, the jobs list holds no log text, and a new re-run produces new logs.

1. Explain the short archive: a partial re-run archive holds only re-run jobs.
2. Recall that each attempt keeps its own logs.
3. Find attempt 1 in the UI or by attempt number in the REST API.
4. Reject options that return current or new logs, or only metadata.

Exam tip: For a partial re-run, fetch earlier logs by attempt: the Latest dropdown or /runs/{id}/attempts/{n}/logs.

GET /repos/{owner}/{repo}/actions/workflows/{workflow_id}/runs accepts a workflow file name and filters by branch, event, status, actor and more.

Run history for one workflow comes from the list workflow runs for a workflow endpoint, where workflow_id can be the file name such as ci.yml. Its query parameters include branch, event and status (status also accepts conclusions such as failure), so the server returns only the matching runs. The repository-wide runs endpoint lists every workflow's runs and has no workflow parameter, jobs are listed per run, and check runs for one commit are not a history.

1. Identify the scope: runs of one workflow file.
2. Use the workflows/{workflow_id}/runs endpoint, which accepts ci.yml.
3. Filter with branch=main, event=push and status=failure.
4. Reject endpoints with the wrong scope or invented paths.

Exam tip: Run history for one workflow: /actions/workflows/{file}/runs with branch, event and status filters.

A re-run uses the same GITHUB_SHA and GITHUB_REF as the original event, so fixes committed later are not picked up; a commit with a skip instruction starts no push run, but it does not block workflow_dispatch.

GitHub re-runs a workflow with the commit SHA and ref of the original event, so every re-run of run 5310, from the UI or the API, with or without debug logging, evaluates the workflow file as it was at that commit. The fix commit started no run of its own because [skip ci] skips push and pull_request workflows. A new run is needed at a commit containing the fix: a manual workflow_dispatch run on main (skip instructions do not apply to that event) or a further push whose message has no skip instruction.

1. Explain the repeat failure: a re-run is tied to the original commit.
2. Explain the missing new run: [skip ci] suppressed the push run for the fix commit.
3. Recall that skip instructions affect only push and pull_request events.
4. Pick the actions that create a new run at a commit containing the fix.

Exam tip: Re-runs replay the original commit; to test a fix, start a new run.

In a composite action, every run step must set shell.

The metadata syntax for composite actions says shell is required when run is set. Unlike a workflow, an action cannot fall back on defaults.run.shell, and a calling job's defaults do not reach into the action. Adding shell to the step fixes the metadata.

1. Identify the action type: composite.
2. Recall the composite rule for run steps.
3. Discard defaults-based fixes, which do not apply inside actions.

Exam tip: Composite action run steps always need an explicit shell.

A composite action's outputs need a value key that maps an inner step's output to the action's output.

For JavaScript and Docker actions, writing to GITHUB_OUTPUT sets the action's output directly. A composite action is different: its outputs.<id>.value is required and typically references steps.<inner-id>.outputs.<name>. Without it, the inner step's output is never surfaced. The workflow cannot reach inside the action by inner step id; it reads outputs from the step that used the action.

1. Note that the action type is composite.
2. Check the outputs block: description only, no value.
3. Recall that the caller sees only the action step's outputs.
4. Map the inner output with value.

Exam tip: Composite outputs need value: ${{ steps.<inner-id>.outputs.<name> }}.

Composite actions do not get INPUT_<NAME> environment variables; they use the inputs context.

JavaScript and Docker actions receive inputs as INPUT_<NAME> variables, but the metadata reference states that composite actions do not get them automatically and must use ${{ inputs.<id> }}. Writing the expression straight into run works but substitutes untrusted text into the script before bash runs it. Mapping it to an environment variable on the step and quoting that variable gives both the value and safe handling.

1. Recall how composite actions receive inputs.
2. Note the security constraint about untrusted text.
3. Prefer passing the expression through env over inline substitution.
4. Choose env mapping with a quoted variable.

Exam tip: Composite: inputs come from ${{ inputs.x }}; pass them through env, not straight into run.

An entrypoint script copied into an action image must have execute permission.

GitHub's Dockerfile guidance for actions says entrypoint.sh must be executable, and a permission denied error is the symptom when it is not. The mode is taken from the file in the repository, so set the executable bit in Git and commit it. USER and WORKDIR are discouraged in action Dockerfiles and do not address file permissions.

1. Read the error: the kernel refused to execute the file.
2. Recall that the image copies the file mode from the repository.
3. Set the executable bit and commit.

Exam tip: permission denied on entrypoint.sh means the script is not executable: chmod +x and commit.

Restrictive defaults set at a higher level cannot be loosened below it, but workflows can still request permissions explicitly.

For workflow permissions, GitHub states that the more permissive setting cannot be chosen as the default for organizations or repositories once the enterprise restricts it. The default is only a starting point: a workflow or job that declares permissions: contents: write gets that scope, which is also least-privilege practice.

1. Recall that a restrictive enterprise default flows down to organizations and repositories.
2. Reject options where an organization or repository loosens it.
3. Remember the permissions key in the workflow sets the token's scopes per run.
4. Grant contents: write only in the release workflow.

Exam tip: Restricted default from above stays; request write per workflow with permissions:.

A separate workflow-permissions setting decides whether GITHUB_TOKEN may create or approve pull requests.

Under Workflow permissions, "Allow GitHub Actions to create and approve pull requests" is off by default. While it is off, GITHUB_TOKEN cannot open or approve pull requests even with pull-requests: write. The other settings govern default scopes, fork runs and allowed actions.

1. Read the symptom: the push works, only creating the pull request is refused.
2. Note the job already has the right scopes.
3. Enable the setting that allows Actions to create and approve pull requests.

Exam tip: Opening PRs with GITHUB_TOKEN needs "Allow GitHub Actions to create and approve pull requests".

Private and internal repositories have their own fork pull request policies: run, send write tokens, send secrets, require approval.

Enabling fork runs alone gives a read-only GITHUB_TOKEN and no secrets. Adding "Require approval for fork pull request workflows" makes each run wait for approval. "Send write tokens to workflows from fork pull requests" and "Send secrets and variables to workflows from fork pull requests" loosen exactly what must stay closed, and the first-time and external contributor approval options belong to public repositories.

1. Note the repository is private, so the private fork policies apply.
2. Enable fork runs, which default to read-only and no secrets.
3. Leave write tokens and secrets off.
4. Turn on approval for fork pull request workflows.

Exam tip: Private forks: enable runs + require approval; leave write tokens and secrets off.

Fork pull request approval settings hold pull_request runs, but pull_request_target always runs.

GitHub documents that pull_request_target workflows on the base branch always run, regardless of approval settings, because they run in the base repository's trusted context. That is why such workflows must never check out and execute the fork's code with secrets available.

1. Note that the approval setting applies to fork pull request workflows.
2. Recall the documented exception for pull_request_target.
3. Exclude the pull_request variants, which are held, and workflow_run, which waits for the held test run.

Exam tip: Fork approval never holds pull_request_target runs.

Organization rulesets can require a workflow from a central repository to pass before merging.

The "Require workflows to pass before merging" rule is configured once at organization level, names a source repository and workflow file, and runs it on pull requests in the targeted repositories. Templates, reusable workflows and per-repository status checks all need something added to each repository.

1. Note the requirement: central workflow, enforced, no per-repository files.
2. Rule out templates and reusable workflows, which need files in each repository.
3. Rule out status checks, which need the workflow to exist in each repository.
4. Choose the ruleset workflow rule.

Exam tip: Enforce a central workflow on every PR with an organization ruleset workflow rule.

A ruleset workflow's source repository visibility and access setting decide where it can run.

Two rules combine. The workflow file must be in a repository whose visibility matches the targets: public runs anywhere, internal runs in internal and private repositories, private runs only in private ones. And an internal or private workflow must be made accessible from outside its repository. So the source repository becomes internal and its Access setting allows the organization. Event additions and filters do not change visibility rules, and copies are not what the ruleset checks.

1. Note the source: a private repository with the default Access setting, so no other repository can use its workflows yet.
2. Apply the visibility rule: a private source serves only private repositories, never internal ones.
3. Make the source internal so it can serve internal and private repositories.
4. Allow access from outside the source repository in its Access setting.

Exam tip: Ruleset workflow source: visibility must cover the targets, and access must be opened.

Least-privilege GITHUB_TOKEN: list only the scopes and access levels the job uses.

The job needs to read code and write to pull requests. contents: read plus pull-requests: write covers both, and every other scope becomes none. Contents write is unnecessary, pull-requests read cannot post a review, and issues: write is a scope the job never uses.

1. List the job's actions: read code, write a pull request review.
2. Map each action to a scope and the lowest level that works.
3. Pick the block with exactly those scopes.

Exam tip: Grant each scope the job uses at the lowest level that works; leave the rest out.

Expressions in ${{ }} are substituted into the script text before it runs; pass untrusted input through env instead.

GitHub evaluates ${{ github.event.comment.body }} and writes the result into the JavaScript source before github-script runs it, so a comment containing a quote can close the string and append code. Setting the value as an environment variable and reading process.env.BODY keeps it as data. Changing the quote style or adding toJSON inside existing quotes still splices text into code, and masking only affects logs.

1. Spot the untrusted value: the comment body.
2. Recall that ${{ }} is substituted into the script source before execution.
3. Reject fixes that still splice the value into the code.
4. Pass the value through env and read it at run time.

Exam tip: Never put untrusted ${{ }} values inside script code; hand them over through environment variables.

Pass untrusted input through an environment variable and reference it as a quoted shell variable, not through ${{ }}.

Anything inside ${{ }} is replaced in the script text before the shell starts, including ${{ env.TITLE }}, so it gives no protection. Referencing $TITLE lets the shell read the value from the environment at run time, and double quotes stop word splitting. Single quotes and toJSON both leave the title in the script source.

1. Separate template substitution (${{ }}) from shell expansion ($VAR).
2. Recall that ${{ env.X }} is still template substitution.
3. Pick the line that uses the shell variable, double-quoted.

Exam tip: Use "$VAR" in run:, never ${{ env.VAR }}, for untrusted values.

Fields a contributor writes (branch names, titles, bodies, comments, commit messages, author names and emails) are untrusted input.

Treat any context value that a contributor writes as attacker-controlled: the head branch name, pull request title and body, comment and review bodies, commit messages and author details. Numbers and IDs that GitHub generates, and the base repository's name, are not shaped by the contributor. Untrusted values should reach scripts only through environment variables.

1. Ask who writes each value: the contributor or GitHub/maintainers.
2. Mark branch names and free-text fields as untrusted.
3. Mark GitHub-generated numbers and the base repository name as not attacker-controlled.

Exam tip: Branch names and any free text from a pull request, issue or commit are untrusted.