Author and maintain actions practice questions

Docker container actions are supported only on Linux runners; JavaScript and composite actions run on all three operating systems.

The failure is a platform limit, not a configuration error: a container action cannot run on Windows or macOS runners. Installing Docker does not lift that limit, and calling docker run from a composite step fails too because macOS hosted runners have no Docker engine and Windows runners use Windows containers. Skipping the step on non-Linux jobs removes coverage the team needs. Rewriting the logic as a JavaScript action is the one change that runs everywhere without extra per-run setup.

1. Note the action type from runs.using: docker.
2. Recall that container actions run only on Linux runners.
3. Check whether Docker is even usable on hosted Windows and macOS runners for a Linux image.
4. Reject the option that drops linting on two systems.
5. Choose a JavaScript rewrite.

Exam tip: Need an action on Windows or macOS? It must be JavaScript or composite, never a container action.

Self-hosted runners need Linux and Docker to run Docker container actions.

GitHub's documentation states that to run Docker container actions, self-hosted runners must use a Linux operating system and have Docker installed. Registration level and labels decide where jobs go, not what a runner can execute, and macOS is not a supported platform for container actions.

1. Recall the platform limit of container actions.
2. Recall what the runner uses to start the container.
3. Discard options about routing and registration scope.

Exam tip: Container actions on self-hosted runners: Linux plus Docker.

The runner downloads a JavaScript action's repository as is and runs the file named in main; it never installs npm dependencies.

Because the runner does not run npm install for actions, every module the action requires must be in the repository at the referenced ref. GitHub's guidance is to either commit node_modules or compile the code and dependencies into a single file (for example with @vercel/ncc) and point main at that file. Editing package.json alone changes nothing on the runner, and asking users to install dependencies breaks the stated constraint.

1. Read the error: a required module is missing at run time.
2. Recall that the runner does not install action dependencies.
3. Keep the fix inside the action's repository.
4. Choose committing a bundled file and pointing main at it.

Exam tip: A JavaScript action must ship its dependencies: commit node_modules or a compiled bundle.

A JavaScript action's runs section needs using (the Node.js runtime) and main (the entry file).

The metadata syntax for JavaScript actions accepts node20 or node24 in runs.using and requires runs.main. GitHub removed Node 20 from Actions runners in September 2026 and asks maintainers to set node24. entrypoint and image are Docker container action keys, and javascript is not a valid runtime value.

1. Identify the action type: JavaScript.
2. Recall the two required runs keys: using and main.
3. Check that using names a Node.js version.

Exam tip: JavaScript action = runs.using: node24 + runs.main.

Every action metadata file requires name, description and runs.

The action metadata syntax lists name, description and runs as required. author, inputs, outputs and branding are optional, whatever the action type.

1. Recall the required top-level keys of action.yml.
2. Remove runs, which the question already gives.
3. Select the remaining two.

Exam tip: action.yml must have name, description and runs; everything else is optional.

required: true in action metadata documents intent; the action's code must enforce it.

GitHub's metadata reference notes that required: true does not make the run fail when the input is missing. The toolkit's core.getInput with { required: true } throws an error naming the input when its value is empty, which gives the early, clear failure the maintainer wants. A default token changes behaviour the stem forbids, and deprecationMessage serves a different purpose.

1. Recall whether the runner enforces required inputs.
2. Find where the check must live: the action's own code.
3. Choose the toolkit call that fails on an empty input.

Exam tip: The runner does not enforce required inputs; core.getInput(name, { required: true }) does.