CI/CD Interview Questions & Answers

GitLab looks for one specific file at the root of your repo, .gitlab-ci.yml, and that's what tells its Runners which jobs and stages to execute. Other names like pipeline.yml or gitlab.yml simply won't be recognized.

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.

If your test suite has jobs that don't depend on each other, like linting and unit tests, there's no reason to make them wait in line. Pipeline parallelization runs those independent jobs on multiple runners at the same time, so the whole pipeline finishes in the time of the slowest single job instead of the sum of all of them.

Jenkins is an open-source tool built specifically to automate building, testing, and deploying code, which is what CI/CD is all about, unlike general-purpose office software like Photoshop, Excel, or Word.

Anything committed to a repo, even in a .env file, becomes part of its history forever and is visible to anyone with access. GitHub Repository Secrets keep values encrypted and only inject them into the workflow at runtime via ${{ secrets.MY_KEY }}, so the actual value never has to live in your code at all.

GitOps means your Git repository is the one true record of what your infrastructure and apps should look like, and an automated controller constantly checks the real system against Git and fixes any difference. It's a workflow philosophy, not just a place to host code or a single deployment script.

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 staging environment exists to catch problems before real users ever see them, by being set up as close to production as possible (same infrastructure, similar config) so what you test there is actually representative of what will happen in production.

Both practices get your code to a release-ready state automatically, the difference is what happens next: Continuous Delivery stops and waits for a person to say 'go' before releasing, while Continuous Deployment skips that step and pushes straight to production on its own.

Pipeline as code means the pipeline definition itself, such as a .gitlab-ci.yml, Jenkinsfile, or GitHub Actions workflow file, lives in a version-controlled file rather than being configured by clicking through a UI. This gives the pipeline the same benefits as application code: change history, review via pull requests, and easy rollback of pipeline changes. It has nothing to do with the pipeline writing application source code, and it doesn't restrict how the pipeline can be triggered.