CI/CD and Jenkins Interview Questions and Answers

A CI/CD pipeline is an automatic path from a code commit to a running deployment. It runs checks at every step, so problems are found early.

Typical stages:

1. Source: a push or pull request triggers the pipeline.
2. Build: compile code, install dependencies, build a Docker image.
3. Test: unit tests, linting, static analysis, security and dependency scans.
4. Package and publish: push the image or artifact to a registry (ECR, Docker Hub, Artifactory).
5. Deploy: release to dev, then staging, then production.
6. Verify: smoke tests, health checks, monitoring, and automatic rollback on failure.

Benefits: faster and more frequent releases, fewer manual mistakes, the same build every time, and quick feedback for developers. Common tools are GitHub Actions, GitLab CI, Jenkins, AWS CodePipeline and Argo CD.

What they are checking: Whether you can describe the whole flow from commit to production, not only the buzzwords.

DevOps is a culture and a set of practices that bring development and operations together. Software is delivered faster and more reliably, and everyone shares ownership. The main principles are:

• Collaboration and shared ownership: developers and operations work as one team. Both care about running the service, not only writing or deploying code.
• Automation: build, test, infrastructure setup and deployment are scripted. So they can be repeated and do not depend on one person.
• Continuous integration and delivery: merge small changes often, test each one automatically, and keep the main branch ready to release.
• Infrastructure as code: servers and networks are defined in files kept in version control (Terraform, CloudFormation) and reviewed like application code.
• Monitoring and fast feedback: metrics, logs and alerts show how a release behaves, so problems are found and fixed fast.
• Continuous improvement: reviews after incidents that blame no one, and small, frequent changes, lower the risk over time.

In an interview, link each principle to something you did. For example "I automated deploys with GitHub Actions and Terraform, so releases stopped depending on manual steps".

What they are checking: Whether you understand DevOps as culture plus automation, not only a list of tools

Pick the tool that fits where your code lives and how much you want to maintain.

• GitHub Actions: no server to run, works closely with GitHub, a big marketplace, and OIDC to clouds. The best default if your code is on GitHub.
• Jenkins: very flexible, with many plugins and full control. But you maintain the controller, agents, plugins and upgrades.
• GitLab CI: very good if you use GitLab. It has a built-in registry and scanning.
• AWS CodePipeline/CodeBuild: good for teams that use only AWS, with access through IAM.

Triggers: a push to a branch, a pull request, a tag push (releases), a schedule (cron), a manual start, or a webhook from another system.

I usually pick GitHub Actions because it needs less maintenance. I use Jenkins only when we need custom, on-premises or old integrations. Self-hosted runners help with private networks or heavy builds.

What they are checking: Whether you can explain a tool choice by maintenance, integration and cost.

GitOps means Git is the one source of truth for the state you want. An automatic agent keeps making the live system match Git.

Argo CD is a Kubernetes controller that does this:

• You point an Application at a Git repo path (plain YAML, Helm or Kustomize) and a target cluster and namespace.
• It compares live state to Git and reports Synced or OutOfSync.
• With auto-sync it applies changes. With selfHeal it undoes manual changes.
• Rollback is a Git revert. Every change has a record in commits and reviews.

Flow: CI builds and pushes an image, then updates the image tag in the manifest repo. Argo CD sees the commit and deploys. Benefits: no cluster credentials in CI, easy rollback, drift fixing, and a clear history. Databases are usually better as managed services or run by operators. GitOps then manages the operator and its custom resources.

What they are checking: Whether you understand the pull model, drift fixing and how CI passes the work to Argo CD.

• Continuous integration (CI): developers often merge small changes to a shared branch. Each merge builds and tests the code automatically, to find problems early.
• Continuous delivery (CD): every change that passes the pipeline is built into an artifact that is ready to release. It is deployed to a staging-like environment. But releasing to production needs a manual approval.
• Continuous deployment: the same as delivery, except that production releases happen automatically when all checks pass. No person has to approve.

In short: CI means merge and test automatically. Delivery means always ready to release, and a person presses the button. Deployment means there is no button. Choose deployment when tests are strong and the service is low risk. Choose delivery when rules or business timing need an approval.

What they are checking: Whether you can explain the three terms clearly, especially the manual approval in delivery.

GitOps means Git is the one source of truth for the state you want. An agent in the cluster keeps making the cluster match Git. Changes happen through pull requests. This gives you review, a history of changes, and an easy rollback by reverting a commit.

