CI/CD Quiz

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.

Blue-green deployment keeps two full, identical production environments running side by side, one live (blue) and one idle with the new version (green). Switching traffic from blue to green happens instantly, so there's no downtime, and if anything goes wrong you can just switch back to blue just as fast.

Trunk-based development means everyone merges small changes into the main branch constantly instead of working for weeks on a separate feature branch. Frequent small merges are much easier to integrate cleanly than one giant merge at the end, which is exactly the conflict-heavy scenario long-lived branches create.

GitHub looks for workflow definitions in one specific spot: the .github/workflows/ folder, written as YAML files. That's different from how Jenkins (a Jenkinsfile) or GitLab (.gitlab-ci.yml) each expect their own pipeline config to live.

Running automated tests on every single change means a bug gets flagged the moment it's introduced, while it's still fresh and easy to trace, rather than being discovered days or weeks later once it's already reached production and affected real users.

A cache is only useful if it gets thrown out when the thing it's caching changes. If the cache key doesn't include a hash of the lockfile, updating the lockfile doesn't tell the cache anything changed, so CI keeps reusing the old, now-outdated dependencies instead of installing the ones the lockfile actually specifies.

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.

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.

A rolling deployment replaces instances incrementally within the same pool of servers, so it needs only a little spare capacity, or even none if done one instance at a time, rather than a whole second environment. Blue-green and shadow deployments both require standing up a full duplicate environment, which is exactly what the limited budget here rules out. Big-bang deployment offers no gradual risk reduction at all, since every instance changes at once.

By automating the repetitive parts (building, testing, releasing), CI/CD removes a lot of room for human error and shortens the time between writing code and finding out if it works, which is why teams end up shipping faster and with more confidence.