Jenkins Interview Questions

True. A Jenkins executor is a single execution slot on a node that can run one build at a time; configuring multiple executors on a node enables that many concurrent builds on it.

True. Each executor on a Jenkins node is one concurrent build slot, so increasing the executor count lets more builds run in parallel on that node.

A Jenkins agent requires a Java runtime compatible with the Jenkins controller version. Agents communicate with the controller over the remoting protocol, which runs on the JVM; they do not need the full Jenkins web UI, the same OS as the controller, or a Kubernetes pod.

The Jenkins Docker agent plugin runs each build inside a container created from the specified image and removes that container when the build finishes. This gives the pipeline an isolated, reproducible environment without running steps directly on the controller or automatically pushing images to a registry.

A Jenkins Kubernetes agent dynamically creates a new pod for each build, runs the pipeline steps inside it, and terminates the pod when the build completes. This ephemeral, per-build model contrasts with a static, always-on agent and is the key advantage of the Kubernetes plugin.

To add a label to an existing Jenkins agent, go to Manage Jenkins → Nodes, click the node name, click Configure, type the label(s) into the Labels field, then Save. Each step depends on the previous page being open, so the order is fixed.

The correct order is: (1) the build is triggered and placed in the Jenkins build queue, (2) Jenkins assigns the build to an available agent matching the job's label expression, (3) Jenkins checks out the project's source code from the configured SCM, and (4) Jenkins executes the configured build steps. Each stage depends on the prior one completing — you need an agent before checkout, and checkout before build steps.

To create a new permanent Jenkins agent with labels, go to Manage Jenkins → Nodes, click New Node, enter the node name and select the type, fill in the configuration including the Labels field, then click Save. The steps form a fixed wizard flow with no reordering possible.

