A platform engineer explains GitOps to a team adopting Kubernetes: "GitOps means Git is your single source of truth for everything — application configs, Kubernetes manifests, Helm chart values, infrastructure definitions. You never apply changes directly to the cluster. Every change is a Git commit. An operator running in the cluster — ArgoCD in our case — continuously watches the Git repo. When it detects a difference between what Git says should exist and what actually exists in the cluster, it reconciles: it brings the cluster to match Git. Humans push to Git; the operator pushes to the cluster." What is the reconciliation loop in GitOps?
Reconciliation loop: the heart of GitOps. The operator (ArgoCD, Flux) runs an infinite control loop: (1) Read desired state from Git, (2) Read observed state from the cluster via Kubernetes API, (3) Compare — compute the diff, (4) If different, apply changes to make observed = desired. This runs on a configurable interval (e.g., every 3 minutes) and also on Git push events via webhooks. GitOps principles (from Weaveworks, who coined the term): Declarative: describe what you want, not how to get there (Kubernetes YAML, Helm charts, Kustomize). Versioned and immutable: all desired state in Git with full history. Pulled automatically: the operator pulls from Git (not push-based CI) — the cluster initiates the connection, which is more secure for cloud environments. Continuously reconciled: the system self-heals to match desired state, correcting manual changes (drift). Key vocabulary: Desired state: what Git says should exist. Observed state: what the Kubernetes API currently shows. Drift: any difference between desired and observed. Self-healing: automatic correction of drift. In conversation: 'With GitOps, if someone kubectl-applies a hotfix directly to production, ArgoCD will revert it within minutes. The Git repo is law.'
2 / 10
A DevOps engineer explains ArgoCD to a developer unfamiliar with GitOps tooling: "ArgoCD is a declarative GitOps controller for Kubernetes. You define an Application custom resource that tells ArgoCD: watch this Git repo, at this path, for this target cluster and namespace. ArgoCD then continuously syncs. The Application has a health status — Healthy, Progressing, Degraded — and a sync status — Synced or OutOfSync. OutOfSync means Git and the cluster diverge. You can configure auto-sync to automatically apply changes, or leave it manual so a human reviews the diff and clicks sync." In ArgoCD, what does OutOfSync mean and when is it expected?
ArgoCD sync status: Synced: observed cluster state matches desired Git state. OutOfSync: a difference exists — could be a new Git commit not yet applied, a manual change made to the cluster, or a resource that drifted. Unknown: ArgoCD cannot determine the state. Health status: Healthy: all resources are running as expected. Progressing: deployment or rollout is in progress. Degraded: a pod has crash-looped or a Deployment failed to roll out. Suspended: a CronJob or similar is paused. ArgoCD Application vocabulary: Application CR: the ArgoCD custom resource defining a deployment target. App of Apps: a pattern where one ArgoCD Application manages a Git directory full of other Application CRs — enables bootstrapping an entire cluster from a single sync. Sync policy: automated = ArgoCD auto-applies on OutOfSync. Manual = human triggers sync. Sync waves: ordering mechanism — resources with lower wave numbers sync first (e.g., CRDs before operators, namespaces before deployments). Sync options: CreateNamespace=true (create ns if missing), PruneLast=true (delete old resources after creating new), Replace=true (force replace instead of patch). Resource hooks: PreSync, Sync, PostSync Jobs run at specified phases. In conversation: 'We use manual sync for production and auto-sync for dev/staging. Anything going to prod requires a human to review the diff in ArgoCD before clicking sync.'
3 / 10
A senior engineer explains why they chose Flux over ArgoCD at architecture review: "Flux is a CNCF graduated project — it's GitOps for Kubernetes implemented as a set of controllers. Each controller is a focused CRD: GitRepository watches a Git repo, Kustomization applies manifests, HelmRelease manages Helm chart deployments. The image automation controllers watch container registries and can automatically update image tags in Git when new images are pushed. We liked Flux's composability and the fact that all state lives in the cluster as CRDs — there's no separate Flux UI state, it's pure Kubernetes." What is a HelmRelease in Flux and why is it more GitOps-native than running Helm directly?
Flux HelmRelease: a Custom Resource that declaratively describes a Helm chart release — the chart source (HelmRepository, GitRepository, or OCI), version constraint, and values. The Helm controller continuously reconciles it, meaning: if someone runs helm upgrade directly and changes values, Flux will revert them on the next reconciliation cycle. This enforces GitOps: Helm charts are no longer deployed imperatively by CI pipelines. Flux CRDs: GitRepository: defines a Git source (URL, branch, credentials, interval). OCIRepository: pulls from an OCI (container) registry — e.g., Helm charts stored in ECR or GHCR. HelmRepository: points to a Helm chart repository. Kustomization: applies a kustomize directory from a GitRepository source, with health assessment and dependency ordering. HelmRelease: manages a Helm chart release with reconciliation. ImageRepository: watches a container registry for new image tags. ImagePolicy: defines tag selection policy (semver, alphabetical). ImageUpdateAutomation: automatically commits updated image tags to Git when new images match a policy. Flux vs ArgoCD: both implement GitOps for Kubernetes. Flux: CRD-native, composable controllers, better image automation. ArgoCD: richer UI, App of Apps pattern, sync waves, RBAC built-in. Both are CNCF graduated. In conversation: 'With Flux image automation, pushing a new image to ECR automatically opens a PR updating the image tag in our config repo. Humans review and merge; Flux deploys.'
4 / 10
An SRE explains a GitOps incident to the postmortem meeting: "Someone made an emergency hotfix directly in the cluster — kubectl edited the Deployment to bump the image tag. ArgoCD detected drift within three minutes and auto-synced, reverting the hotfix. The fix disappeared silently. In hindsight, the right process was: commit the fix to the Git repo, push, let ArgoCD sync. For true emergencies we have a 'break-glass' procedure: pause ArgoCD sync on that Application, apply manually, then immediately commit to Git and re-enable sync. This preserves the audit trail." What is drift in a GitOps context and why is it problematic?
Drift in GitOps: any difference between what Git declares (desired state) and what exists in the cluster (observed state). Sources of drift: Manual kubectl changes: the most common. Someone edits a Deployment, ConfigMap, or Secret directly. Cluster autoscaler or VPA changes: the platform modifies resource requests automatically. Admission webhooks: mutating webhooks inject or modify fields that aren't in the Git manifest. Operators: Kubernetes operators may update resources they manage, which might conflict with GitOps-managed manifests. In-place secret rotation: external secrets operators update secrets from vaults. Why problematic: in a GitOps model, the cluster should be fully reproducible from Git. If someone makes a kubectl change without committing to Git, that knowledge lives only in the cluster. If the cluster is rebuilt or ArgoCD auto-syncs, the change is lost. The team has no audit trail of who made the change or why. Break-glass procedures: formal process for emergency cluster changes outside normal GitOps flow. Best practice: (1) Pause GitOps reconciliation for the affected resource, (2) Apply emergency fix, (3) Immediately commit the same change to Git, (4) Re-enable reconciliation. All break-glass events should be logged and followed up in postmortem. In conversation: 'Drift is an organizational risk, not just a technical one. It means your Git repo no longer describes your production system — that's a knowledge problem as much as a tooling problem.'
5 / 10
A platform team lead presents their GitOps repository structure: "We use a mono-repo for all cluster configuration. The structure follows the environment-per-directory pattern: clusters/dev/, clusters/staging/, clusters/production/. Each directory has its own ArgoCD Application pointing to it. We use Kustomize for environment-specific overrides — base/ has the shared manifests, overlays/dev/ patches resource limits down and disables PodDisruptionBudgets, overlays/production/ bumps replicas and enables HPA. This way we have one set of base manifests and environment-specific differences tracked in Git." What is Kustomize and how does it support multi-environment GitOps?
Kustomize: built into kubectl (since 1.14) and all GitOps tools. Philosophy: plain YAML everywhere, no templating language. Instead of Go templates (Helm), Kustomize uses patches applied on top of base manifests. Structure: base/: common manifests (Deployment, Service, ConfigMap) valid for all environments. overlays/dev/: kustomization.yaml that references base and applies patches (reduce replicas, lower resource limits). overlays/production/: different patches (increase replicas, add HPA, enable PodDisruptionBudget). Kustomize features: namePrefix/nameSuffix: add environment prefix to all resource names. commonLabels/commonAnnotations: add labels across all resources. images: override image tags without editing manifests. configMapGenerator/secretGenerator: auto-generate ConfigMaps/Secrets with content hash appended to name (triggers rolling update on change). patches: strategic merge patches or JSON6902 patches for fine-grained overrides. Helm vs Kustomize: Helm uses Go templates and values.yaml (more complex, better for distributable charts). Kustomize uses overlays (simpler, better for managing your own apps across environments). GitOps repo patterns: Mono-repo: all environments in one repo. Poly-repo: separate repos per team or environment. Config repo separate from app repo: CI builds images, writes image tag to config repo, GitOps syncs config repo. In conversation: 'With Kustomize, dev and prod manifests share 90% of their YAML. The overlay only contains the diffs. That's much easier to audit than separate manifest copies per environment.'
6 / 10
During a Slack discussion with the front-end team, Sarah (a Developer) mentions 'pulling' changes to the Kubernetes cluster. Mark (a DevOps Engineer), familiar with GitOps, replies: 'Actually, we don't *pull* directly. ArgoCD continuously monitors our Git repository for changes and automatically applies them to the cluster. Think of it like a constant synchronization – whenever you push a commit to the repo, ArgoCD immediately updates the cluster.' What does Mark primarily describe in his response?
Mark is explaining the core concept of continuous synchronization – the automated nature of ArgoCD's operation. The key phrase 'continuously monitors our Git repository' highlights how changes are triggered and applied automatically based on Git commits. Options A, C, and D misrepresent the fundamental workflow of a GitOps system.
7 / 10
You're reviewing a PR from Alex (a developer) that describes deploying a new version of a microservice. The PR includes a comment: 'I've updated the Helm chart values and committed them to Git. ArgoCD should handle the rest.' What does Alex's statement indicate about their approach to deployment within a GitOps environment?
Alex's statement demonstrates an understanding of declarative configuration management. By saying 'ArgoCD should handle the rest,' they acknowledge that ArgoCD will automatically synchronize the changes defined in the Helm chart values from the Git repository to the Kubernetes cluster. Option A is incorrect because it describes a deviation from GitOps principles.
8 / 10
During a stand-up meeting, David (an SRE) explains that their team uses Flux CD. He says: 'We've configured Flux to watch our Git repository and automatically update the Kubernetes manifests whenever we push changes. It's like having a constant observer ensuring everything stays in sync.' What is David highlighting about Flux CD's core functionality?
David's statement accurately describes Flux CD's continuous monitoring and automatic update functionality – its core purpose in a GitOps environment. The 'constant observer' analogy effectively conveys this automated synchronization process. Options A, C, and D are incorrect descriptions of Flux CD's capabilities.
9 / 10
You receive an email from the Release Manager, Emily: 'We've detected a configuration drift in our production environment. ArgoCD is automatically reconciling it back to the latest state defined in Git.' What does 'configuration drift' specifically refer to in this context?
'Configuration drift' describes the situation where the actual state of the Kubernetes cluster diverges from the desired state defined in Git. This is a critical concept in GitOps – the continuous monitoring and reconciliation process aims to eliminate this divergence. Option A is incorrect as it describes a deliberate change; option C is misinterpreting ArgoCD's actions, and D relates to network issues.
10 / 10
In a code review comment on a PR that introduces a new feature using GitOps, Liam (a Senior Developer) writes: 'This looks good! Just double-checking – are we sure ArgoCD is correctly configured to watch this particular branch and namespace?' What aspect of GitOps is Liam primarily questioning?
Liam's comment focuses on the critical configuration aspect – ensuring ArgoCD correctly monitors the specified Git branch and namespace for changes. This is fundamental to the GitOps workflow; incorrect configuration leads to synchronization failures and 'drift.' Options A, B, and D address broader concerns rather than the core synchronization process.
What does the "GitOps Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to gitops vocabulary through 10 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 1 other vocabulary module. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.