Basic Jenkins Interview Questions

1. What is Jenkins?
Answer:
Jenkins is an open-source automation server used to automate the building, testing, and deploying
of applications. It provides continuous integration (CI) and continuous delivery (CD) services,
making it easier for developers to integrate changes into a project and for DevOps teams to deliver
software efficiently.

2. What is a Jenkins pipeline?

Answer:
A Jenkins pipeline is a set of automated processes that define the steps required to build, test, and
deploy an application. Pipelines can be written in either Declarative or Scripted syntax using
Groovy. They allow you to script workflows and manage complex builds in a more flexible and
controlled way.

3. What are the types of Jenkins pipelines?

Answer:
1. Declarative Pipeline: A simpler and more readable syntax for creating pipelines.
2. Scripted Pipeline: Offers more control and flexibility, written entirely in Groovy.

4. How does Jenkins achieve continuous integration (CI)?

Answer:
Jenkins achieves CI by allowing developers to automatically integrate code changes into the shared
repository. Jenkins listens for changes in version control systems (like Git), pulls the code, and
triggers builds. It can then run tests, generate reports, and deploy builds automatically.

5. How do you configure Jenkins to pull code from a Git repository?

Answer:
 Install the Git plugin in Jenkins.
 Create a new Jenkins job (e.g., Freestyle Project or Pipeline).
 In the job configuration, under Source Code Management, select Git.
 Provide the repository URL and credentials (if necessary).
 Jenkins will pull the code from the specified repository when the job is triggered.

Intermediate Jenkins Interview Questions

6. What is a Jenkins agent/slave?
Answer:
A Jenkins agent (formerly called a slave) is a machine that connects to the Jenkins master and runs
jobs assigned to it. Agents can be on any platform that supports Java. This setup enables distributed
builds and allows Jenkins to scale out by distributing the workload across multiple machines.

7. What is the difference between a Freestyle job and a Pipeline job in Jenkins?
Answer:
 Freestyle Job: A simpler, legacy way to define Jenkins jobs. It is suitable for basic tasks like
pulling code from Git and running a script or command.
 Pipeline Job: A more modern approach that allows defining complex build, test, and
deployment workflows using Groovy scripts. Pipelines are code, versionable, and can handle
complex CI/CD tasks.

8. How do you trigger Jenkins jobs automatically?

Answer:
 Polling SCM: Jenkins periodically checks the version control system (e.g., Git) for changes.
 Webhook: Configure a webhook in the SCM (e.g., GitHub) to notify Jenkins when there is a
change.
 Build Triggers: In the job configuration, you can define Build Triggers like scheduling jobs
using CRON, triggering jobs after another job completes, or using plugins like GitHub
Webhook for automatic triggering.

9. How do you handle credentials securely in Jenkins?

Answer:
 Jenkins provides the Credentials Plugin to securely manage credentials like usernames,
passwords, SSH keys, and API tokens.
 In the job or pipeline, reference the credentials by their ID using the withCredentials()
block or directly in the environment variables.
 Credentials are encrypted and stored securely within Jenkins and can be scoped globally or
to specific jobs or folders.

10. What is a Jenkinsfile?

Answer:
A Jenkinsfile is a text file that contains the definition of a Jenkins pipeline. It allows you to
store pipeline code as part of the source code, version it, and track changes. It can be either written
in Declarative or Scripted syntax and is used to define a complete CI/CD pipeline.
Advanced Jenkins Interview Questions

11. How do you achieve parallel execution in Jenkins pipelines?

Answer:
You can use the parallel directive in a Jenkins Declarative Pipeline or in Scripted Pipelines to
execute multiple tasks simultaneously. For example:
groovy

pipeline {
stages {
stage('Parallel Stage') {
parallel {
stage('Test on Linux') {
steps {
sh 'run-tests.sh'
}
}
stage('Test on Windows') {
steps {
bat 'run-tests.bat'
}
}
}
}
}
}

This allows you to run different tasks (e.g., testing on different platforms) at the same time,
reducing the overall pipeline execution time.

12. How would you set up Jenkins to build and deploy a Docker-based application?
Answer:
1. Install Docker Plugin: Ensure the Jenkins server has the Docker plugin installed and
Docker is set up on the agent/machine.
2. Build Docker Image:
 Use a Jenkins pipeline to build the Docker image.
 Push the Docker image to a Docker registry (e.g., Docker Hub or AWS ECR).
3. Deploy Docker Container:
 Use Jenkins to run the Docker container either on the same agent or by pushing it to
