Cheat sheet & self-check

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

1. Q1. 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 05 · Actions Runner Controller

2. Q2. 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 05 · Actions Runner Controller

3. Q3. 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 05 · Actions Runner Controller

4. Q4. 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 06 · OIDC federation & secret hygiene

5. Q5. 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 06 · OIDC federation & secret hygiene

6. Q6. 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 06 · OIDC federation & secret hygiene

7. Q7. 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 07 · Supply chain: sign, attest, scan, verify

8. Q8. 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 07 · Supply chain: sign, attest, scan, verify

9. Q9. 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 07 · Supply chain: sign, attest, scan, verify

10. Q10. 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 08 · Hardening the runner

11. Q11. 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 08 · Hardening the runner

12. Q12. 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 08 · Hardening the runner