25 CI/CD Pipelines questions with answers for devops roles — 5 easy, 13 medium, 7 hard.
About CI/CD Pipelines
CI/CD automates build, test and deployment so every change reaches users safely. This topic covers Jenkins controllers and agents, declarative Jenkinsfiles, GitHub Actions workflows, artefact repositories, secrets handling, deployment strategies like blue-green and canary, DevSecOps scanning, GitOps and DORA metrics.
Sheet progressStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
What is the difference between continuous integration, continuous delivery and continuous deployment?
Continuous integration means developers merge small changes often and every merge is automatically built and tested. Continuous delivery goes further: every passing build is packaged and ready to release, but a human approves the production push. Continuous deployment removes that manual step, so every change that passes all checks goes to production automatically. Each stage needs more test confidence than the last.
A common pipeline is checkout, build or compile, unit tests, static analysis and security scans, packaging into an artefact or container image, pushing to a registry, deploying to a test or staging environment, running integration or smoke tests, an approval gate, and production deployment with monitoring. Fast checks run first so developers get feedback within minutes and slow tests run later.
03
What is an artefact repository and why is it used?
An artefact repository such as Nexus, JFrog Artifactory or a container registry stores versioned build outputs like JAR files, npm packages and Docker images. The pipeline builds once and promotes the same artefact through dev, staging and production, so what you tested is exactly what you deploy. It also caches public dependencies, speeds up builds and keeps release history for rollbacks.
04
What is a webhook and how does it trigger a build?
A webhook is an HTTP callback: when an event happens in the Git server, such as a push or pull request, it sends a POST request with event details to a configured URL. Jenkins or another CI tool receives it and starts the matching pipeline immediately. This is better than polling the repository every few minutes, which wastes resources and delays feedback.
05
The build works on your laptop but fails on the CI server. How do you debug it?
The environments differ. Compare tool versions such as JDK, Node or Python, environment variables, and dependency versions, especially if there is no lock file. Check for files present locally but not committed, and for hard-coded paths. Reproduce by running the build inside the same Docker image the CI agent uses. Long term, build inside containers so local and CI match.
06
Explain the Jenkins controller and agent architecture.
The Jenkins controller stores configuration, schedules jobs, serves the UI and keeps build history. Agents are separate machines or containers that actually execute build steps, connected over SSH or JNLP and selected by labels. Running builds on agents rather than the controller keeps the controller stable and secure, and lets you scale with dynamic agents on Kubernetes or cloud VMs that are created per build.
07
What is the difference between declarative and scripted Jenkins pipelines?
Both are written in a Jenkinsfile using Groovy. Declarative pipelines use a fixed structure with pipeline, agent, stages, steps and post blocks, which is easy to read, validate and maintain. Scripted pipelines start with node and allow full Groovy logic, giving more flexibility but more room for messy code. Most teams use declarative and drop into a script block only when needed.
08
Compare blue-green, canary and rolling deployments.
Blue-green runs two full environments and switches traffic from old to new at once; rollback is instant but costs double capacity. Rolling replaces instances in batches with no extra environment, but old and new versions run together for a while. Canary sends a small share of traffic, say 5 percent, to the new version and widens it as metrics stay healthy, limiting blast radius.
Never store secrets in code or the Jenkinsfile. Use the CI tool's encrypted credentials store, such as Jenkins credentials or GitHub Actions secrets, or fetch them at runtime from HashiCorp Vault or AWS Secrets Manager. Prefer short-lived credentials, for example OIDC federation from GitHub Actions to AWS instead of long-lived keys. Mask secrets in logs and give each pipeline only the permissions it needs.
10
Builds fail randomly because of flaky tests. How do you handle it?
First identify flaky tests by tracking which tests fail and pass on the same commit. Quarantine them into a separate non-blocking job so the main pipeline stays trustworthy, and raise tickets with owners. Common causes are timing assumptions, shared test data, order dependence and external services. Blind automatic retries hide real bugs, so use them only briefly while fixing the root cause.
11
A production deployment failed halfway. What do you do?
Assess impact quickly using monitoring and error rates. If users are affected, roll back to the last good version, which should be a single pipeline action redeploying the previous artefact. Communicate status to stakeholders. Then check pipeline logs and application logs to find the cause, fix it in a branch and redeploy. Afterwards, hold a blameless review and add a check to catch it earlier.
12
You need one pipeline that deploys to dev, staging and production with approval before production. How do you design it?
Build and test once, publish a versioned artefact, then promote it through environments. Dev deploys automatically on merge, staging deploys after dev smoke tests, and production waits for a manual approval from authorised people using a Jenkins input step or GitHub environment protection rules. Keep environment-specific settings in config files or parameters, not separate pipelines, and record who approved each release.
13
Write a declarative Jenkinsfile with build, test and deploy stages.
name: CI
on:
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
cache: npm
- run: npm ci
- run: npm test
Add this as .github/workflows/ci.yml and make the job a required status check in branch protection.
# shell steps in any CI tool
IMAGE=registry.example.com/shop/api
TAG=$(git rev-parse --short HEAD)
echo "$REG_PASS" | docker login registry.example.com -u "$REG_USER" --password-stdin
docker build -t $IMAGE:$TAG .
docker push $IMAGE:$TAG
Tag with the commit SHA so each image is traceable and immutable; avoid relying on latest. Credentials come from the CI secret store, and --password-stdin keeps them out of process lists.
17
How do you use stored credentials inside a Jenkins pipeline?
pipeline {
agent any
environment {
SONAR_TOKEN = credentials('sonar-token')
}
stages {
stage('Push') {
steps {
withCredentials([usernamePassword(credentialsId: 'docker-hub',
usernameVariable: 'USER', passwordVariable: 'PASS')]) {
sh 'echo $PASS | docker login -u $USER --password-stdin'
}
}
}
}
}
Jenkins masks these values in console output. Use single quotes in sh so Groovy does not interpolate the secret.
18
How do you handle pressure when a release is blocked close to a deadline?
Situation: a security scan blocked our release one day before a client demo. Task: ship without ignoring the risk. Action: I checked the finding, confirmed it was a real vulnerable library, upgraded it, ran the full test suite and kept the product manager updated every few hours. Result: we released on time, and I added weekly dependency scans to avoid last-minute surprises.
19
What is DevSecOps and which security checks belong in a pipeline?
DevSecOps moves security earlier into the delivery process instead of a final audit. A pipeline typically adds secret scanning, static code analysis (SAST) with tools like SonarQube, dependency scanning (SCA) for vulnerable libraries, container image scanning with Trivy, infrastructure-as-code checks with Checkov, and sometimes dynamic testing (DAST) on staging. Critical findings fail the build, while lower ones create tickets.
GitOps uses a Git repository as the single source of truth for the desired state of infrastructure and applications. An agent running in the cluster, such as Argo CD or Flux, continuously compares the live state with Git and pulls changes to reconcile drift. Deployments become pull requests, giving review, audit history and easy rollback by reverting a commit. CI builds images; GitOps handles deployment.
DORA metrics measure software delivery performance: deployment frequency, lead time for changes, change failure rate and time to restore service. The first two measure speed and the last two measure stability. Elite teams deploy on demand with lead times under a day and recover within an hour. DevOps teams use them to find bottlenecks, not to rank individual engineers.
22
Your CI pipeline takes 40 minutes. How would you speed it up?
Measure first: find which stages take longest. Then cache dependencies and Docker layers, run independent stages and test suites in parallel, split tests across agents, and run only affected modules in a monorepo. Move slow end-to-end tests to a later stage or nightly run while keeping fast unit tests on every commit. Use bigger or autoscaled agents if they are the bottleneck.
23
The Jenkins controller is slow and builds keep queueing. What do you do?
Make sure no builds run on the controller by setting its executors to zero. Add agents, ideally dynamic ones on Kubernetes or EC2 that scale with the queue. Check controller heap, disk and plugin count, and remove unused plugins. Discard old builds and artefacts with retention rules. For very large setups, split teams across multiple controllers or move suitable jobs to another CI tool.
24
How do you run stages in parallel in a Jenkins declarative pipeline?
Situation: a release passed staging but caused payment timeouts in production because a new connection pool setting was wrong. Task: as release owner, I had to restore service. Action: I triggered the rollback job within ten minutes, updated stakeholders, then found the config difference between environments. Result: service recovered quickly and we added config validation and a canary stage to the pipeline.
Frequently asked questions
How important is CI/CD Pipelines in DevOps interviews?
CI/CD automates build, test and deployment so every change reaches users safely. This topic covers Jenkins controllers and agents, declarative Jenkinsfiles, GitHub Actions workflows, artefact repositories, secrets handling, deployment strategies like blue-green and canary, DevSecOps scanning, GitOps and DORA metrics.
How should I use the CI/CD Pipelines sheet?
Go top to bottom — easy to hard. Answer before opening each answer, tick what you solved and save misses to Last-Minute Revision.