a Kubernetes cluster.
Here’s a pipeline example:
pipeline {
agent any
stages {
stage('Build Docker Image') {
 steps {
script {
docker.build('my-app:${env.BUILD_ID}')
}
}
}
stage('Push Docker Image') {
steps {
script {
docker.withRegistry('https://index.docker.io/v1/', 'dockerhub-credentials') {
docker.image('my-app:${env.BUILD_ID}').push()
}
}
}
}
}
}

13. How do you integrate Jenkins with Kubernetes for deployment?

Answer:
 Install the Kubernetes plugin in Jenkins.
 Set up a Kubernetes cluster and configure Jenkins to use it as an agent (Jenkins dynamically
provisions Kubernetes pods to run jobs).
 Create a Jenkins pipeline that uses kubectl commands to deploy an application to the
Kubernetes cluster.
Example:
pipeline {
agent any
environment {
KUBECONFIG = credentials('kubeconfig')
}
stages {
stage('Deploy to Kubernetes') {
steps {
sh 'kubectl apply -f k8s/deployment.yaml'
}
}
}
}

14. How do you implement security in Jenkins?

Answer:
 Role-based access control (RBAC): Use the Role Strategy Plugin to create roles with
specific permissions (read, write, execute, etc.) and assign them to users or groups.
 Matrix-based security: Define granular permissions at different levels (job, folder, etc.)
using Jenkins' matrix-based security.
  Credentials Management: Use Jenkins' built-in credentials management system to securely
handle sensitive information (API tokens, SSH keys, etc.).
 Security best practices: Ensure Jenkins is up-to-date, use HTTPS, restrict anonymous
access, and use strong authentication mechanisms (e.g., LDAP, OAuth).

15. How can you monitor Jenkins jobs?

Answer:
 Job Logs: View logs for individual jobs through the Jenkins UI.
 Build Health: Jenkins provides build history and trends for each job, helping you track
stability.
 Monitoring Plugins: Use plugins like Monitoring Plugin, Prometheus Plugin, or integrate
with third-party monitoring systems (e.g., New Relic, Grafana) to monitor Jenkins and
gather performance metrics (CPU, memory usage, etc.).
 Alerts: Set up email notifications, Slack integration, or custom scripts to notify teams when
jobs fail or exceed thresholds.

Jenkins Pipeline Scripts

1. Simple Build and Test Pipeline (Declarative Syntax)

This basic pipeline script compiles code, runs unit tests, and reports the results.
groovy

pipeline {
agent any

stages {
stage('Checkout') {
steps {
// Checkout code from version control (GitHub, Bitbucket, etc.)
git 'https://github.com/your-repository/project.git'
}
}

stage('Build') {
steps {
// Build your project (e.g., Maven, Gradle, npm)
sh 'mvn clean install'
}
}

stage('Test') {
steps {
// Run unit tests
sh 'mvn test'
}
 post {
always {
// Publish test results (JUnit, for example)
junit 'target/surefire-reports/*.xml'
}
}
}
}

post {
always {
// Clean up workspace after the pipeline finishes
cleanWs()
}
success {
echo 'Build and test successful!'
}
failure {
echo 'Build or test failed.'
}
}
}

2. Pipeline with Docker Build and Push (Declarative Syntax)

This script builds a Docker image from your project, tags it, and pushes it to a Docker registry (e.g.,
Docker Hub or AWS ECR).
groovy

pipeline {
agent any

environment {
DOCKER_IMAGE = 'my-app:${BUILD_NUMBER}' // Dynamic image tag
DOCKER_REGISTRY = 'your-docker-hub-repo' // Replace with your Docker registry
}

stages {
stage('Checkout') {
steps {
git 'https://github.com/your-repository/project.git'
}
}

stage('Build Docker Image') {

steps {
script {
docker.build(DOCKER_IMAGE)
}
}
}
 stage('Push Docker Image') {
steps {
script {
docker.withRegistry('https://index.docker.io/v1/', 'dockerhub-credentials') {
docker.image(DOCKER_IMAGE).push()
}
}
}
}
}
}

3. Pipeline with Approval for Deployment (Declarative Syntax)

This pipeline includes a manual approval step before deploying to production.
groovy

