Question 1

What is CI/CD?

Accepted Answer

CI stands for Continuous Integration, where code changes are merged frequently and validated with automated checks such as builds and tests. CD usually refers to Continuous Delivery or Continuous Deployment, where software is prepared for release or automatically released after passing validations.

In a strong interview answer, you should explain the outcome, not just the acronym. CI/CD reduces manual release effort, shortens feedback loops, improves consistency, and helps teams deliver software more safely and frequently.

Question 2

What are common stages in a CI/CD pipeline?

Accepted Answer

Typical stages include source checkout, dependency installation, linting, unit testing, build or package creation, security scanning, artifact publishing, deployment, and post-deployment verification.

The exact stages depend on the system, but the principle is the same: move from fast, cheap validation to slower, higher-confidence checks. Well-designed pipelines catch issues early while still enforcing enough quality before production.

Question 3

What is the difference between continuous delivery and continuous deployment?

Accepted Answer

Continuous delivery means the software is always in a deployable state, but release to production may still require a manual approval. Continuous deployment means changes are automatically released once all pipeline checks pass.

The distinction matters because many teams say “CD” but mean different things. Continuous deployment requires a higher level of automation, observability, testing confidence, and rollback readiness than continuous delivery.

Question 4

Why is automation important in CI/CD?

Accepted Answer

Automation reduces human error, speeds up feedback, and ensures the same process is applied consistently to every change. It also makes releases more predictable and easier to audit.

From a DevOps perspective, the real value is trust. When build, test, scan, and deploy steps are automated and repeatable, teams can ship more frequently without depending on fragile manual knowledge.

Question 5

Why do teams run tests in parallel in CI?

Accepted Answer

Parallel execution reduces total pipeline duration, which helps developers get feedback faster and keeps the delivery process moving.

This matters because slow pipelines discourage frequent commits and can create larger, riskier batches of change. A good answer also mentions tradeoffs such as test isolation, infrastructure cost, and the need to avoid flaky shared-state tests.

Question 6

What is a quality gate in a pipeline?

Accepted Answer

A quality gate is a checkpoint that must be satisfied before code can move to the next stage. Examples include passing unit tests, minimum coverage thresholds, security scans, approvals, or successful integration tests.

Quality gates are important because they turn expectations into enforceable controls. Instead of relying on “best effort,” the pipeline consistently blocks changes that do not meet team standards.

Question 7

How should secrets be handled in CI/CD pipelines?

Accepted Answer

Secrets should be stored in secure CI variable stores or external secret managers, not hardcoded in repositories or pipeline files. Access should be limited by scope, and secret values should be masked in logs.

Mature teams also rotate secrets regularly, avoid overprivileged credentials, and prefer short-lived or federated identities when possible. The goal is not just hiding secrets, but reducing exposure and limiting blast radius if something goes wrong.

Question 8

What is an artifact in a CI/CD pipeline?

Accepted Answer

An artifact is the output of a build process that can be promoted and deployed, such as a binary, container image, package, or static site bundle.

Artifacts are important because they separate build from deployment. Instead of rebuilding differently in each environment, teams create a versioned artifact once and deploy that same tested artifact everywhere.

Question 9

Why is artifact immutability important?

Accepted Answer

Immutability means the built artifact does not change after creation. This improves traceability, reproducibility, and rollback safety because every environment receives the same content.

Without immutability, debugging becomes harder because a “same version” deployment may not actually be the same. Interviews often reward answers that connect immutability to trust in release pipelines.

Question 10

What is the difference between blue-green and canary deployments?

Accepted Answer

Blue-green deployment uses two parallel environments, where traffic is switched from the old version to the new version when the new one is ready. Canary deployment releases the new version to a small percentage of users first and gradually increases exposure.

Blue-green is strong when you want very fast rollback and near-zero downtime. Canary is useful when you want to observe risk gradually and validate behavior under real traffic before a full rollout.

Question 11

How should rollback be designed in CI/CD?