Argo CD is a common GitOps controller. It watches a repo path (plain YAML, Helm or Kustomize), compares it with the live cluster and syncs the differences. It can also auto-sync and self-heal.

For blue/green or canary releases, Argo Rollouts adds a Rollout resource. It runs the new version beside the old one and moves traffic, or switches the service. It can stop and roll back if the analysis fails.

My flow: CI builds and pushes the image and updates the image tag in the config repo. Then Argo CD deploys it.

What they are checking: Whether you understand pull-based deployment and can explain how Argo CD works in real life.

GitHub Actions pipelines are YAML workflows stored in .github/workflows/. A workflow has triggers (on), jobs and steps. Jobs run on GitHub-hosted or self-hosted runners.

Without CI/CD (manual): build and push the image, SSH to the server, then docker pull and docker run.

Jenkins is an open-source automation server for CI/CD. A controller schedules jobs, and agents run them.

GitHub Actions is the CI/CD system built into GitHub. These are its main terms:

A Jenkinsfile is a text file in the repository that defines a Jenkins pipeline as code. So the pipeline has versions and is reviewed like application code.

The controller (formerly master) runs the web page, the configuration, job scheduling and plugin management. Agents (nodes) are the machines where builds really run.

An artifact is the result of a build that you deploy or keep: a Docker image, JAR, wheel, npm package, zip, or test report.

Secrets (tokens, passwords, cloud keys) must never be in the repository or in plain pipeline files.

Blue-green keeps two identical production environments. Blue serves live traffic. You deploy the new version to green and test it. Then you switch the router (load balancer, DNS or Kubernetes Service selector) to green. Blue stays idle, ready for an instant rollback.

A canary release sends the new version to a small share of users (for example 5 percent) and watches it. If it is healthy, it slowly sends more traffic. The name comes from the canary bird that miners used to warn of danger.

Use Docker's official actions to log in, build and push. For AWS ECR, log in with OIDC to an IAM role. Do not store access keys.

They change at different speeds, carry different risks and need different permissions. So keep them apart.

Run fast tests first and slow ones later, as in the test pyramid:

In push-based deployment, the CI system runs commands that push the new version into the environment (kubectl apply, helm upgrade, ssh). The pipeline needs credentials for the cluster.

Sample answer:

"A developer creates a feature branch from main and opens a pull request. The PR starts CI: install with cache, lint, unit tests, security scans, and a build that makes a Docker image. The image is tagged with the commit SHA and pushed to [registry]. Reviewers approve, and branch protection requires that all checks pass.

When the PR is merged to main, the pipeline deploys the same image to dev automatically and runs smoke tests (quick basic checks). Then it moves to staging for integration tests and QA. Production needs a manual approval. It then rolls out with [rolling/canary] and is watched with [monitoring]. It rolls back automatically if health checks fail.

Config for each environment comes from Helm values or a parameter store. Secrets come from [secrets manager]. Infrastructure changes follow a separate Terraform pipeline. We use version tags for releases and keep a changelog."

Change the tools to match your real experience, but keep the flow: branch, PR, CI, artifact, promote, approve, deploy, verify.

What they are checking: Whether you can explain the whole flow with approval steps, moving one artifact up the environments, and rollback.

Sample flow:

1. A developer pushes a version tag (for example v1.8.0) or merges to main.
2. CI (GitHub Actions or Jenkins) runs tests, builds the image and scans it. It pushes the image to the registry with the version and SHA as tags.
3. CI updates the image tag in the config repo, for example in envs/staging/values.yaml. It does this with a pull request or a bot commit.
4. Argo CD watches the config repo. It builds the Helm chart with the values file for that environment and syncs the change to the staging cluster.
5. Smoke tests run. Moving to production means a reviewed change to envs/prod/values.yaml, which Argo CD then applies.
6. Rollback is a Git revert, or an Argo CD sync to the previous revision.

Per-environment values (values-dev.yaml, values-prod.yaml) hold the replicas, resources, ingress hosts and config. Secrets come from an external secrets operator. If you build the image once and move the same tag up, all environments stay consistent.

What they are checking: Whether you can explain how CI passes work to GitOps, and how environment config is kept apart from the chart.

Order matters: build once, scan, and push only what passes.

A self-hosted runner is a machine you manage. It registers with the CI service and takes jobs from it.

