GitHub Actions · 25% of the exam

Author and Maintain Actions: free practice questions

5 sample questions from our 27-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real GitHub exam.

1. You are writing a composite action and need one of its steps to produce an output value that callers of the composite action can then consume. Which action.yml configuration correctly wires an inner step's output to the composite action's own output?

  • A. Define the output in the outer outputs section with a value expression like `${{ steps.step-id.outputs.result }}`, and ensure the inner step sets the output using `echo "result=value" >> $GITHUB_OUTPUT`.✓ Correct
  • B. Composite actions cannot expose outputs; only JavaScript and Docker actions support the outputs section.
  • C. Use `core.setOutput('result', value)` directly inside the composite action's action.yml to propagate the inner step output.
  • D. Define the output in outputs and set its value to `${{ env.RESULT }}`, then have the inner step write to $GITHUB_ENV instead of $GITHUB_OUTPUT.
Explanation

In a composite action, outputs must be declared in the top-level outputs section, and each output's value field should reference a specific step's output using the expression `${{ steps.<id>.outputs.<name> }}`. The inner step sets the output by writing to $GITHUB_OUTPUT. Composite actions fully support outputs — the claim they cannot is incorrect. core.setOutput() is a Node.js toolkit function and cannot be called from a composite action's YAML. While writing to $GITHUB_ENV and reading it via `${{ env.RESULT }}` is a workaround, it is not the correct/intended pattern for wiring outputs and can break in certain runner contexts.

2. Your composite action needs to accept an input called 'environment' and pass it to an inner action step. Which action.yml snippet correctly declares this input and references it inside the composite steps?

  • A. inputs:\n environment:\n description: 'Target env'\n required: true\nruns:\n using: composite\n steps:\n - run: echo ${{ inputs.environment }}\n shell: bash✓ Correct
  • B. inputs:\n environment:\n description: 'Target env'\n required: true\nruns:\n using: composite\n steps:\n - run: echo ${{ env.environment }}\n shell: bash
  • C. inputs:\n environment:\n description: 'Target env'\n required: true\nruns:\n using: node20\n steps:\n - run: echo ${{ inputs.environment }}\n shell: bash
  • D. env:\n environment:\n description: 'Target env'\nruns:\n using: composite\n steps:\n - run: echo ${{ env.environment }}\n shell: bash
Explanation

Composite actions declare inputs under the 'inputs' key and reference them with the ${{ inputs.<name> }} expression context. The 'shell' key is required for every 'run' step inside a composite action. Using ${{ env.environment }} would only work if the input were explicitly exported as an environment variable first. 'using: node20' with 'steps' is invalid — node20 actions use 'main'/'pre'/'post' keys, not 'steps'. Declaring inputs under 'env' is not valid action.yml syntax.

3. You are authoring a JavaScript action and want to signal to the workflow that the action has failed with a custom error message, causing the step to be marked as failed. Which code snippet correctly accomplishes this?

  • A. core.setFailed('Something went wrong during deployment');✓ Correct
  • B. core.error('Something went wrong during deployment');
  • C. process.exit(1);
  • D. core.warning('Something went wrong during deployment');
Explanation

core.setFailed() from @actions/core both logs the message as an error AND sets the action's exit code to 1, causing the step to be marked as failed. core.error() logs an error annotation but does NOT set the exit code, so the step can still pass. process.exit(1) does exit with a non-zero code but bypasses the Actions toolkit's cleanup and logging hooks, making it an unreliable pattern. core.warning() only emits a warning annotation and does not cause failure.

4. Which TWO of the following are valid 'using' values in the 'runs' section of an action.yml for defining how the action executes? (Select TWO)

  • A. node20✓ Correct
  • B. composite✓ Correct
  • C. python3
  • D. bash
  • E. runner
Explanation

The valid 'using' values for the 'runs' key are JavaScript runtime versions (e.g., node20, node16), 'docker', and 'composite'. 'node20' specifies that the action runs as a JavaScript action on the Node.js 20 runtime. 'composite' specifies a composite action made up of multiple steps. 'python3' is not a supported runtime for GitHub Actions' 'using' field — Python scripts must be invoked via a Docker or composite action. 'bash' is not a valid 'using' value; shell commands are used inside composite action steps, not as a top-level runtime. 'runner' is not a valid value.

5. You are creating a JavaScript action. In your action.yml you declare an input: ```yaml inputs: dry-run: description: 'Perform a dry run' required: false default: 'false' ``` Inside index.js, a teammate writes `const dryRun = core.getInput('dry_run');` but the value always comes back empty. What is the most likely cause?

  • A. core.getInput() requires the input name exactly as declared in action.yml, using the original hyphenated form: core.getInput('dry-run').✓ Correct
  • B. Boolean inputs must be read with core.getBooleanInput(), not core.getInput(), otherwise they return empty.
  • C. The input has a default of 'false', which is a falsy string and is treated as an empty value by the toolkit.
  • D. The input name contains a hyphen, which is not a valid character in action input names; the input declaration itself is invalid.
Explanation

core.getInput() matches the input name exactly as it appears in action.yml. The declared name is 'dry-run' (with a hyphen), so core.getInput('dry-run') is correct. Using an underscore ('dry_run') does not match and returns an empty string. core.getBooleanInput() is a convenience method that parses the string to a boolean, but core.getInput() still returns the string value correctly — it would return 'false', not empty. A default value of 'false' is a valid non-empty string and would be returned properly. Hyphens are perfectly valid characters in action input names.

22 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free
Author and Maintain Actions — Free GitHub Actions Practice Questions | DataCertPrep — Certification Prep