pipeline {
agent any

stages {
stage('Build') {
steps {
sh 'mvn clean install'
}
}

stage('Test') {
steps {
sh 'mvn test'
}
}

stage('Deploy to Staging') {
steps {
echo 'Deploying to Staging Environment...'
// Deploy steps here (e.g., SSH, Kubernetes deployment, etc.)
}
}

stage('Manual Approval') {
steps {
input message: 'Approve deployment to production?', ok: 'Deploy'
}
}

stage('Deploy to Production') {
steps {
echo 'Deploying to Production Environment...'
// Production deploy steps
}
 }
}

post {
always {
echo 'Pipeline complete.'
}
}
}

4. Multibranch Pipeline with Parallel Stages (Declarative Syntax)

This pipeline runs tests in parallel for multiple platforms (e.g., Linux, macOS, and Windows) to
reduce overall test time.
pipeline {
agent any

stages {
stage('Checkout') {
steps {
git 'https://github.com/your-repository/project.git'
}
}

stage('Parallel Testing') {
parallel {
stage('Linux Tests') {
agent { label 'linux' }
steps {
sh './run-tests.sh'
}
}
stage('macOS Tests') {
agent { label 'mac' }
steps {
sh './run-tests.sh'
}
}
stage('Windows Tests') {
agent { label 'windows' }
steps {
bat 'run-tests.bat'
}
}
}
}
}

post {
always {
echo 'Parallel test stages completed.'
 }
}
}

5. Scripted Pipeline Example with Custom Groovy Logic

A more flexible approach using scripted syntax, which allows custom Groovy logic. This example
shows a pipeline with conditions and loops.
node {
def shouldDeploy = false

stage('Checkout') {
checkout scm
}

stage('Build') {
try {
sh 'mvn clean install'
} catch (Exception e) {
echo 'Build failed'
currentBuild.result = 'FAILURE'
error 'Stopping pipeline'
}
}

stage('Test') {
try {
sh 'mvn test'
shouldDeploy = true
} catch (Exception e) {
echo 'Tests failed'
currentBuild.result = 'UNSTABLE'
}
}

if (shouldDeploy) {
stage('Deploy') {
input message: 'Proceed with deployment?', ok: 'Deploy'
echo 'Deploying to environment...'
// Deployment logic here
}
}

stage('Clean Up') {
cleanWs()
}
}

6. Pipeline with Terraform (Infrastructure as Code)

This pipeline runs Terraform commands to plan and apply infrastructure changes.
pipeline {
agent any

environment {
AWS_CREDENTIALS = credentials('aws-credentials')
}

stages {
stage('Checkout') {
steps {
git 'https://github.com/your-repository/infrastructure.git'
}
}

stage('Terraform Init') {
steps {
sh 'terraform init'
}
}

stage('Terraform Plan') {
steps {
sh 'terraform plan -out=tfplan'
}
}

stage('Terraform Apply') {
steps {
input message: 'Apply the changes?', ok: 'Apply'
sh 'terraform apply tfplan'
}
}
}

post {
always {
cleanWs()
}
}
}

7. Kubernetes Deployment (Declarative Syntax)

This pipeline deploys an application to a Kubernetes cluster using kubectl.

pipeline {
agent any

environment {
KUBECONFIG = credentials('kubeconfig')
}
 stages {
stage('Checkout') {
steps {
git 'https://github.com/your-repository/project.git'
}
}

stage('Build Docker Image') {

steps {
script {
docker.build('my-app:${BUILD_NUMBER}')
}
}
}

stage('Push Docker Image') {

steps {
script {
docker.withRegistry('https://index.docker.io/v1/', 'dockerhub-credentials') {
docker.image('my-app:${BUILD_NUMBER}').push()
}
}
}
}

stage('Deploy to Kubernetes') {
steps {
sh 'kubectl apply -f k8s/deployment.yaml'
}
}
}
}

Explanation of Key Concepts:

 Declarative vs Scripted Pipelines: Declarative syntax is simpler and more structured, while
scripted syntax offers more flexibility but requires more detailed control of the execution
flow.
 Stages: Each stage represents a distinct step in the pipeline (e.g., build, test, deploy).
 Parallelization: By using the parallel keyword, tests or tasks can run concurrently
across different environments or platforms.
 Input: The input step provides manual approval gates for deployments, often used when
transitioning to production.
 Docker and Kubernetes: Pipelines can integrate Docker for building and deploying
containerized applications, and Kubernetes for deploying to clusters.
 Terraform: Terraform can be integrated to manage infrastructure as code within a CI/CD
pipeline.
Advanced Jenkins Interview Questions

