CGOA common mistakes
CGOA · Understand the traps and how to avoid them.
Treating 'GitOps' as a synonym for 'anything configured in Git', so answers accept manual kubectl edits that are later committed as GitOps.
Candidates conflate version control as a backup/audit trail with the declarative, continuously reconciled model; the exam deliberately offers 'commit after the fact' as a distractor.
What to do instead
Apply the four-principle test to every scenario: declarative desired state, versioned and immutable, pulled automatically by an agent, continuously reconciled. If a human pushes changes to the cluster, it is not GitOps even if Git records it afterwards.
Confusing reconciliation with deployment: stating that the agent applies changes once after a commit rather than continuously converging drift back to the declared state.
CI-driven push pipelines feel familiar, so candidates describe a single apply step and miss the closed control loop that also reverts out-of-band changes.
What to do instead
Describe the loop explicitly: agent observes actual state, compares to desired state in Git, and acts on any difference, including drift introduced by a human, not only on new commits.
Mixing up the roles of the Git repository, the reconciler/agent, and the cluster, e.g. saying the cluster pulls from Git or that Git pushes to the cluster.
Terminology questions swap subject and object; candidates answer from pipeline intuition where a server pushes to a target.
What to do instead
Fix the actor in memory: the in-cluster agent pulls (polls or is webhook-notified), the repository is passive storage, and the cluster is the target of reconciliation. Re-read each option asking 'who performs the action?'
Using 'source of truth', 'desired state', 'declared state', and 'actual/live state' interchangeably in scenario answers.
Everyday usage blurs these, but exam items hinge on which one Git holds versus which one the cluster reports.
What to do instead
Memorise the mapping: Git holds desired/declared state (source of truth); the cluster holds observed/actual state; reconciliation drives actual toward desired. Label both states in every scenario before choosing.
Ignoring environment promotion and segregation patterns and answering that all environments should share one branch and one path.
Simple single-branch layouts are easy to picture, so candidates default to them without considering blast radius, promotion gates, or per-environment credentials.
What to do instead
Know the common patterns: directory-per-environment, branch-per-environment, repository-per-environment, and app-of-apps or umbrella composition. Match the pattern to stated constraints such as isolation, audit, and promotion flow.
Describing secrets management as storing plaintext secrets in Git and relying on repository access control.
Candidates know secrets must be versioned alongside config and jump to committing them directly, forgetting that Git history is effectively permanent.
What to do instead
Use sealed or encrypted secrets, external secret stores referenced from Git, or SOPS-style encryption with cluster-side decryption. State that the Git repo holds references or ciphertext, never plaintext, and that rotation must not require rewriting history.
Treating GitOps as replacing CI: claiming the reconciler builds images, runs tests, or promotes artefacts.
The overlap between CI and CD leads candidates to merge them, but the exam separates build/test from state reconciliation.
What to do instead
Keep the boundary crisp: CI builds, tests, and pushes immutable artefacts and updates the desired-state reference (e.g. an image tag or digest); the GitOps agent only reconciles declared state. Promotion is a change to Git, not a rebuild.
Overlooking drift detection and observability: answering that a successful sync means the system is healthy, with no alerting on out-of-sync or degraded resources.
Candidates equate 'applied without error' with 'operating correctly' and forget reconciliation status is itself a signal to monitor.
What to do instead
Name the signals: sync status, health status, last reconciliation time, and drift events, surfaced as metrics and alerts. Treat out-of-sync or degraded conditions as actionable, not cosmetic.
Assuming any tool with a Git integration is a GitOps tool, e.g. selecting a push-based CI runner or a plain manifest linter as the reconciler.
Vendor marketing and surface similarity make push pipelines look equivalent; candidates skip the pull-and-reconcile criterion.
What to do instead
Evaluate tools against the principles: does an agent in or near the cluster pull desired state and continuously reconcile? Know the landscape by category (reconcilers such as Argo CD or Flux, plus policy, secrets, and progressive-delivery companions) and reject tools that only push on commit.
Answering multi-tenant or production-safety questions with a single shared agent holding cluster-admin credentials and no scoping.
Lab setups use one broad-privilege agent, so candidates carry that habit into exam scenarios about isolation and least privilege.
What to do instead
Scope agents per cluster or tenant, restrict what each can read and write in Git and in the cluster, and separate credentials per environment. Mention impersonation, namespace scoping, and policy enforcement as the controls that make multi-tenancy safe.