GH-200 - Author and manage workflows (25% of the exam) - Section 1.4

Use workflow commands, environment variables and service containers to support dependent services in build and test jobs.

Use workflow commands and environment variables to share state within a job, and declare service containers with the services keyword to run dependent services such as databases alongside build and test steps. Distinguish service containers from Docker run steps.

workflow commandsenvironment variablesservice containersservices keyword

Practice question for this objective

Free sampleAuthor and manage workflowsmedium

A workflow defines a single job whose steps compile a binary and then run a test suite against that freshly compiled file. A colleague suggests splitting the compile and test work into two separate jobs to make the run tidier. The author wants to understand the execution consequence before refactoring. Which statement correctly contrasts how steps behave against how separate jobs behave by default?

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - run: ./compile.sh
      - run: ./test.sh

ASteps run sequentially on the same runner and share its filesystem, while separate jobs run on independent runners in parallel and do not share a workspace by default. Correct
BSteps run in parallel and never share state, while separate jobs always run one after another on a single shared runner that keeps the workspace.
CSteps and separate jobs behave identically, both running sequentially on the same runner and sharing one persistent filesystem across the whole workflow run.
DSteps run on independent runners that each clean their filesystem, while separate jobs reuse one runner sequentially and carry the workspace from one job to the next.

Distinguish that steps run sequentially on one shared runner while separate jobs run on independent runners in parallel by default. All steps in a job execute in order on the same runner and share that runner's filesystem, so a later step can use files an earlier step created. Separate jobs, by contrast, are scheduled on independent runners and run in parallel unless ordered with needs, and they do not share a workspace, which is why splitting compile and test into two jobs would require uploading the binary as an artifact to pass it across.

Why A is correct: Steps execute in order inside one runner and can read files earlier steps produced, whereas jobs default to parallel runners with isolated filesystems, so the test job would not see the compiled binary without extra wiring.

Why B is wrong: Tempting because it sounds orderly, but it inverts the model: steps run sequentially and share state, and separate jobs run in parallel on independent runners by default rather than serially.

Why C is wrong: Tempting because both are units of work, but only steps share a runner and its filesystem; separate jobs get their own runners, so they are not interchangeable in execution behaviour.

Why D is wrong: Tempting because isolation matters, but it swaps the two: it is jobs that get independent runners, and steps that stay on one shared runner, so the described split is reversed.

See more GH-200 practice questions, answers explained.

Exam traps in Author and manage workflows

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.

The concurrency key, because setting concurrency: build forces deploy to queue behind build until that named group is released.
Why it is wrong: Tempting because concurrency does serialise runs, but it groups runs by a shared label to cancel or queue them, not to declare that one job depends on another finishing first.
Use localhost as the hostname on the published port, because the service port is mapped onto the runner host that the job container shares for networking.
Why it is wrong: Tempting because localhost works when steps run on the runner host, but the job runs inside a container, so localhost points at that container, not the MySQL service.
Connect to the container's published address by reading its dynamic IP from the github context, because service hostnames are not registered for runner steps.
Why it is wrong: Tempting because container IPs feel necessary, but service containers are reachable by their label and the github context exposes no such field, so this would fail to connect.

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