1. How would you design a Jenkins larchitecture for a large-scale project with hundreds of
developers?
Answer: For a large-scale project, consider a distributed Jenkins architecture:
1. Master-Agent Setup: Use multiple Jenkins masters to distribute the load, and set up
multiple agents/slaves to handle the builds. Ensure agents are spread across different
environments to run parallel builds.
2. High Availability (HA): Set up a backup Jenkins master or use a Jenkins HA plugin to
ensure the CI/CD system remains available even if the primary master fails.
3. Scalability: Use Kubernetes or AWS ECS to dynamically scale Jenkins agents based on
the load, ensuring resources are efficiently used.
4. Pipeline as Code: Store Jenkinsfile in the repository for each project, enabling
developers to easily manage and version pipelines.
5. Shared Libraries: Use Jenkins shared libraries to standardize code and reuse common
pipeline steps across multiple projects.
6. Monitoring and Alerting: Integrate with Prometheus and Grafana to monitor Jenkins
performance and receive alerts for system issues.
7. Security: Implement role-based access control (RBAC) and enforce proper credential
management.

2. What is a Jenkins Shared Library, and how would you use it?
Answer: A Jenkins Shared Library is a reusable code library that can be used across multiple
pipelines. It allows you to define common functions, variables, or classes in a centralized place,
making your pipeline code more modular and maintainable.
 Use Case: If you have repeated steps across pipelines (e.g., code checkout, Docker image
building, notifications), you can move this logic to a shared library.
 Implementation: Define the shared library in a separate Git repository, and reference it in
the pipeline code using @Library.

@Library('my-shared-library') _
pipeline {
stages {
stage('Build') {
steps {
script {
common.buildApp() // Call a function from the shared library
}
}
}
}
}

3. How do you ensure security in Jenkins pipelines, especially when handling sensitive data?
Answer:
1. Credential Management: Use Jenkins' Credentials Plugin to store sensitive information
like passwords, API tokens, and SSH keys. Never hard-code sensitive data in the pipeline
scripts.
2. Masking Sensitive Data: Use plugins like Mask Passwords Plugin to prevent sensitive
data from being displayed in the build logs.
3. Role-Based Access Control (RBAC): Restrict access using Role Strategy Plugin or other
authentication methods (LDAP, SSO) to ensure that only authorized users can configure jobs
or access certain projects.
4. Pipeline Security: Use withCredentials block in the pipeline to handle secrets,
ensuring they are not exposed.
5. Jenkins Job Restrictions: Enforce script approval to review Groovy code running within
Jenkins, preventing users from executing arbitrary code that could compromise security.

4. Explain how you would implement Blue/Green Deployment and Canary Deployment using
Jenkins.
Answer:
1. Blue/Green Deployment:
 Maintain two identical environments, "Blue" (current) and "Green" (new).
 Use a Jenkins pipeline to deploy the new version to the Green environment.
 Perform testing on Green, and if it passes, switch the production traffic from Blue to
Green.
 Update DNS or load balancer settings to direct users to the Green environment.
 If an issue is found, you can switch back to Blue, ensuring minimal downtime.
2. Canary Deployment:
 Deploy the new version to a small subset of the servers or containers.
 Monitor performance metrics and logs to detect any issues.
 If successful, gradually increase the deployment to more servers, using Jenkins
pipelines to automate the progressive rollout.
 If failures are detected, roll back to the previous stable version, allowing for safer and
controlled deployment.
Example Jenkins pipeline snippet:
pipeline {
stages {
stage('Deploy Canary') {
steps {
// Deploy to 10% of the instances
sh 'deploy --canary --instances=10%'
}
}
stage('Full Rollout') {
when {
expression {
 // Rollout to 100% only if Canary deployment is successful
currentBuild.result == 'SUCCESS'
}
}
steps {
sh 'deploy --all'
}
}
}
}

5. What are Jenkins X, and how does it differ from Jenkins?

Answer: Jenkins X is an open-source, Kubernetes-native CI/CD solution that automates the
process of building, testing, and deploying applications. Unlike traditional Jenkins, which can be
manually configured and managed, Jenkins X focuses on:
1. Kubernetes Integration: Jenkins X is designed to run natively on Kubernetes,
automatically provisioning environments for development, staging, and production.
2. GitOps: Jenkins X uses a GitOps approach, where environment changes are managed
through Git repositories. This means that all changes are version-controlled, and
deployments are triggered by Git commits.
3. Automated Environment Management: Jenkins X can automatically create preview
environments for pull requests, making it easier to test changes before merging.
4. Pipeline Automation: Jenkins X automatically generates CI/CD pipelines based on project
structure, reducing the need for manual configuration.
Difference: While Jenkins is versatile and can be used for various CI/CD tasks, Jenkins X is
specialized for cloud-native and container-based applications with a focus on microservices and
Kubernetes.

