GH-200 practice questions

Question 1. Which `on:` form restricts a workflow to pushes and pull requests on main only?

1. An event-configuration map, listing branches under each event
2. A single event, on: push
3. An array, on: [push, pull_request]
4. A schedule with a cron expression matching the branch

Question 2. A deploy job must run only when the preceding build job reported that something actually changed. How is that wired?

1. Read `steps.build.outputs.changed` in the deploy job
2. Use `needs: [build]` with `if: needs.build.outputs.changed == 'true'`
3. Set an environment variable with GITHUB_ENV in the build job and read it in deploy
4. Cache the flag in the build job and restore it in deploy

Question 3. A team spends the first hour of every release day running the same lint, test and package steps by hand, and a step is occasionally missed. Beyond saving time, what is the strongest argument for automating the sequence?

1. It removes the need for code review, since automation checks the code
2. The same steps run the same way every time, so a missed step stops being possible
3. It guarantees the build is faster than running the steps locally
4. It transfers responsibility for failures from the team to GitHub

Question 4. A value is needed by several workflows across an organisation, is not sensitive, and changes occasionally. What is the appropriate home for it?

1. An organisation variable, read through the vars context
2. A hard-coded value in each workflow, updated when it changes
3. An organisation secret, read through the secrets context
4. A step-level env entry in every workflow that needs it

Question 5. A workflow run appears in the Actions tab at 03:00 with no corresponding commit. You need to establish what started it, and you only have API access. What tells you?

1. The run object's event property, alongside its commit SHA, actor and timestamp
2. The name of the first job in the run
3. The runner image the run was allocated
4. The repository's branch protection settings

Question 6. An end-to-end test job should upload browser screenshots when it fails, but the upload step never runs on red builds. What is missing?

1. A needs: reference to the failing job
2. retention-days set on the upload action
3. The artifact name must be unique per run
4. A condition such as if: always() or if: failure() on the upload step

Question 7. A job occasionally hangs and consumes minutes until the platform's own limit terminates it. What is the appropriate fix in the workflow?

1. continue-on-error: true, so a hung job does not fail the run
2. concurrency, so only one instance of the job can run
3. fail-fast: false, so the rest of the matrix continues
4. timeout-minutes on the job, set to a value comfortably above its normal duration

Question 8. A reviewer asks what continue-on-error: true on a single step actually changes, given that the step still fails. What is the accurate answer?

1. Both the job and the run are still failed, and the setting only suppresses the annotation
2. The job is failed but the run is reported as successful
3. The step is marked failed, the remaining steps in the job still run, and neither the job nor the run is failed by it
4. The step is skipped silently and nothing is recorded against it

Question 9. An organisation shortens its default artifact retention to reclaim storage, but usage does not fall. Why?

1. Storage is measured before compression, so the change is invisible
2. Retention changes apply only to new artifacts and log files, not to objects that already exist
3. Retention settings take 90 days to take effect
4. Retention can only be set at enterprise level, so a repository change is ignored

Question 10. A GitHub Script automation has grown to eighty lines and is duplicated in three repositories. What should happen?

1. Convert it into a Docker container action for isolation
2. Split it across three shorter GitHub Script steps
3. Move it into a JavaScript action, which gives metadata, versioning and publication
4. Keep it inline but add comments so it is easier to read

Question 11. An organisation publishes an internal library as a package and wants only its own repositories to consume it. What determines who can install it?

1. The package's visibility, which for a private package restricts access to those with permission on it
2. The licence file in the source repository
3. Whether the workflow that published it used GITHUB_TOKEN or a personal access token
4. The retention period configured for the package

Question 12. A nightly workflow is failing every night while a fix is developed. The team wants the noise to stop without losing the file or its history. What should they do?

1. Disable the workflow, and re-enable it once fixed
2. Delete the workflow file and restore it from git later
3. Set continue-on-error: true on every job
4. Add an if: false condition to each job

Question 13. A composite action's step writes to $GITHUB_OUTPUT but the workflow fails with an error about the step. What is the most likely omission?

1. The step needs continue-on-error: true to write outputs
2. Composite actions cannot write to GITHUB_OUTPUT and must use GITHUB_ENV
3. The run step does not declare shell:, which composite actions require
4. The action.yml is missing a runs: image: key

Question 14. You need an action that runs on Linux, macOS and Windows runners and starts as quickly as possible. Which type fits?

1. A Docker container action, because the image guarantees consistency
2. A composite action, because it is the only type that is cross-platform
3. A JavaScript action, because it runs directly on the runner and is not tied to Linux
4. Any type, since all three behave identically across operating systems

Question 15. An action catches every exception and logs it with console.log so users are not alarmed by stack traces. A later job then consumes an output that was never produced. What is the root cause?

1. The action is not failing properly: swallowing the error lets the step report success, so nothing stops the workflow and the later job runs on nothing
2. The later job is missing a needs: entry
3. console.log output is not captured in the run log
4. The output should have been written to GITHUB_ENV rather than to GITHUB_OUTPUT

Question 16. Which mitigation most directly removes the persistence that makes a compromised self-hosted runner dangerous over time?

1. Using ephemeral runners that reset after each job
2. Increasing the runner's disk encryption
3. Adding the runner to a larger runner group
4. Switching the runner's operating system to Windows

Question 17. An organisation wants to guarantee that a third-party action cannot be swapped for malicious code after review. What achieves this?

1. Pinning to the major version tag and enabling Dependabot
2. Forking the action and referencing the fork's default branch
3. Requiring the action to carry a Verified creator badge
4. Pinning to the full commit SHA, and enforcing SHA pinning through the allowed actions policy

Question 18. Which of these is a genuine abuse risk that an Actions use policy is designed to reduce?

1. Runners being shared between unrelated organisations by default
2. A workflow triggered by an outside contributor running a malicious third-party action with access to repository secrets
3. Artefacts being retained longer than the repository setting allows
4. Workflow logs being publicly readable on private repositories

Question 19. An organisation plans to remove version 1 of a widely used reusable workflow. What should happen first?

1. Delete the tag, so consumers are forced to migrate promptly
2. Notify consumers in advance and publish a migration guide before removing the version
3. Make the repository private, so no new consumers can adopt it
4. Nothing, since consumers pinned to v1 are unaffected by its removal

Question 20. An enterprise policy permits only actions the enterprise itself created. One organisation beneath it wants to allow a single Marketplace action for its own repositories. What can that organisation do?

1. Add the action to an organisation allowlist, which takes precedence over the enterprise setting
2. Nothing locally: an inherited policy can be narrowed further but never widened, so the change has to be made a level up
3. Fork the action into the enterprise, which is blocked because a fork inherits the original's policy
4. Grant the requesting team the repository admin role, which bypasses the policy