Cheat sheet & self-check

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

1. Q1. Why should the controller's built-in node have 0 executors in production?

   1. AIt saves licences
   2. BBuilds running on the controller can read JENKINS_HOME (credentials, config) and compete for its resources; run builds on agents instead
   3. CThe UI requires it
   4. DExecutors are deprecated
   Show answer

   B. The controller holds every secret and job definition. Keeping builds off it is both a security and a stability measure.

   From lesson 01 · Jenkins architecture and installation

2. Q2. What lives in JENKINS_HOME?

   1. AOnly logs
   2. BConfiguration, jobs and their build history, plugins, credentials (encrypted) and secrets used to decrypt them
   3. CContainer images
   4. DThe Git repositories
   Show answer

   B. JENKINS_HOME is the whole state of the controller, which is why it needs backups and careful access control.

   From lesson 01 · Jenkins architecture and installation

3. Q3. What is an executor?

   1. AA plugin
   2. BA slot on a node that runs one build at a time
   3. CA user role
   4. DA pipeline stage
   Show answer

   B. A node with 4 executors can run 4 builds concurrently. Agents on Kubernetes typically have one executor per pod.

   From lesson 01 · Jenkins architecture and installation

4. Q4. Why use single quotes in sh steps that reference secrets, e.g. sh 'echo $TOKEN'?

   1. AStyle only
   2. BWith double quotes Groovy interpolates the secret into the command string before the shell runs, which can expose it; single quotes let the shell read the environment variable
   3. CSingle quotes are faster
   4. DDouble quotes don't work
   Show answer

   B. Groovy string interpolation of secrets is a classic leak (Jenkins even warns about it). Let the shell expand the variable.

   From lesson 02 · Declarative pipelines

5. Q5. Where should a JUnit report be published so it's recorded even when tests fail?

   1. AIn the test stage's steps
   2. BIn post { always { ... } }
   3. CNowhere
   4. DIn when { }
   Show answer

   B. Steps stop at the first failure; post always runs, so reports are captured for failed builds too.

   From lesson 02 · Declarative pipelines

6. Q6. What does when { branch 'main' } do in a multibranch pipeline?

   1. AChecks out main
   2. BRuns that stage only when the build is for the main branch
   3. CMerges to main
   4. DFails other branches
   Show answer

   B. Stages like 'publish' or 'deploy' run only for main (or tags), while every branch and PR still builds and tests.

   From lesson 02 · Declarative pipelines

7. Q7. Why avoid mounting the host's Docker socket into build agents?

   1. AIt's slow
   2. BAccess to the Docker socket is effectively root on the node, so any build (or malicious dependency) could take over the host
   3. CDocker isn't supported
   4. DIt breaks caching
   Show answer

   B. Rootless builders (BuildKit rootless, Buildah) build images without host-level privileges, which is essential on shared Kubernetes nodes.

   From lesson 03 · Build, test and publish images

8. Q8. Which image tag is best for tracing a running container back to its source?

   1. Alatest
   2. BThe Git commit SHA (plus the digest recorded at push)
   3. CThe build number only
   4. DThe date
   Show answer

   B. A commit SHA tag points to the exact source; the digest guarantees the exact bytes. 'latest' tells you nothing.

   From lesson 03 · Build, test and publish images

9. Q9. In a GitOps setup, what's the last step of the Jenkins pipeline?

   1. Akubectl apply to production
   2. BUpdate the image tag/digest in the GitOps config repository (usually through a pull request); the in-cluster agent deploys it
   3. CRestart the cluster
   4. DEmail the team
   Show answer

   B. CI builds and publishes; deployment is pulled by Argo CD or Flux from Git, so CI doesn't need cluster credentials.

   From lesson 03 · Build, test and publish images