Cheat sheet & self-check

Pick an answer to see if you got it, and why.

1. Q1. Where does GitHub look for workflow definitions?

   1. AThe repository root
   2. B.github/workflows/*.yml in the repository
   3. CThe organisation settings only
   4. DAny YAML file
   Show answer

   B. Every YAML file in .github/workflows is a workflow; it's versioned and reviewed like the rest of the code.

   From lesson 01 · Workflows, events and your first pipeline

2. Q2. What's the difference between `uses:` and `run:` in a step?

   1. ANone
   2. Buses runs a packaged action (e.g. actions/checkout@v4); run executes shell commands
   3. Crun is for Windows only
   4. Duses is deprecated
   Show answer

   B. Actions are reusable building blocks; run is plain shell. Most workflows combine both.

   From lesson 01 · Workflows, events and your first pipeline

3. Q3. Why set `permissions:` explicitly?

   1. AIt's required syntax
   2. BThe GITHUB_TOKEN can otherwise have broader default rights; declaring only what a job needs limits damage if a step is compromised
   3. CIt speeds up runs
   4. DIt enables caching
   Show answer

   B. Least privilege for the automatic token is one of the simplest, most effective hardening steps.

   From lesson 01 · Workflows, events and your first pipeline

4. Q4. Are secrets available to workflows triggered by pull requests from forks?

   1. AYes, always
   2. BNo (except GITHUB_TOKEN with read-only rights), so untrusted code can't read them
   3. COnly on Mondays
   4. DOnly for admins
   Show answer

   B. GitHub withholds secrets from fork PR runs by default. Be very careful with pull_request_target, which runs with the base repository's permissions.

   From lesson 01 · Workflows, events and your first pipeline

5. Q5. Two jobs in a workflow have no `needs`. How do they run?

   1. AOne after the other, in file order
   2. BIn parallel, on separate runners, each with a fresh workspace
   3. COn the same runner, sharing files
   4. DOnly the first runs
   Show answer

   B. Jobs are independent by default. Use `needs` to order them and artifacts or outputs to pass data.

   From lesson 02 · The execution model

6. Q6. Why is `run: echo "${{ github.event.pull_request.title }}"` dangerous?

   1. AIt's slow
   2. BThe expression is pasted into the shell script before it runs, so a crafted PR title can inject commands; pass it through an environment variable instead
   3. CTitles are secret
   4. DIt fails on Windows
   Show answer

   B. Expressions are expanded into the script text. Use `env: TITLE: ${{ … }}` and reference "$TITLE" in the script.

   From lesson 02 · The execution model

7. Q7. What does setting `permissions: contents: read` at the top of a workflow do?

   1. AMakes the repo read-only for people
   2. BLimits what the automatic GITHUB_TOKEN can do in this workflow, so a compromised step can't push code or change settings
   3. CDisables secrets
   4. DBlocks pull requests
   Show answer

   B. Grant only what each workflow or job needs (e.g. packages: write only on the publish job).

   From lesson 02 · The execution model

8. Q8. What's the difference between a reusable workflow and a composite action?

   1. ANone
   2. BA reusable workflow is called as a whole job (or jobs) with its own runners; a composite action bundles steps that run inside the caller's job
   3. CComposite actions can't take inputs
   4. DReusable workflows only run on schedule
   Show answer

   B. Use reusable workflows for whole pipelines (build, deploy); composite actions for shared step sequences.

   From lesson 03 · Real pipelines

9. Q9. Why capture the image digest from the build step?

   1. AFor logs only
   2. BTags can move, but a digest identifies exactly the bytes you tested, so deploy, sign and scan that digest
   3. CDigests are shorter
   4. DRegistries require it
   Show answer

   B. Deploying by digest makes releases and rollbacks exact (see the scenario in lesson 05).

   From lesson 03 · Real pipelines

10. Q10. How do you require a human approval before a production deploy job runs?

    1. AAdd a sleep step
    2. BPut the job in an environment (environment: prod) configured with required reviewers
    3. CUse a matrix
    4. DDisable the workflow
    Show answer

    B. Environment protection rules pause the job until an approver allows it, and environment secrets are only available after approval.

    From lesson 03 · Real pipelines

11. Q11. Why generate tags with docker/metadata-action instead of hard-coding them?

    1. AIt's required
    2. BTags follow Git consistently: sha-<commit> for every build, semantic versions for release tags, branch names where useful, without custom scripting
    3. CIt makes images smaller
    4. DRegistries require it
    Show answer

    B. Consistent, derived tags make every image traceable to its source and release.

    From lesson 04 · Build, test and publish container images

12. Q12. What does cache-from/cache-to type=gha do?

    1. ACaches test results
    2. BStores BuildKit layer cache in the GitHub Actions cache, so unchanged layers aren't rebuilt on the next run
    3. CCaches the registry login
    4. DNothing on hosted runners
    Show answer

    B. Ephemeral runners start empty; a remote layer cache brings back fast rebuilds.

    From lesson 04 · Build, test and publish container images

13. Q13. Why promote by opening a pull request against the GitOps repo, rather than committing directly?

    1. APRs are faster
    2. BPromotion becomes reviewable and gated by checks, with an audit trail; for dev it can be auto-merged, for prod it needs approval
    3. CDirect commits are impossible
    4. DArgo CD requires PRs
    Show answer

    B. The same workflow serves every environment: auto-merge where risk is low, human approval where it isn't.

    From lesson 04 · Build, test and publish container images