I would recommend a GitHub webhook as the primary build trigger. Webhooks are push-based: GitHub sends an HTTP POST to the Jenkins GitHub plugin endpoint (e.g., https://jenkins.example.com/github-webhook/) the instant a push occurs, so builds start within seconds instead of waiting for the next polling cycle. To set this up, I would install the GitHub plugin in Jenkins, configure the Jenkins URL under global system settings, add the webhook in the GitHub repository settings pointing to the Jenkins webhook URL, and select 'GitHub hook trigger for GITScm polling' in the Jenkins job/pipeline configuration.

The key drawback of Poll SCM is that it runs on a cron schedule (e.g., every 5 minutes) and must query the repository each time to see if anything changed. This wastes API rate-limit budget and compute on every interval even when there are zero new commits, and it introduces up to one polling-interval of latency before a build starts. With builds already taking 8 minutes, adding avoidable trigger latency compounds the feedback loop.

The trade-off with webhooks is that they require Jenkins to be reachable from GitHub over the internet, and if Jenkins is temporarily down or restarting when a push event fires, that webhook delivery is missed and no build is triggered for that commit. To mitigate this, I would periodically run a lightweight nightly Poll SCM job as a safety net to catch any missed pushes, or rely on a manual 'Rebuild' for rare gaps. This hybrid approach gives near-instant builds in the common case while ensuring no commit is permanently skipped.

Because Jenkins is behind a firewall with no inbound access, a direct GitHub webhook will not work — GitHub has no way to deliver the push event to Jenkins. The current Poll SCM approach 'works' but polls every 2 minutes, consuming GitHub API quota on every cycle even when nothing changed, and introducing up to 2 minutes of trigger latency.

I would replace polling with a webhook relay. The approach: deploy a lightweight relay client inside the Jenkins network that establishes an outbound connection to a relay broker (e.g., smee.io, or a self-hosted relay on a public server). GitHub sends webhook events to the broker's public URL; the relay client inside the firewall receives them and forwards the POST to the local Jenkins GitHub webhook endpoint. Because the connection from Jenkins-side to the broker is outbound, no inbound firewall rule is needed.

This eliminates the 2-minute polling interval entirely. Builds trigger within seconds of a push, and GitHub API rate limits are no longer consumed by repeated polling queries — the webhook is a single HTTP push per event, not a scheduled GET per interval.

The trade-off is added operational complexity: the relay broker and client become an additional component that must be monitored and maintained. If the relay goes down, webhook deliveries are missed. As a fallback, I would keep a low-frequency Poll SCM (e.g., every 30 minutes) as a safety net to catch any events missed during a relay outage, so no commit is permanently skipped. This hybrid gives near-instant builds in the common case while retaining a backstop.

An executor. Each executor represents a single slot on an agent (or the built-in controller) that can run one build at a time. The number of executors assigned to a node determines how many concurrent builds that node can handle.

Jenkins matches the label expression against the labels assigned to each agent. Only agents whose configured labels satisfy the expression are eligible to run the build, and Jenkins schedules the build on one of those agents that has a free executor.

The build stays in the build queue waiting. It remains queued until an executor on a matching agent becomes free (i.e., a currently running build on that agent finishes), at which point Jenkins assigns the queued build to that now-available executor and starts it.

In a Jenkins Declarative Pipeline, you can restrict the build to agents that carry BOTH the linux and docker labels by writing:

agent { label 'linux **&&** docker' }

The blank is the logical operator that requires both labels to match simultaneously. Enter the two-character symbol (no spaces, no extra characters).

A single executor runs exactly one build step (one sh/bat/batch block, one Maven goal, etc.) at a time. A job/stage that fans out into multiple parallel branches will consume one executor per concurrent branch at the same instant. A Jenkins node (controller or agent) has a fixed executor count, so the sum of simultaneously-active build steps across all jobs on that node cannot exceed that count; additional steps queue until an executor frees up. Therefore measuring 'concurrent builds' is imprecise — you must reason in terms of concurrent build steps and the executor budget per node.

Use the agent { label 'linux && docker' } syntax (or node('linux && docker') in Scripted Pipeline). Jenkins matches the label expression against every online agent's configured label set. The built-in scheduler picks an idle executor on any matching agent; if none is free, the build waits in the queue. Labels are purely metadata — you assign them per-agent in the node configuration — so multi-label expressions let you express capability requirements (OS, tools, architecture) without hard-coding a specific node name.

Jenkins pins executor threads to each agent at the node-configuration level. The flyweight task (the Pipeline DSL evaluator / lightweight executor on the controller) does not consume a heavyweight executor slot — it runs on the controller's flyweight pool. Only the actual work — sh, bat, checkout, tool invocations, and any node/agent block body — grabs a heavyweight executor on the target agent. This is why a long-running input step or sleep inside a stage that is not inside an agent/node block does not hold an agent executor hostage: the Pipeline is suspended on the controller's flyweight thread, and the heavyweight executor is released back to the pool until work resumes.

The correct answers are A, B, D, and E. The Jenkins Kubernetes plugin dynamically provisions agent pods that are destroyed after each build, supports multi-container pods with container('') block targeting, injects a JNLP agent container for remoting, and allows pod templates at both global and folder levels. The Jenkins controller does not need to reside in the same Kubernetes cluster — only reachable API access to the cluster is required.

The correct answers are A, B, C, and E. The Docker plugin supports remote daemon connections via TCP or SSH; sh 'docker run' executes on whichever agent node is running the step; top-level agent { docker 'image' } runs all stages in that container unless a stage overrides it; and docker.withServer() lets Scripted Pipeline specify a custom Docker host. Docker-based agents do not require docker.sock mounted inside the agent container — that is only needed for Docker-inside-Docker usage.

Statements a, b, and d are accurate. Polling is an outbound pull from Jenkins to the SCM on each cron cycle; webhooks are an inbound HTTP POST from the SCM to Jenkins on push events. Polling latency is bounded by the interval, while webhooks trigger within seconds. When both are configured, polling won't redundantly trigger if the webhook already built the latest commit, because polling compares the remote HEAD against the last built revision. Statements c and e are false: webhooks don't query the SCM for new commits, and neither mechanism needs access to internal repository storage.

Starting with Jenkins 2.319, the controller's built-in execution node (formerly called "Master") was renamed to the **built-in** node. The old predefined master label that was previously auto-assigned to this node was replaced by a new reserved label of the same name as the node; Jenkins also maintains a backward-compatible alias so existing label expressions referencing master still resolve to this node.

In Jenkins label expressions (used in node('...') and agent { label '...' }), the boolean operators &&, ||, and ! follow standard precedence: ! binds tightest, then &&, then ||. Given the label expression linux || mac && docker, Jenkins evaluates it as linux||(mac&&docker) — write the fully parenthesized form showing the grouping Jenkins applies.

True. The Jenkins Kubernetes plugin injects the remoting agent JAR path, controller URL, agent name, and a per-build secret as the jnlp container's command-line arguments at provisioning time. Overriding the command or args on the jnlp container replaces those injected values, so the inbound agent never starts and the node stays offline until the pod times out.

False. The Jenkins Kubernetes plugin does not derive executor count from CPU requests or limits. Each pod template has a fixed executors configuration property (default 1) that is set at template-definition time and never changes based on runtime resource availability. Concurrency is achieved by provisioning additional pods, not by scaling executors within a single pod.

We would introduce a multi-dimensional label taxonomy where every agent carries labels from five orthogonal dimensions: os (e.g., os.linux, os.windows), arch (e.g., arch.x86_64, arch.arm64), toolchain (e.g., toolchain.java17, toolchain.node20, toolchain.go1.22), capability (e.g., cap.docker, cap.gpu-a100, cap.browser), and region (e.g., region.us-east, region.eu-west). An agent's complete label set is its identity. No flat single-word labels are allowed — every label is namespaced by dimension.

Governance: all agent definitions live in a Terraform-monorepo that is the single source of truth. Each agent definition specifies its labels AND the Docker image / AMI it boots from. The images are built by a shared pipeline that installs the exact tools matching the declared labels (e.g., toolchain.java17 image installs Temurin JDK 17 and a post-build smoke test asserts java -version returns 17). A nightly controller-side Groovy script iterates over online agents and runs a verification probe for each declared label — if an agent claims toolchain.java17 but java -version reports 21, the agent is marked offline with a reason and an alert fires. This eliminates silent drift.

Pipeline authors never write raw label expressions. Instead, a shared pipeline library exposes a selectAgent(map) function that takes a typed map (e.g., [os: 'linux', toolchain: 'java17', capability: 'docker']) and generates the correct label expression internally (e.g., os.linux && toolchain.java17 && cap.docker). This guarantees expressions are always minimal conjunctions across the required dimensions and prevents teams from matching too broadly.

For GPU starvation: GPU agents carry cap.gpu-a100 (or similar) but critically do NOT carry any broad generic label like linux or docker that non-GPU jobs match on. Instead, GPU agents are described only by os.linux && cap.gpu-a100. Non-GPU jobs that need os.linux && cap.docker will never match GPU agents because the GPU agents lack cap.docker. Additionally, we configure a custom QueueSorter that gives priority boost to builds whose label expression includes a scarce-capability label, ensuring GPU jobs jump ahead of any non-GPU contention. The Kubernetes plugin's pod template for GPU nodes has a higher idleMinutes and a dedicated nodeSelector so only GPU workloads schedule there.

Elastic provisioning: each label dimension maps to a Kubernetes plugin pod template. When a build enters the queue with a label expression, Jenkins' Kubernetes plugin matches it to the pod template(s) whose labels satisfy the expression and provisions an ephemeral pod. For permanent agents (e.g., bare-metal GPU hosts), we use the retentionStrategy with demand mode so idle agents are taken offline after a timeout but reconnected when a matching queued item appears. For peak load, the pod templates specify autoscaling via cluster-autoscaler node pool taints/tolerations, so a surge of toolchain.java17 && cap.docker jobs triggers new nodes. The shared library's selectAgent also accepts an optional ephemeral: true flag that routes to cloud pod templates instead of permanent agents for stateless builds, reserving permanent agents for stateful workloads.