CI/CD Interview Questions & Answers

CD covers what happens after code passes CI: Continuous Delivery/Deployment automates getting that already-tested code out to staging or production quickly, rather than being about containers, distribution, or config files.

Scheduled triggers, configured with a cron expression, let a pipeline run at a fixed time regardless of whether any code changed, which is exactly what's needed for a nightly regression run. A push trigger only fires when someone commits, and a manual trigger still requires a person to start it at that hour. A pull request trigger fires only when a PR is opened or updated, not on a timer.

Removing a public function is a breaking change, since anything relying on that function will stop working, so it should have triggered a major version bump under semantic versioning rules, not a patch. Because many tools automatically pull in new patch versions, mislabeling this change means other projects could break without any warning.

Think of a pipeline as an assembly line for your code: it moves each change through a series of automated steps, like building it, testing it, and deploying it, so nothing skips a check on its way to release.

A canary deployment sends a small portion of real traffic to the new version first, so problems affect only a few users and can be caught before a full rollout. Blue-green deployment instead runs two complete environments and switches all traffic at once, rather than gradually increasing a percentage.

Since the cache key is based only on the branch name, the pipeline sees the same key as before and assumes the cached output is still valid, even though the source code underneath it changed. A cache key based on the content of the source files instead would correctly detect the change and force a fresh build.

Since the three jobs don't rely on each other's results, they can all run at the same time instead of waiting in line, which cuts the total wait time down to roughly however long the slowest one takes. Deleting test suites would speed things up too, but at the cost of losing real safety checks.

Before your code can be built or tested, all the packages it depends on need to actually be present, and npm install is the command that reads package.json and downloads exactly those packages, which is why it's the very first step in a Node.js job.

Coverage only measures which lines of code got run during testing, not whether the results were actually checked, so tests that call code without asserting anything can inflate the percentage while adding no real protection. The team ends up with a false sense of safety, since the coverage gate looks satisfied even though bugs could still pass through unnoticed.

A flaky test is one that gives inconsistent results, passing or failing seemingly at random, even though nothing in the code changed between runs. A regression test, by contrast, is simply a test meant to catch a previously fixed bug from reappearing.