CI/CD Interview Questions
CI/CD is the heart of modern DevOps, so interviewers lean on it heavily. They want to know that you understand the pipeline from a developer pushing code to that code running safely in production. This page gives you 13 common questions with short, accurate model answers you can adapt in your own words. Read the answer, then say it out loud once or twice so it feels natural in an interview.
Core concepts
What is the difference between CI and CD?
CI stands for Continuous Integration (developers merge their code into a shared branch many times a day, and an automated build plus tests run on every merge). It catches broken code early. CD has two meanings: Continuous Delivery (every passing build is automatically prepared and ready to deploy, but a human clicks the button to release) and Continuous Deployment (every passing build is released to production automatically with no human gate). The short version: CI builds and tests; Continuous Delivery makes a release ready; Continuous Deployment ships it for you.
What are the typical stages of a CI/CD pipeline?
A pipeline is just an ordered list of steps that run automatically. A common layout is: checkout (pull the code), build (compile or package it), test (unit and integration tests), scan (security and code-quality checks), artifact (save the built thing), and deploy (push to staging then production). Each stage only runs if the one before it passed, so a failing test stops the pipeline before anything reaches users.
Why run a pipeline instead of deploying manually?
Manual deploys are slow, easy to get wrong, and hard to repeat the same way twice. A pipeline gives you speed, consistency, and a record of exactly what ran. When to use it: any project with more than one developer or more than one environment. When not to bother: a throwaway personal script you run once.
Pipelines and tools
How does GitHub Actions differ from Jenkins?
Both run pipelines, but they are built differently. GitHub Actions is a hosted service tied to your GitHub repo and configured with YAML files in .github/workflows/. Jenkins is software you install and run yourself, usually on an Ubuntu server, configured with a Jenkinsfile or the web UI.
| Feature | GitHub Actions | Jenkins |
|---|---|---|
| Hosting | Cloud-hosted (or self-hosted runners) | You host and patch it |
| Config | YAML in the repo | Groovy Jenkinsfile |
| Setup effort | Almost none | Install Java, plugins, agents |
| Best for | GitHub-based teams, fast start | Full control, on-prem, complex builds |
Self-hosting Jenkins means you own its security patches. An unpatched Jenkins on a public IP is a classic breach. Keep it behind a firewall (
ufw) and update it withapt.
How would you install Jenkins on Ubuntu?
Jenkins needs Java first. Here are the exact steps on Ubuntu 22.04/24.04 LTS:
sudo apt update
sudo apt install -y fontconfig openjdk-17-jre
sudo wget -O /usr/share/keyrings/jenkins-keyring.asc \
https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key
echo "deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
https://pkg.jenkins.io/debian-stable binary/" | \
sudo tee /etc/apt/sources.list.d/jenkins.list > /dev/null
sudo apt update
sudo apt install -y jenkins
sudo systemctl enable --now jenkins
sudo systemctl status jenkinsOutput:
● jenkins.service - Jenkins Continuous Integration Server
Loaded: loaded (/usr/lib/systemd/system/jenkins.service; enabled)
Active: active (running) since Mon 2026-06-15 10:12:04 UTC; 3s ago
Main PID: 4821 (java)Jenkins now listens on port 8080. Open it only to trusted IPs: sudo ufw allow from 203.0.113.0/24 to any port 8080.
What does a simple GitHub Actions workflow look like?
A workflow is a YAML file describing when to run and what steps to take. This one runs tests on every push:
name: CI
on:
push:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: "20"
- run: npm ci
- run: npm teston is the trigger, jobs are groups of steps, and runs-on picks the machine. actions/checkout@v4 is a reusable step that pulls your code.
Secrets, artifacts, and rollbacks
How do you handle secrets in a pipeline?
A secret is any sensitive value (an API key, a database password, a deploy token). Never hard-code secrets in your YAML or commit them to Git. Instead store them in your CI tool’s secret store: GitHub Actions uses encrypted repository or organization secrets, read as ${{ secrets.MY_TOKEN }}. Jenkins uses the Credentials plugin. Both inject the value as an environment variable at run time and mask it in logs.
- run: ./deploy.sh
env:
DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}Anyone who can edit a workflow file can usually print a secret. Restrict who can change pipeline files and review those changes carefully. Treat the CI system as production-level sensitive.
What is a build artifact?
An artifact is the finished output of your build that you want to keep or reuse, for example a compiled .jar file, a Docker image, or a zipped front-end bundle. You build it once and reuse the exact same artifact across environments, so staging and production run identical code. When to use: anything you deploy. Store small artifacts in your CI tool’s artifact storage and store Docker images in a registry like Docker Hub or GitHub Container Registry.
What is the difference between an artifact and caching?
They look similar but serve different goals. An artifact is an output you keep and ship. A cache is temporary data (like a node_modules folder) you save only to make the next build faster. Losing a cache just makes a build slower; losing an artifact means you have to rebuild before you can deploy.
How do you roll back a bad deployment?
A rollback means putting the previous good version back quickly. The cleanest way is to redeploy the previous artifact or image tag, because you saved it. With containers you re-point to the last known-good tag:
kubectl rollout undo deployment/web-appOutput:
deployment.apps/web-app rolled backStrategies that make rollbacks painless: blue-green (run two identical environments and switch traffic), and canary (send a small slice of users to the new version first). When to use canary: high-traffic apps where a bad release is expensive. Always keep database migrations backward-compatible so a rollback does not break the schema.
What is a self-hosted runner or agent?
A runner (GitHub Actions) or agent (Jenkins) is the machine that actually runs your pipeline steps. Hosted runners are managed for you; self-hosted runners are your own Ubuntu servers that you register with the CI system. When to use self-hosted: you need special hardware, access to a private network, or large build caches. When not to: simple public projects, where managed runners are easier and safer.
How do you make a pipeline fast?
Slow pipelines kill productivity. Speed them up by caching dependencies, running independent jobs in parallel, only running tests affected by the change, and using smaller base images for Docker builds. Measure first with the timing the CI tool already shows you, then fix the slowest stage.
What is a pipeline-as-code and why does it matter?
Pipeline-as-code means your pipeline definition lives in a file in your repo (a workflow YAML or a Jenkinsfile) instead of being clicked together in a UI. This gives you version history, code review, and the ability to roll back the pipeline itself. It is the standard expectation in 2026 and you should always prefer it over UI-only configuration.
Best Practices
- Keep the pipeline definition in your repo (pipeline-as-code) so every change is reviewed and versioned.
- Build an artifact once and promote the same one through staging to production.
- Store every secret in the CI secret store, never in code or logs.
- Fail fast: run quick tests and linters before slow integration tests.
- Make rollbacks trivial by keeping old artifacts and backward-compatible migrations.
- Patch self-hosted runners and Jenkins regularly with
aptand keep them off the public internet. - Require a human approval gate before production for anything customer-facing.