6. How would you handle a situation where a Jenkins job fails intermittently?
Answer:
1. Analyze Logs: Check the Jenkins console logs for patterns in the failures. Look for stack
traces, error messages, or warnings that could indicate issues with dependencies, network, or
the environment.
2. Isolate the Issue: Identify if the failure is related to a particular step in the pipeline, such as
code checkout, build, test, or deployment. Try running that step independently to isolate the
problem.
3. Retry Mechanism: Implement retry logic in the Jenkins pipeline to automatically re-run the
failed step a specified number of times, especially for tasks that might fail due to transient
network issues.
4. Resource Management: Ensure that Jenkins agents have sufficient CPU, memory, and
other resources. Lack of resources might lead to intermittent failures.
5. CI/CD Pipeline Analysis: If the issue persists, review the pipeline scripts, dependencies,
and external services (e.g., databases, APIs) that might cause flaky tests or failures. Consider
stabilizing tests or adding more logging.
 6. Scheduled Downtime: Run the job at a different time to check if external factors (network
congestion, scheduled maintenance) are impacting the job.

7. How do you scale Jenkins for hundreds of concurrent builds?

Answer:
1. Distributed Jenkins Architecture: Configure Jenkins to use multiple agents. Agents can be
on VMs, physical machines, or containerized in environments like Docker or Kubernetes.
2. Dynamic Agent Provisioning: Use cloud-based solutions (AWS EC2, Azure VMs) or
Kubernetes to dynamically provision agents based on the demand. Plugins like Kubernetes
Plugin or Amazon EC2 Plugin allow Jenkins to automatically spin up new agents when a
job is triggered.
3. Load Balancing: Set up a load balancer in front of multiple Jenkins masters to distribute
requests across the servers. This can help reduce the load on a single Jenkins instance.
4. Job Queuing Management: Use the Throttle Concurrent Builds plugin to limit the
number of concurrent builds for resource-heavy jobs to prevent overloading agents.
5. Pipeline Optimization: Optimize pipeline stages to run in parallel where possible, reducing
overall build time.

8. What strategies do you use to handle long-running jobs in Jenkins?

Answer:
1. Parallel Execution: Break down the job into smaller, independent tasks that can run in
parallel, reducing the overall execution time.
2. Distributed Builds: Utilize Jenkins agents to distribute workloads across multiple
machines.
3. Checkpointing and Job Resumption: Use the Pipeline: Stage Step plugin, which allows
pipelines to resume from the last successful stage if interrupted.
4. Scheduled Builds: Schedule long-running jobs during off-peak hours to minimize the
impact on other tasks.
5. Containerization: Run long-running processes inside Docker containers to isolate them
from the host machine, improving reliability and cleanup after completion.

Jenkins Master-Slave Architecture

Jenkins is a popular open-source automation server that helps in automating the parts of software
development related to building, testing, and deploying. To handle larger projects and distribute the
workload efficiently, Jenkins follows a master-slave architecture (also known as master-agent
architecture). This setup allows Jenkins to scale and manage the execution of jobs across multiple
machines.

Key Concepts
1. Jenkins Master
  Role: The Jenkins Master is responsible for managing the Jenkins environment. It
serves as the main server that provides the user interface, handles job scheduling, and
assigns tasks to slaves.
 Responsibilities:
 Managing project configurations and job definitions.
 Scheduling build jobs.
 Sending jobs to the appropriate slaves (agents) for execution.
 Monitoring the status of jobs and agents.
 Handling plugin management, maintaining logs, and notifying users of build
results.
 Managing the overall Jenkins environment and orchestration of builds.
2. Jenkins Slave (Agent)
 Role: Jenkins Slaves are machines that run build jobs assigned to them by the master.
They can be on the same machine as the master or distributed across multiple
systems.
 Responsibilities:
 Execute the jobs that are delegated by the master.
 Run tasks based on specific labels or types of workloads (e.g., Linux builds,
Windows builds, testing, etc.).
 Communicate the results of tasks back to the master.
 Can be configured to run specific jobs or types of jobs only.
3. Communication:
 Jenkins Master and Slaves communicate over TCP/IP.
 The Master can initiate communication with a Slave, and vice versa, depending on
