The Words the Exam Uses — and Where the CI/CD Boundary Moved

In one line

CGOA has no hands-on exam, so it tests whether you use the words precisely. Desired state, actual (live) state, drift, reconciliation, and convergence are not interchangeable words; they are five different positions in a single loop.

Why this was needed

In day-to-day work, phrases like "I ran a sync" or "it doesn't match" are enough for a conversation. But exam questions ask things like "Which of the following best describes drift?", and three of the four choices sound plausible. Words such as Deviation, Delta, and Divergence are laid out as wrong answers. If you know the definitions only loosely, you will get it wrong.

How it works

Following one lap in order looks like this.

Desired state — the target the system must reach, declared in Git. It includes the rendered result. A Helm chart or a kustomize overlay is "the material that generates the desired state," and the desired state itself is the final manifest that results from rendering it.
Actual state / Live state — the objects the cluster API server is holding right now.
Drift — the difference between the two. It arises when someone ran kubectl edit, a controller changed a field, or an earlier sync failed partway.
Reconciliation — the act of finding the difference and pushing the actual state toward the desired state.
Convergence — the state in which the two have become identical as a result. It may not happen in one pass, and when the two eventually become identical after several loops, that is called eventual consistency.

Two more words go with these. The state store is the version control system that holds the desired state (usually Git), and the software agent is the in-cluster process that performs reconciliation (Argo CD, Flux). The reason the OpenGitOps documents use these two words instead of tool names is to make clear that GitOps is not a concept tied to a specific product.

Where did the line between CI and CD go?

In traditional CI/CD, the boundary was "the point where testing ends." In GitOps the boundary moves to between repositories.

[앱 저장소]  코드 커밋 → 빌드 → 테스트 → 이미지 푸시 → (설정 저장소에 태그 커밋)
                                                          |
                                                          | ← 여기가 CI 의 끝
                                                          |
[설정 저장소]  PR 리뷰 → 머지 → (에이전트가 당겨감) → 클러스터
                                  ↑ 여기부터가 CD

The output of CI is no longer a "deployment" but a commit. CD is not a job a person triggers but a loop that is always running. That is why in GitOps a "deployment failure" and a "sync failure" are different events, and a rollback is done with git revert rather than by re-running the pipeline. Because a revert does not erase history but stacks a new commit, it also fits the immutability principle.

One trap that comes up often: a webhook is not required. Even without a webhook, the agent checks Git at every polling interval, so it converges eventually. A webhook is only an optimization that shortens that delay, and the claim that "without a webhook it is not GitOps" is wrong.

What it looks like in the field

One scene the author actually went through in the homelab. When KubeVirt was installed, every component's status was AllComponentsReady, yet the VM would not start. When the virt-launcher Pod spec was examined, the volume mount for the binaries the init container would use was missing. The record says this was the third time this kind of incident had been experienced on the same cluster.

What does this have to do with the terminology? Because Sync status and Health status are different axes. Argo CD also shows Synced (the desired state and the actual objects are the same) and Healthy (that object is really doing its job) separately. An app that is Synced but Degraded is common. It happens when Git's instructions were carried out exactly, but the spec itself was wrong. If the exam asks "Can an app be OutOfSync yet Healthy?", the answer is yes. The two axes are independent.

What to check in the next quiz

The next module sets up the repository structure. "Which directory, and in what shape, do you put the desired state" is itself the repository strategy, and environment promotion comes down to a PR that moves one line, the image tag, on top of that structure.