Jenkins interview questions and answers and Answers (2026) - Part 01

Ans: This architecture is commonly used to distribute the workload and to scale Jenkins for larger and more complex continuous integration (CI) and continuous delivery (CD) pipelines.

• Jenkins Master: Central server managing Jenkins, scheduling jobs, and overseeing the environment
• Jenkins Slave/Agent: Worker machine executing build jobs dispatched by the master.
• Communication: The Master communicates with slaves over a network, selecting available agents for job execution.
• Job Execution: Slave nodes execute build tasks as per job configurations, such as compiling code or running tests
• Status Reporting: Slaves report job status and progress back to the master for monitoring and analysis

Ans: There are 2 types of pipeline

1. Scripted pipeline

   • Definition: Groovy-based scripting language directly within Jenkins.
   • Syntax: Imperative scripting syntax for sequential execution of commands and statements.
   • Flexibility: Allows dynamic generation of stages, parallel execution, and advanced logic.
   • Example: Imperatively defines stages and commands using Groovy.
   • Use Cases: Suitable for complex build and deployment requirements, and for teams familiar with Groovy scripting.

   Example:

   node {
       stage('build){
           sh 'mvn clean package'
       }
       stage('Test'){
           sh 'mvn test'
       }
       stage('Deploy'){
           sh 'ansible-playbook deploy.yaml'
       }
   }
   

2. Declarative pipeline

   • Definition: YAML-based syntax focusing on defining the desired state of the pipeline
   • Syntax: Predefined keywords and blocks for readability and maintainability.
   • Structure: Fixed structure with predefined sections for stages, steps, and post-build actions.
   • Example: Declaratively defines stages and steps using YAML.
   • Use Cases: Ideal for standardizing configurations, enforcing best practices, and promoting collaboration.

   pipeline {
   agent any
   stages {
       stage('Build') {
           steps {
               sh 'mvn clean package'
           }
       }
       stage('Test') {
           steps {
               sh 'mvn test'
           }
       }
       stage('Deploy') {
           steps {
               sh 'ansible-playbook deploy.yml'
           }
       }
   }   
   

Ans: Linux Server: /var/log/jenkins/jenkins.log Windows Server: C:\Program Files (x86)\Jenkins\jenkins.out

you can also access the logs via the Jenkins web interface. Navigate to “Manage Jenkins” > “System Log” or “Log Recorder” to view and manage various log files.

Q.4 How to trigger a build in Jenkins manually?

Ans: To trigger a build manually in Jenkins: - go to jenkins -> project/job -> ‘build now’

In declarative pipeline:

pipeline {
    agent any
    
    parameters {
        // Define any parameters needed for the build, if applicable
    }

    // Manual input to trigger the build

    triggers {
        userInput('Deploy to Production?') {
            // Customize the message displayed to the user
            message 'Do you want to deploy to production?'
            // Define parameters if needed
            parameters {
                // Define parameters for user input, if applicable
            }
            // Define options for the input step
            ok 'Deploy'
            submitter 'admin' // Specify user who can approve the input
        }
    }
    
    stages {
        // Define stages of your pipeline
        stage('Build') {
            steps {
                // Steps to build your project
            }
        }
        // Add more stages as needed
    }
    
    post {
        always {
            // Any post-build actions or cleanup tasks
        }
        success {
            // Actions to perform when the build is successful
        }
        failure {
            // Actions to perform when the build fails
        }
        unstable {
            // Actions to perform when the build is unstable
        }
    }
    
}

Ans: The default path for the Jenkins initial administrative password is:

Unix-like systems (e.g., Linux): /var/lib/jenkins/secrets/initialAdminPassword

Windows: C:\Program Files (x86) \Jenkins\secrets\initialAdminPassword

Ans:

1. Install Git plugin: “Manage Jenkins” > “Manage Plugins” > “Available” tab, search for “Git Plugin”, and install it.
2. Configure Global Git Settings (if necessary): Manage Jenkins” > “Configure System” -> Under git section, specify the path to the Git executable if Jenkins cannot locate it automatically.

Ans:

• Freestyle is the older model, where build steps are configured through the Jenkins web interface.
• Pipeline jobs store the build logic in a Jenkinsfile, support complex workflows including parallel execution and conditional logic, and scale much more cleanly across large teams.

Ans:

• Polling means Jenkins checks the repository on a configured interval and starts a build if it finds new commits since the last check. It works without any configuration changes on the repository side, but it introduces latency between a push and a build starting, and it wastes resources by checking constantly even when nothing has changed.

• Webhooks reverse the direction of that relationship: the repository sends a notification to Jenkins the moment a push happens, making the trigger immediate and far more efficient. For production setups, webhooks are the standard choice.

Ans: A multibranch pipeline automatically discovers branches in a repository that contain a Jenkinsfile and creates a corresponding pipeline job for each one. When a developer pushes a new feature branch, Jenkins finds it and starts running its pipeline. When the branch gets deleted, Jenkins cleans up the corresponding job.

For teams using feature branch workflows, this removes the overhead of manually creating and deleting jobs every time a branch comes and goes, and each branch gets its own isolated build history without requiring any additional configuration.

Ans: The Jenkins controller handles scheduling, configuration, the web interface, and build history, but it does not run the actual build workloads in a properly configured setup. Agents (also called nodes or workers) are the machines that execute pipeline stages.

When a pipeline runs, Jenkins routes stages to agents based on label matching: a stage that requires Docker goes to agents labeled “docker,” while a stage requiring Windows would route to a Windows agent. This setup allows you to parallelize work across machines, isolate environments per build, and keep resource-intensive computation off the controller.

Ans: Shared libraries allow reusable pipeline logic to live in a separate repository, where it can be called from Jenkinsfiles across many different projects.

Instead of writing the same Docker build-and-push sequence across a dozen Jenkinsfiles, you write it once in the shared library and every team calls it with a single line. Individual Jenkinsfiles stay clean and readable, the logic is consistent across all projects that use the library, and a fix in the shared library propagates to all consumers immediately.

Libraries can also be pinned to specific versions, which matters a lot when the shared library is actively changing and you need production pipelines to stay stable.

Ans: Console output is the first place to look. Jenkins logs each step with its exit code and full output, and the failure is usually visible there directly.

If the error looks environment-related (wrong tool version, missing dependency, unexpected PATH), the next step is checking which agent the build ran on and comparing its configuration to agents where the build passes.

For intermittent failures, adding the timestamps() wrapper and looking at how long individual steps are taking often reveals the issue: something waiting on a slow network call or an external service tends to show up clearly in the timing.

When a build passes locally but fails in Jenkins, the culprit is almost always environmental, and the most reliable approach is reproducing the agent environment locally using the same Docker image the agent uses.