Avoid kubeconfig files that live for a long time. Use a short-lived identity with only the access it needs.

• Rolling update: replace instances a few at a time (the Kubernetes default). It is simple and needs no extra capacity. But old and new versions run together, and a rollback is a second rollout.
• Blue/green: run a full new environment (green) next to the current one (blue) and test it. Then switch traffic...

Use OpenID Connect (OIDC). GitHub gives a short-lived signed token to each workflow run. AWS swaps it for temporary credentials by assuming an IAM role. No long-lived key is stored anywhere.

Do not copy nearly identical charts for every service.

Keep the pipeline logic in one place and let each project give only the settings.

Multi-cluster:

• Register clusters in Argo CD (argocd cluster add <context>), which saves a service account credential for each cluster.
• Use one Application per workload per cluster, or an ApplicationSet with a cluster generator, which creates the applications for every cluster automatically.
• Choose one central Argo CD for all clusters (simple, one place of control). Or choose one Argo CD for each cluster (clear separation, more to maintain).

Use EventBridge. It receives CodePipeline state-change events and can run a Lambda function.

A common setup:

Locally (quick, for tests): zip the code and run aws lambda update-function-code --function-name my-fn --zip-file fileb://function.zip, or use SAM (sam build && sam deploy), Serverless Framework or CDK.

Yes. Many hosting platforms (like Amplify) can build for you. But if you run the build in your own CI, you get more control, and the host only serves the output.

A shared library is a Git repository of reusable Groovy pipeline code that many Jenkinsfiles load. It removes copy and paste and keeps pipelines consistent across dozens of services.

The pipeline can deploy to production, so attackers want it.

Use sed, yq or kustomize to replace the image tag with the build's tag. Then apply it or commit it.

First measure which steps are slow. Then fix the biggest one.

• Cache dependencies (npm, pip, Maven) and Docker layers (BuildKit cache, registry cache).
• Order the Dockerfile layers so steps that rarely change (dependency install) come before the source copy. Use multi-stage builds and small base images.
• Run in parallel: split lint, unit tests and builds into jobs that run at the same time. Split long test suites into parts.
• Build only what changed: path filters, monorepo tools, and finding which services changed.
• Faster runners: bigger or self-hosted machines with ready caches.
• Skip what is not needed: do not rebuild for docs-only changes. Reuse the artifact across environments.
• Faster deploys: pull smaller images, tune the health checks and rolling-update settings, and keep images already pulled on nodes.

Report the numbers before and after. This shows that you worked step by step.

What they are checking: Whether you measure first and know caching, parallel jobs and builds that run only for changes.

Plan rollback before releasing.

Rollback:

• Keep the previous artifacts: image tags by SHA, Helm revisions, ECS task definition revisions.
• Kubernetes: kubectl rollout undo deployment/app or helm rollback app 12. GitOps: revert the commit. Blue/green: switch traffic back.
• Automate it with health checks and alarms that start the rollback.

Tracking releases: use version tags, release notes, deployment events in the pipeline, and a deploy marker on dashboards. Then an incident can be linked to a change.

Database migrations:

• Use migration tools that keep versions (Flyway, Liquibase, Alembic).
• Follow expand and contract. First add columns or tables in a way that works with old code. Then deploy the code. Remove the old structures in a later release.
• Take a backup or snapshot before risky migrations. Do not ship changes that delete data in the same release as the code.
• Move forward with a fix when a rollback would lose data.

What they are checking: Whether you can roll back safely and know that database schema changes are the hard part.

Make things stable first. Investigate second.

Immediate:

1. Roll back to the last good version (redeploy the previous artifact, run helm rollback, or switch the blue-green router). Do not debug live while users are getting errors.
2. Tell people the status and keep a timeline.

Unstable tests (tests that fail sometimes and pass other times) destroy trust in the pipeline. Treat them as bugs, not noise.

Assume it is stolen the moment it appears, and act in this order:

Start with what Argo CD itself says.

Use the expand and contract method. In rolling, blue-green or canary releases, both versions use the same database.

Give each service its own Dockerfile and pipeline job. Start a job only when its files change.

Servers that run workloads should be in private subnets. Only load balancers and entry points like a bastion are public. Pipelines reach the servers without opening SSH to the whole world.

A queue means there are more jobs than executors, or builds cannot find a matching agent.

Automate it with metric analysis, so nobody has to watch the dashboard.