GitHub GH-200: Author and Manage Workflows Practice Questions

continue-on-error: true on a step allows subsequent steps to run if that step fails, while the job itself is still ultimately marked failed — exactly the described behavior. B is wrong because setting continue-on-error: true on the job level causes the entire job (and dependent jobs using needs) to be treated as successful even when steps fail, which is too broad. C is wrong because || true makes the shell command exit with code 0, meaning GitHub Actions never sees a failure at all — the step is marked as passed, not just continued past. D is wrong because if: always() on subsequent steps would make them run regardless, but the failing step itself would still halt execution of later steps by default unless combined with another mechanism; it also doesn't control the job's final status in the desired way.

Organization-level variables (the vars context) are designed exactly for non-sensitive, reusable configuration values that can be shared across repos and updated centrally without touching YAML files. A is wrong because secrets are encrypted and intended for sensitive data; using them for non-sensitive config is a misuse and makes values harder to audit. C is wrong because hardcoding means every repo/workflow file must be updated manually when the value changes, defeating the goal. D is wrong because a committed .env file stores values in source control and requires a shell step to source it, which is fragile and not a GitHub-native configuration mechanism.

With cancel-in-progress: false, GitHub Actions does not cancel in-progress or queued runs. Instead, new runs wait until the current run in the same concurrency group finishes. Only one run executes at a time, and the others are queued. All three runs will eventually execute in order. A is wrong — the concurrency group still serializes runs; cancel-in-progress: false does not mean parallel execution. C describes the behavior when cancel-in-progress: true, where a newly queued run replaces a previously pending (queued) run — but that is not the case here. D is wrong — cancellation only happens when cancel-in-progress: true.

Option D is correct: when a workflow_call input has a default value defined, that default is used whenever the caller omits the input. Here default: true means ${{ inputs.notify }} evaluates to true. Option A is wrong: GitHub Actions does not implicitly default boolean inputs to false; it uses the declared default value. Option B is wrong: omitting an optional input with a declared default does not produce an empty string — the default is applied. Option C is wrong: only required: true inputs cause a validation error when omitted; notify is required: false and has a default, so omitting it is perfectly valid.

Option B is correct: the workflow is configured exactly as documented. The build job declares a job-level outputs block mapping version to ${{ steps.tag.outputs.version }}. The step with id: tag writes version=1.4.2 to $GITHUB_OUTPUT. The deploy job lists needs: build, which makes the needs.build.outputs context available. The expression ${{ needs.build.outputs.version }} resolves to 1.4.2, so the printed message is Deploying 1.4.2. Option D is wrong: the needs context is exactly how downstream jobs access upstream job outputs; the configuration is complete and correct. Option C is wrong: expressions in run: blocks ARE evaluated by GitHub Actions before the shell executes the script. Option A is wrong: jobs.<job_id>.outputs is the correct location to declare job-level outputs; the step output is correctly referenced via the steps context within that expression.