Cheat sheet & self-check

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

1. Q1. What does a multibranch pipeline job do?

   1. ABuilds only main
   2. BScans a repository and creates a pipeline for every branch, pull request (and optionally tag) that contains a Jenkinsfile
   3. CMerges branches
   4. DDeploys to many clusters
   Show answer

   B. Each branch runs its own Jenkinsfile. New branches appear automatically; deleted ones are cleaned up.

   From lesson 04 · Multibranch pipelines and webhooks

2. Q2. Why use webhooks instead of periodic polling?

   1. AWebhooks are required
   2. BBuilds start within seconds of a push, and Jenkins isn't hammering the Git server with scans
   3. CPolling is more secure
   4. DThey're the same
   Show answer

   B. Polling wastes resources and adds delay. Keep a slow periodic scan only as a safety net for missed webhooks.

   From lesson 04 · Multibranch pipelines and webhooks

3. Q3. How does Jenkins stop a failing pull request from being merged?

   1. AIt deletes the branch
   2. BIt reports a failing status check to the Git server, and branch protection requires that check to pass
   3. CIt locks the repository
   4. DIt emails reviewers
   Show answer

   B. Jenkins reports; the Git server enforces through required status checks.

   From lesson 04 · Multibranch pipelines and webhooks

4. Q4. Why pin a shared library version in the Jenkinsfile (@Library('lib@v2.3.0'))?

   1. AIt's faster
   2. BSo a library change can't silently alter every pipeline at once; teams upgrade deliberately, and a bad release can be rolled back by version
   3. CUnversioned libraries don't load
   4. DSecurity scanners require it
   Show answer

   B. A shared library runs in every pipeline. Versioning turns it into a release with change control, instead of a global switch.

   From lesson 05 · Shared libraries

5. Q5. What goes in the vars/ directory?

   1. AEnvironment variables
   2. BGlobal steps: each file (e.g. vars/buildImage.groovy) becomes a step you call by its file name
   3. CSecrets
   4. DPlugins
   Show answer

   B. vars/ is the simplest, most common part of a library: named, documented steps usable directly in pipelines.

   From lesson 05 · Shared libraries

6. Q6. What's the main risk of a shared library that every team uses?

   1. ANone
   2. BA bug or breaking change affects every pipeline; it needs tests, versioning, a changelog and a staged rollout like any other product
   3. CIt uses too much disk
   4. DIt only works on Linux
   Show answer

   B. Treat the library as a product: tested, versioned and released gradually.

   From lesson 05 · Shared libraries

7. Q7. What's the main benefit of ephemeral Kubernetes agents?

   1. AThey're always faster
   2. BEach build gets a clean, isolated environment with exactly the tools it declares, and capacity scales with the cluster instead of a fixed agent fleet
   3. CNo need for a controller
   4. DThey don't need images
   Show answer

   B. No leftovers between builds, no snowflake agents to patch, and no idle machines waiting for work.

   From lesson 06 · Agents on Kubernetes

8. Q8. What is the jnlp container in an agent pod?

   1. AA build tool
   2. BThe inbound agent process that connects the pod back to the Jenkins controller; the plugin adds it automatically
   3. CA logging sidecar
   4. DA security scanner
   Show answer

   B. Your tool containers run the steps; the jnlp container is the agent itself. If it can't reach the controller, the pod never comes online.

   From lesson 06 · Agents on Kubernetes

9. Q9. Builds re-download all dependencies every time and are slow. What helps most?

   1. ABigger nodes
   2. BA dependency cache: a registry/proxy for packages (e.g. Nexus, Artifactory) and/or a cache volume, plus build-tool caches for images
   3. CMore executors on the controller
   4. DDisabling tests
   Show answer

   B. Ephemeral pods start empty. A nearby package proxy and remote build caches bring back the speed without shared mutable state.

   From lesson 06 · Agents on Kubernetes