5.1 - CI/CD and continuous integration
Cloud+ CV0-004 objective 5.1 covers CI/CD pipelines. Continuous integration (CI) automatically builds and tests code on every commit to catch problems early, while the changes are small and easy to fix. Continuous delivery keeps every passing build ready to release with a manual approval, whereas continuous deployment automatically pushes every passing build all the way to production with no manual gate. In trunk-based development, developers mainly commit to one main branch in small, frequent changes rather than maintaining long-lived feature branches; merging back frequently mainly reduces painful merge conflicts. You should also know pipelines, stages, automated testing and artifacts. Expect scenario questions that describe building and testing on each commit, auto-releasing to production, or a branching strategy, and ask which practice - continuous integration, continuous deployment or trunk-based development - is being described.
Build + test on every commit = continuous integration. Auto-push every passing build to prod (no gate) = continuous deployment (with a manual gate = continuous delivery). Commit to one main branch, small + often = trunk-based (fewer merge conflicts).
Practice questions
1. Automatically building and testing code on every commit to catch problems early is:
- Continuous integration (correct answer)
- Continuous monitoring
- Configuration drift
- Manual release
Continuous integration (CI) merges and automatically builds/tests changes frequently, catching defects early. Continuous delivery/deployment then automates release.
2. Developers commit small changes straight to one shared main branch many times a day. This model is:
- Trunk-based development (correct answer)
- GitFlow branching model
- Forking-based workflow
- Release-branch strategy
Trunk-based development keeps one short-lived main line with frequent small merges, easing continuous integration. GitFlow instead uses long-lived develop and release branches.
3. Automatically pushing every passing build all the way to production without a manual gate is:
- Continuous integration
- Continuous deployment (correct answer)
- Continuous monitoring
- Continuous backup
Continuous deployment releases every change that passes automated tests straight to production. Continuous delivery stops at a ready-to-release artifact needing a manual approval.
4. Merging a feature branch back to the main line frequently in small changes mainly reduces:
- Test coverage
- Merge conflicts (correct answer)
- Commit history
- Build speed
Frequent small merges keep branches close to main, so conflicts stay small and rare, a core CI practice. Long-lived branches drift and create painful merges.
5. Keeping short-lived branches merged to main behind hidden feature flags is a form of:
- A big-bang batch release
- Config drift
- Trunk-based development (correct answer)
- Manual approval gating
Trunk-based development keeps everyone integrating into main frequently, hiding unfinished work behind feature flags to avoid long branches. This supports continuous integration.
6. In a CI/CD pipeline, which stage typically runs right after the build stage?
- Provision hardware
- Archive to tape
- Automated testing (correct answer)
- Rotate keys
After build, the pipeline runs automated tests to validate the artifact before packaging and deploy. Key rotation and tape archiving are not standard pipeline stages.