GH-200 - Secure and optimize automation (15% of the exam) - Section 5.5

Optimise workflow performance and cost using caching, artifact retention and concurrency and scaling strategies.

Optimise workflow performance and cost by applying caching efficiently, setting appropriate artifact retention periods, and using concurrency groups to cancel superseded runs. Weigh autoscaling and job parallelism strategies to reduce end-to-end pipeline duration.

caching efficiencyartifact retentioncost optimisationconcurrency

Practice question for this objective

Free sampleSecure and optimize automationmedium

A continuous integration workflow runs on every push to a pull request branch. When a developer pushes several commits quickly, multiple runs for the same branch execute at once and burn billable minutes, even though only the newest commit matters. The author wants each new push to cancel any earlier in-progress run for that same branch while never cancelling runs on other branches. Which configuration achieves this?

on: push
<target>:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true
  • AAdd a needs entry referencing the previous run and set cancel-in-progress: true, so each run waits for and then supersedes the prior run on the same branch before continuing.
  • BAdd a concurrency block with a group keyed by the workflow and github.ref and set cancel-in-progress: true, so a new run in the same branch group cancels the earlier in-progress one. Correct
  • CAdd an if condition comparing github.sha to the head commit so older runs evaluate to false and skip their jobs, leaving only the newest push to execute its steps to completion.
  • DAdd a strategy block with max-parallel: 1 so the branch processes only one run at a time, queueing each new push behind the previous run until that earlier run finishes naturally.
Use a concurrency group keyed on github.ref with cancel-in-progress to cancel superseded same-branch runs and save billable minutes. The concurrency key groups runs, and a group expression of github.workflow combined with github.ref scopes the group to a single branch. With cancel-in-progress: true, when a newer run enters the group the older in-progress member is cancelled, so rapid pushes no longer leave stale runs consuming minutes. needs, an if guard, and matrix max-parallel cannot cancel a separate run that is already executing.

Why A is wrong: Tempting because needs sequences work, but it only orders jobs inside one run and cannot reference a separate earlier run, so it cannot cancel an in-progress run on the branch.

Why B is correct: A concurrency group keyed on the branch ref keeps each branch isolated, and cancel-in-progress: true stops the running member when a newer run joins, so superseded runs end immediately.

Why C is wrong: Tempting because an if guard can skip jobs, but an already-running older run keeps consuming minutes until it finishes, and the condition cannot cancel a run that has already started.

Why D is wrong: Tempting because max-parallel limits simultaneity, but it is a matrix setting that only throttles jobs within a run, and queueing still lets the stale earlier run finish and waste minutes.

See more GH-200 practice questions, answers explained.

Exam traps in Secure and optimize automation

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.

  • Lower the repository-wide artifact and log retention period to seven days in the Actions settings, because per-artifact expiry must match the single value configured for the whole repository.

    Why it is wrong: Tempting because that setting controls retention, but it would shorten retention for every artifact in the repository, not just these logs, which is broader than the requirement allows.

  • Upload the built layers with actions/upload-artifact and download them in each later job, because artifacts are restored automatically into subsequent runs once the source content is unchanged.

    Why it is wrong: Tempting because artifacts share files between jobs, but they are scoped to a single run and are never auto-restored into a future run, so they cannot reuse layers across runs.

  • Compute the SHA-256 checksum of the binary and compare it with the checksum committed in the source repository, so a mismatch proves the artifact was not built by the expected workflow.

    Why it is wrong: Tempting because checksums detect tampering, but a matching hash only proves the bytes are unchanged and says nothing about which workflow or repository produced them, so it does not verify provenance.

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