GH-200 - Secure and optimize automation - 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.

More in this domain

Back to all Secure and optimize automation objectives, or the GH-200 cert hub.

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