Cloud Native and CI/CD Tooling
Domain 3: Cloud Native and CI/CD Tooling
This domain tests how cloud-native principles shape delivery pipelines: small independently deployable services, declarative infrastructure, automation, and fast feedback. Expect questions on pipeline design, build once/deploy many, GitOps, and release strategies.
Core rules
- Cloud native combines containers, microservices, declarative APIs, service meshes, and immutable infrastructure to make systems resilient and observable. It is not synonymous with a particular vendor.
- CI integrates and verifies every change. CD usually means continuous delivery: the artifact is always releasable. Continuous deployment automatically releases every passing change.
- Build once, deploy many: build an immutable artifact, store it in a registry, and promote the same digest through environments. Rebuilding per environment creates drift.
- Pipelines need automated tests, security scans, artifact versioning, and fast feedback. A pipeline that only compiles is not CI.
- GitOps uses Git as the desired-state source; an agent reconciles cluster state. Declarative config and drift detection are central.
- Release strategies: rolling, blue-green, canary. Canary needs metrics and automated rollback to be meaningful.
Worked example
A team builds a new image in each environment pipeline: dev, test, prod. Production fails with a dependency version that differs from test. The root cause is rebuild-per-environment, which breaks artifact immutability. The fix: build once, tag with the commit SHA, push to a registry, and promote that digest. Environment differences move to ConfigMaps or external configuration, not new builds.
Traps
- Calling a build job "CI" when no automated tests or merge checks exist.
- Storing secrets in Git or in pipeline logs.
- Assuming continuous delivery automatically deploys to production.
- Using canary releases without observability or rollback.
- Treating GitOps as "Git plus a script" without reconciliation.