Accepted Answer

Rollback should be fast, tested, and as automated as possible. That usually means keeping previous artifacts available, versioning configuration, and making deployment changes easy to reverse.

A strong answer also mentions that rollback strategy depends on the system. Some changes, such as database migrations, are not trivially reversible, so safe delivery may require backward compatibility, expand-contract patterns, or feature flags.

Question 12

What makes a CI/CD pipeline reliable instead of just fast?

Accepted Answer

A reliable pipeline has stable tests, reproducible builds, clear failure signals, secure secret handling, good visibility into results, and deterministic deployment behavior.

Fast pipelines are valuable, but speed alone can be misleading if they are flaky or easy to bypass. Strong DevOps practice balances speed with confidence.

Question 13

How do feature flags complement CI/CD?

Accepted Answer

Feature flags let teams decouple code deployment from feature release. Code can be deployed safely while functionality is enabled gradually, tested with internal users, or disabled quickly if issues appear.

This improves release control and reduces risk, especially in continuous deployment environments. It also helps when a full rollback is undesirable or expensive.

Question 14

How would you troubleshoot a failing pipeline that started breaking after a recent change?

Accepted Answer

I would first identify the first failing stage, compare recent commits, and determine whether the issue is in application code, pipeline configuration, dependencies, environment changes, or external services. Then I would reproduce the issue locally or in a test branch if possible.

Good pipeline troubleshooting is systematic. The key is to isolate whether the failure is deterministic or flaky, whether it affects all branches or one workflow, and whether the root cause is the code being built or the automation around it.

Question 15

What is the purpose of linting in a CI pipeline?

Accepted Answer

Linting checks code style, common mistakes, and rule violations before deeper testing or deployment steps run.

It is useful because it provides fast feedback and catches issues early. In well-designed pipelines, linting acts as a quick, inexpensive quality gate before heavier stages begin.

Question 16

Why are unit tests and integration tests both important in CI/CD?

Accepted Answer

Unit tests validate small pieces of logic in isolation, while integration tests verify how components work together.

Both matter because passing unit tests alone does not guarantee the full system behaves correctly. Strong pipelines use a layered approach to confidence instead of relying on only one test type.

Question 17

What is a deployment promotion model?

Accepted Answer

A promotion model is the process of moving the same built artifact through environments such as dev, staging, and production.

The key benefit is consistency. Instead of rebuilding differently in each environment, teams promote the same tested artifact, which reduces ambiguity and makes failures easier to reason about.

Question 18

Why should pipelines be version controlled?

Accepted Answer

Pipeline definitions should live in version control so changes can be reviewed, tracked, and rolled back like application code.

This is important because pipeline logic directly affects delivery and security. Treating CI/CD config as code supports auditability and safer collaboration.

Question 19

What makes a pipeline flaky?

Accepted Answer

A flaky pipeline fails inconsistently without a real code change, often due to timing issues, external dependencies, poor test isolation, or unstable environments.

Flakiness is dangerous because it erodes trust in automation. Teams start ignoring failures or rerunning jobs blindly, which reduces the value of CI/CD as a quality signal.

Question 20

How do you reduce flaky tests in CI?

Accepted Answer

I would isolate shared state, remove timing assumptions, stabilize test data, mock unreliable dependencies appropriately, and make environments consistent.

It is also important to track flaky tests explicitly rather than normalizing them. Reliable pipelines depend on reliable tests.

Question 21

What is a pipeline cache?

Accepted Answer

A pipeline cache stores reusable dependencies or build outputs between runs to speed up future executions.

Caching can improve performance significantly, but it must be designed carefully. Incorrect cache keys or stale dependencies can create confusing failures or hide real issues.

Question 22

What is the difference between a cache and an artifact in CI?

Accepted Answer

A cache is usually meant to speed up repeated runs by reusing dependencies or intermediate files. An artifact is a build output or report preserved as a result of the pipeline.

This distinction matters because artifacts are often versioned and promoted, while caches are generally disposable performance optimizations.

