Cheat sheet & self-check

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

1. Q1. 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 01 · The execution model

2. Q2. 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 01 · The execution model

3. Q3. 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 01 · The execution model

4. Q4. 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 02 · Real pipelines

5. Q5. 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 02 · Real pipelines

6. Q6. 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 02 · Real pipelines

7. Q7. In ARC's scale-set mode, what happens when a job is queued?

   1. AA permanent runner picks it up
   2. BThe listener receives the job from GitHub, ARC creates an ephemeral runner pod for it, and the pod is deleted after the single job
   3. CGitHub starts a VM in your cluster
   4. DThe job waits for a cron
   Show answer

   B. One job per fresh runner pod: clean state every time and autoscaling from minRunners to maxRunners.

   From lesson 03 · Actions Runner Controller

8. Q8. Why is a GitHub App preferred over a personal access token for ARC?

   1. AIt's faster
   2. BIt isn't tied to a person, has fine-grained permissions and short-lived installation tokens, and survives staff changes
   3. CPATs don't work at all
   4. DApps are free and PATs cost money
   Show answer

   B. Organisation infrastructure shouldn't depend on one person's account and long-lived token.

   From lesson 03 · Actions Runner Controller

9. Q9. A job needs to build a container image. Which trade-off comes with ARC's dind (Docker-in-Docker) mode?

   1. ANone
   2. BIt's convenient (docker commands work) but runs a privileged sidecar, which weakens isolation; rootless builders or kubernetes mode reduce that risk
   3. CIt can't push images
   4. DIt only works on Windows
   Show answer

   B. Privileged containers can reach the node. Choose the mode deliberately, and isolate runner nodes (lesson 06).

   From lesson 03 · Actions Runner Controller

10. Q10. How does OIDC federation remove stored cloud keys from CI?

    1. AIt encrypts the keys
    2. BThe job requests a short-lived signed token from GitHub describing its repo/branch/environment; the cloud verifies it against a trust policy and returns temporary credentials
    3. CIt stores keys in Git
    4. DIt uses SSH
    Show answer

    B. No static secret exists to leak. Credentials last minutes and only match the workflows you trust.

    From lesson 04 · OIDC federation & secret hygiene

11. Q11. Your AWS role trusts `repo:acme/*`. What's the risk?

    1. ANone
    2. BAny workflow in any acme repo (including less-reviewed ones) can assume the role; pin the exact repo and branch or environment
    3. CThe role will be deleted
    4. DIt only affects forks
    Show answer

    B. The subject condition is the whole security boundary. Make it as specific as possible.

    From lesson 04 · OIDC federation & secret hygiene

12. Q12. Which secrets still need managing even with OIDC everywhere?

    1. ANone
    2. BThings without federation support: third-party API tokens, registry credentials for some registries, signing keys, and so on; scope them to environments, rotate them, and scan for leaks
    3. COnly the GITHUB_TOKEN
    4. DOnly SSH keys
    Show answer

    B. OIDC removes cloud keys, but not every integration supports it, so secret hygiene still matters.

    From lesson 04 · OIDC federation & secret hygiene

13. Q13. What does keyless signing with cosign in GitHub Actions use instead of a long-lived private key?

    1. AA password
    2. BThe workflow's OIDC identity: Sigstore issues a short-lived certificate for it, the signature is recorded in a transparency log, and verifiers check the identity and issuer
    3. CAn SSH key
    4. DNo signature at all
    Show answer

    B. No key to store or leak. Verification checks WHO signed (which repo/workflow) rather than which key.

    From lesson 05 · Supply chain: sign, attest, scan, verify

