GH-200 - Author and maintain actions (18% of the exam) - Section 3.4

Implement workflow commands inside an action to set outputs, write environment files and emit log messages.

Implement workflow commands inside a custom action to set step outputs via GITHUB_OUTPUT and write environment variables to environment files. Use the actions toolkit libraries to emit debug, warning, and error log messages.

workflow commandsset outputGITHUB_OUTPUTactions toolkit

Practice question for this objective

Free sampleAuthor and maintain actionsmedium

A maintainer is authoring a composite action and wants action.yml to declare an output called report-url whose value comes from a step that has the id generate. The step writes the value to the file referenced by the GITHUB_OUTPUT environment variable. How should the action's metadata reference that step output so consumers can read it?

outputs:
  report-url:
    description: "Link to the generated report"
    value: <expression>

Avalue: ${{ jobs.generate.outputs.report-url }}, because the output is produced inside a job step and the jobs context exposes each step result for the metadata to forward to consumers.
Bvalue: ${{ env.report-url }}, because the step exported the value to the environment file, so reading it back through the env context lets the action surface the output to its consumers.
Cvalue: ${{ needs.generate.outputs.report-url }}, because the needs context carries forward outputs from the named unit so the action metadata can publish report-url to callers.
Dvalue: ${{ steps.generate.outputs.report-url }}, because a composite action output maps to a step output through the steps context using the step id and the output name written to GITHUB_OUTPUT. Correct

Bind a composite action output to a step result using the steps context with the step id and the output name from GITHUB_OUTPUT. A composite action declares each output's value with an expression, and the supported source for a step result is the steps context, written as steps.<id>.outputs.<name>. The generate step that wrote report-url to the GITHUB_OUTPUT file is therefore read as steps.generate.outputs.report-url. The jobs and needs contexts operate at workflow and job-dependency level and are unavailable inside an action, and env only carries values written to GITHUB_ENV.

Why A is wrong: Tempting because jobs do expose outputs at workflow level, but inside an action the jobs context is not available, so referencing step values through jobs returns nothing.

Why B is wrong: Tempting since GITHUB_OUTPUT looks like an environment file, but it feeds the steps context not env, and env would only work had the step written to GITHUB_ENV instead.

Why C is wrong: Tempting because needs surfaces outputs across dependent jobs, but it applies to job dependencies in a workflow, not to steps within a single composite action, so it resolves to nothing here.

Why D is correct: Composite action outputs bind to a step output via the steps context, so steps.generate.outputs.report-url correctly references the value the generate step wrote to GITHUB_OUTPUT.

See more GH-200 practice questions, answers explained.

Exam traps in Author and maintain actions

Answers that look right on this material and are not. Each one is a distractor from a different question in the GH-200 bank for this domain.

Call core.exportVariable('sha', sha), because exporting the variable through the toolkit registers it as an action output that the workflow reads through the steps context.
Why it is wrong: Tempting because it also persists a value, but core.exportVariable writes to the GITHUB_ENV file and sets an environment variable rather than an output.
Emit ::debug:: before the verbose lines and ::endgroup:: after them, because the debug command opens a collapsible region that the endgroup command closes in the run log.
Why it is wrong: Tempting because both are real workflow commands, but ::debug:: only prints a single debug message shown when debug logging is on and does not open a collapsible region, so the lines stay expanded.
Replace core.info with core.warning on the validation problem, because a warning annotation is treated as a non-passing result that stops the step from being marked successful.
Why it is wrong: Tempting because core.warning adds a visible annotation, but a warning does not change the exit code, so the step still completes successfully and later jobs continue on bad data.

Examworthy is not affiliated with or endorsed by GitHub. Original, blueprint-aligned practice material only.