Question 23

Why should deployment jobs be gated differently from test jobs?

Accepted Answer

Deployment jobs carry a much larger blast radius than test jobs, so they often require stricter controls such as approvals, protected branches, environment-specific permissions, or tighter secret scopes.

A strong answer shows that not every pipeline stage should have the same trust level. Release controls should reflect risk.

Question 24

What are environment-specific variables in CI/CD?

Accepted Answer

These are configuration values that differ by environment, such as API endpoints, credentials, feature flags, or deployment targets.

They should be managed carefully so environments stay consistent without leaking secrets or embedding production-specific values into general build logic.

Question 25

Why are ephemeral test environments useful?

Accepted Answer

Ephemeral environments are temporary environments created for testing a branch, pull request, or deployment candidate.

They help teams validate changes in more realistic conditions without permanently maintaining many separate environments. This can improve confidence while keeping infrastructure cost manageable.

Question 26

What is trunk-based development, and how does it relate to CI/CD?

Accepted Answer

Trunk-based development is a workflow where developers integrate into a shared main branch frequently using small changes and short-lived branches.

It complements CI/CD because frequent integration reduces merge pain and makes automated testing and deployment more effective. Large long-lived branches often work against fast delivery.

Question 27

Why is observability important after deployment?

Accepted Answer

Observability helps teams confirm that a deployment is healthy by tracking errors, latency, traffic, logs, and other runtime signals.

CI/CD does not end at deploy. Post-deployment verification is critical because some problems appear only under real traffic or real infrastructure conditions.

Question 28

What is progressive delivery?

Accepted Answer

Progressive delivery means releasing changes gradually and controlling exposure using techniques like canaries, feature flags, percentage rollouts, or targeted user groups.

This reduces risk because teams can validate changes incrementally instead of exposing all users at once. It is especially useful in mature continuous deployment setups.

Question 29

What is the role of approvals in CI/CD?

Accepted Answer

Approvals are manual checkpoints used when a change needs human validation before moving forward, often for production deploys or sensitive environments.

They can be useful, but too many approvals can slow delivery unnecessarily. Strong teams use approvals deliberately where risk justifies them rather than as a substitute for automation.

Question 30

How do you secure supply chain steps in CI/CD?

Accepted Answer

I would control who can modify pipelines, pin dependencies, verify artifacts, protect secret access, scan images and packages, and limit runner permissions.

Supply chain security matters because attackers may target the build and release process itself. A secure pipeline protects both the software and the path by which it reaches production.

CI/CD Pipelines

1. What is CI/CD?

2. What are common stages in a CI/CD pipeline?

3. What is the difference between continuous delivery and continuous deployment?

4. Why is automation important in CI/CD?

5. Why do teams run tests in parallel in CI?

6. What is a quality gate in a pipeline?

7. How should secrets be handled in CI/CD pipelines?

8. What is an artifact in a CI/CD pipeline?

9. Why is artifact immutability important?

10. What is the difference between blue-green and canary deployments?

11. How should rollback be designed in CI/CD?

12. What makes a CI/CD pipeline reliable instead of just fast?

13. How do feature flags complement CI/CD?

14. How would you troubleshoot a failing pipeline that started breaking after a recent change?

15. What is the purpose of linting in a CI pipeline?

16. Why are unit tests and integration tests both important in CI/CD?

17. What is a deployment promotion model?

18. Why should pipelines be version controlled?

19. What makes a pipeline flaky?

20. How do you reduce flaky tests in CI?

21. What is a pipeline cache?

22. What is the difference between a cache and an artifact in CI?

23. Why should deployment jobs be gated differently from test jobs?

24. What are environment-specific variables in CI/CD?

25. Why are ephemeral test environments useful?

26. What is trunk-based development, and how does it relate to CI/CD?

27. Why is observability important after deployment?

28. What is progressive delivery?

29. What is the role of approvals in CI/CD?

30. How do you secure supply chain steps in CI/CD?