14. Q14. What is build provenance?

    1. AThe Dockerfile
    2. BA signed statement of how an artifact was built: source repo and commit, builder, workflow and parameters
    3. CThe image size
    4. DThe registry name
    Show answer

    B. Provenance lets consumers check that an image came from the expected repo and pipeline (SLSA's central idea).

    From lesson 05 · Supply chain: sign, attest, scan, verify

15. Q15. Where must signatures be verified to actually protect you?

    1. AOnly in CI
    2. BAt deploy/admission time (e.g. a policy engine in the cluster), so unsigned or wrongly signed images are refused
    3. CIn the README
    4. DNowhere, signing is enough
    Show answer

    B. Signing without verification is decoration. Enforce it where images are admitted.

    From lesson 05 · Supply chain: sign, attest, scan, verify

16. Q16. Why should self-hosted runners not be used for public repositories that accept fork PRs?

    1. AThey're slower
    2. BAnyone can open a PR that runs arbitrary code on your runner, inside your network
    3. CGitHub forbids it technically
    4. DForks can't use Actions
    Show answer

    B. A self-hosted runner executes whatever the workflow says. For untrusted code, use GitHub-hosted runners or heavily isolated, ephemeral ones with no network access to internal systems.

    From lesson 06 · Hardening the runner

17. Q17. What makes ephemeral runners safer than long-lived ones?

    1. AThey're cheaper
    2. BEach job starts on a clean runner, so a malicious or buggy job can't leave behind files, credentials or processes for the next job
    3. CThey have more CPU
    4. DThey skip checkout
    Show answer

    B. Persistence between jobs is how one compromised build poisons later ones, including release builds.

    From lesson 06 · Hardening the runner

18. Q18. A runner pod on EKS uses the node's IAM role. What's wrong?

    1. ANothing
    2. BEvery job on that node inherits the node's cloud permissions; use per-workload identity (IRSA/Pod Identity) or OIDC federation, and block access to the instance metadata service from runner pods
    3. CIt's slower
    4. DEKS doesn't allow it
    Show answer

    B. Jobs should get only the credentials they explicitly request, never ambient node permissions.

    From lesson 06 · Hardening the runner

19. Q19. How compatible are Gitea/Forgejo Actions workflows with GitHub Actions?

    1. ANot at all
    2. BLargely compatible syntax (on, jobs, steps, uses, run); most common actions work, but some GitHub-specific features and actions don't, so test each workflow
    3. CIdentical in every feature
    4. DThey only support Jenkinsfiles
    Show answer

    B. The runners are based on act-style execution. Familiar syntax, but not a perfect clone of GitHub's platform.

    From lesson 07 · The air-gapped port

20. Q20. In an air-gapped network, where does `uses: actions/checkout@v4` come from?

    1. Agithub.com, always
    2. BFrom a mirror of that action's repository inside the air gap, with the server configured to resolve actions locally
    3. CIt's built into Git
    4. DIt can't be used
    Show answer

    B. Every external dependency (actions, images, packages, scanner databases) must be mirrored inside the gap.

    From lesson 07 · The air-gapped port

21. Q21. Keyless cosign signing isn't possible offline by default. Why, and what's the alternative?

    1. Acosign doesn't work offline
    2. BKeyless relies on public Sigstore services (Fulcio, Rekor) and an OIDC issuer; offline, use key-based signing with keys in an HSM/KMS or run a private Sigstore
    3. CSigning isn't needed offline
    4. DUse MD5 sums instead
    Show answer

    B. Supply-chain controls still matter inside the gap; they just use local trust roots.

    From lesson 07 · The air-gapped port

22. Q22. Why set the built-in (controller) node to 0 executors?

    1. ATo save money
    2. BBuilds on the controller can read its files, including credentials and configuration; run builds only on agents
    3. CIt's faster
    4. DJenkins requires it
    Show answer

    B. The controller holds secrets for every job. Isolating builds to agents limits what a malicious build can reach.

    From lesson 08 · Jenkins in the real world

23. Q23. What problem do Jenkins shared libraries solve?

    1. APlugin updates
    2. BCopy-pasted pipeline logic across many Jenkinsfiles; common steps live in one versioned library
    3. CDisk space
    4. DUser login
    Show answer

    B. Like reusable workflows in Actions (lesson 02): one place to fix and improve, versioned so teams upgrade deliberately.

    From lesson 08 · Jenkins in the real world

24. Q24. Your single Jenkins controller dies in the middle of a release. What design would have reduced the impact?

    1. ANothing
    2. BConfig as code + pinned plugins in an image + backed-up JENKINS_HOME for fast rebuild, builds that are reproducible outside CI, and a documented manual release path
    3. CMore plugins
    4. DA bigger VM only
    Show answer

    B. CI is a dependency of every release. It needs a tested recovery path and a fallback, like any production system.

    From lesson 08 · Jenkins in the real world