the setup (e.g., SSH, JNLP).
 Secure protocols are recommended to ensure secure data transmission between the
Master and Slaves.

Architecture Diagram
+---------------------+
| Jenkins Master |
+---------------------+
| - UI Management |
| - Job Scheduling |
| - Build Distribution|
+----------+----------+
|
+-----------+-----------+
| | |
+----------------+ +----------------+ +----------------+
| Jenkins Slave | | Jenkins Slave | | Jenkins Slave |
| (Linux Server) | | (Windows VM) | | (Mac Machine) |
| - Build Job A | | - Build Job B | | - Testing Job |
How It Works
1. Job Creation and Scheduling:
 A developer configures a job on the Jenkins Master using the Jenkins UI. This could
be a build job, testing job, deployment, etc.
 The Master schedules the job according to the trigger (manual, periodic, SCM
polling, etc.).
2. Job Assignment:
 The Master selects an appropriate Slave to run the job based on labels, resources, or
node availability.
 The assignment criteria might be based on:
 Operating system compatibility.
 Toolchain availability (e.g., a specific version of Python, Node.js, etc.).
 Resource availability (CPU, memory, etc.).
 Labels/tags assigned to the Slaves (e.g., linux, windows, build-
server, test-server).
3. Job Execution:
 The selected Slave receives the job details and executes the job.
 During execution, the Slave communicates with the Master, providing real-time
feedback on the job status.
4. Results and Feedback:
 After job completion, the results are sent back to the Master.
 The Master processes the results, stores build artifacts, logs, and displays job results
on the Jenkins dashboard.
5. Scaling and Load Distribution:
 More Slaves can be added to the setup to handle an increased number of jobs,
allowing for horizontal scaling.
 The Master can distribute jobs across Slaves based on load, ensuring efficient
utilization of resources.

Setting Up Jenkins Master-Slave Architecture

1. Install Jenkins Master:
 Install Jenkins on a dedicated machine/server. This will act as the Master.
2. Set Up Jenkins Slave:
 Install Java on the Slave machine (as Jenkins requires Java).
 Navigate to Manage Jenkins > Manage Nodes and Clouds > New Node to add a
new node (Slave).
 Configure the Slave by providing details like the name, remote directory, launch
method, labels, and more.
3. Connection Options:
 SSH: Configure the Slave to connect to the Master using SSH. This is a secure way
and is often preferred.
  JNLP: The Slave machine initiates a connection to the Master. Useful when the
Slave is behind a firewall or in a different network.
 Docker: Jenkins can launch Slave containers using Docker when the job requires it
(ephemeral agents).
4. Configure Labels:
 Assign labels to each Slave based on the type of tasks they can handle. This allows
jobs to be targeted to specific Slaves.

Advantages of Master-Slave Architecture

1. Scalability:
 You can add multiple Slaves to distribute the load and handle more jobs concurrently.
2. Parallel Execution:
 Multiple jobs can run in parallel across different Slaves, speeding up the CI/CD
pipeline.
3. Flexibility:
 Jobs can be distributed based on specific requirements (e.g., OS, software
dependencies).
 Resource-intensive tasks can be run on Slaves with higher configurations.
4. Resource Isolation:
 Isolate builds to different machines to avoid conflicts and provide a clean
environment for each job.
5. Load Balancing:
 Efficient distribution of jobs across multiple Slaves, ensuring no single Slave is
overloaded.

Example Configuration Snippet for Slave Node (JNLP)

# Assuming Jenkins Master has a URL: http://jenkins-master:8080
# Start a Slave using JNLP connection
java -jar agent.jar -jnlpUrl http://jenkins-master:8080/computer/jenkins-slave/slave-agent.jnlp -
secret <secret-key> -workDir "/home/jenkins"

Use Cases for Interviews

1. Why Master-Slave Architecture?
 Understand the need for distributing workloads and handling multiple jobs
simultaneously in a CI/CD setup.
2. How Does Jenkins Ensure Security?
 Discuss secure connections between Master and Slave using SSH and JNLP, and
recommend using encryption and authentication to ensure safe communication.
3. What Are the Drawbacks of This Setup?
 Single point of failure (Master node), potential network delays between Master and
Slaves, and the need for proper resource management.
Jenkins Master-Slave architecture helps organizations handle large-scale CI/CD deployments,
improves efficiency, and enables flexibility in managing different environments. Understanding this
concept is crucial for building robust and scalable Jenkins pipelines.