Certified GitOps Associate (CGOA, CNCF/Linux Foundation) (CGOA) (CGOA) — Questions 76–150

Pruning removes resources from the cluster that are no longer defined in the source Git repository, ensuring the cluster only contains what is declared.

A complete GitOps pipeline requires a Git repository for state, a CI process for artifact creation, and a CD operator for reconciliation.

OPA (Gatekeeper) and Kyverno are the two industry-standard policy engines for Kubernetes.

GitOps is based on the system state being explicitly declared in a version control system and then continuously reconciled by an automated operator.

The 'Hub-and-Spoke' pattern with local agents (like Argo CD ApplicationSets or Flux controllers on each cluster) prevents a single central controller from having to manage thousands of API connections.

Flux and Argo CD are both popular examples of pull-based GitOps operators.

OpenGitOps principles state that desired state must be expressed declaratively, stored in a system that enforces versioning and immutability (like Git), and serve as the single source of truth.

In a pull-based model, the agent/controller running inside the cluster actively polls the Git repository.

The self-healing and automated sync policies, combined with directory recursion, allow the App-of-Apps pattern to maintain state automatically.

Using directories or separate repos are the standard patterns.

Common pitfalls include failing to secure credentials and relying on imperative patterns, such as manual cluster edits.

IaC allows infrastructure to be treated with the same rigor as application code, enabling versioning, testing, and automated reconciliation.

Mozilla SOPS is the standard tool for encrypting sensitive values within manifest files (like YAML) before they are committed to Git.

Phased rollouts and cluster grouping ensure that if a deployment fails, it is contained to a specific set of clusters rather than the entire fleet.

Advanced patterns include using ApplicationSets for dynamic generation, using Git submodules or monorepos for structure, and implementing policy-driven deployments.

The controller pulls the desired state from Git, which is more secure than pushing secrets out to the cluster.

The Source of Truth (typically a Git repository) holds the desired state of the entire system, ensuring that all cluster changes are versioned, audited, and reproducible.

When drift occurs, the controller flags the resource as 'OutOfSync', alerts the relevant teams, and optionally applies the correction to restore the desired state.

In GitOps, all changes—including rollbacks—are executed by interacting with Git. Reverting the Git commit to a previous known-good state causes the GitOps controllers across all 50 clusters to reconcile to that restored desired state, maintaining a complete audit trail.

Effective GitOps uses tools like Helm, Kustomize, or directory separation to manage environmental differences without code duplication.

ArgoCD supports 'Helm parameters' or 'Kustomize vars', but specifically for dynamic external values, the 'argocd-vault-plugin' or similar sidecar approaches are common, but using 'Application parameters' is the core supported way to override Helm values.

The controller detects the commit and immediately triggers a sync to update the cluster.

The developer updates the manifest (e.g., image tag) in the Git repository and merges it, triggering the GitOps operator to update the cluster.

The 'flux get kustomizations' command provides a summary including the status and any error messages.

Imperative scripts define 'how' to achieve a state through a sequence of steps, rather than expressing 'what' the target system should look like (declarative). Declarative state relies on static configuration documents (like YAML manifests) that express target end-states.

Using a base directory with common configurations and multiple overlay directories allows you to trigger updates across the entire hierarchy.

The 'syncPolicy.syncOptions' field, specifically 'ApplyOutOfSyncOnly=true' or using 'wave' annotations, manages deployment ordering. However, standard Argo CD 'syncWaves' are the primary mechanism for ordering resources within an app.

Using a tool like Crossplane or an orchestrator ensures that infrastructure and applications are synchronized through the same Git-based reconciliation loop.

Git provides a cryptographically signed, timestamped, and versioned history of all changes, which is ideal for auditing.

Automating image updates through a tool like Renovate or Argo CD Image Updater ensures the repository is kept in sync with the latest build artifacts.

The process involves detecting changes, fetching manifests, and applying them.

Pull models require an agent to be installed in the cluster, which adds complexity to the management of that agent.

Drift occurs when the cluster state deviates from the version-controlled Git state.

Validating admission webhooks (which Gatekeeper uses) enforce policies regardless of the source of the change, whether manual or GitOps.

IaC and automated policy gates are essential to manage infrastructure safely and securely.

Version control provides a clear audit trail of who changed what, and enables easy restoration to a previous known-good state.

The pipeline handles the CI (build/test/publish) process, while the controller handles the CD (pull/reconcile) process.

A GitOps repository contains the declarative definitions of the infrastructure (Kubernetes manifests) and the configuration required to manage them.

The 'spec.source.helm.values' field allows for either direct YAML values or a reference to a values file within the repository.

Drift occurs when the runtime state deviates from the Git-stored state.

Argo CD will report an 'Invalid' state because it cannot resolve the target revision specified in the manifest.

The Git repository holds the declarative state that the cluster must match.

Environment-specific values files (e.g., values-prod.yaml) are typically stored in the Git repository alongside the chart or in a separate environment-specific folder, allowing for clear separation of concerns.

Pull-based systems don't require the CI system to have credentials for the cluster, improving security and enabling autonomous reconciliation.

Declarative means describing the 'what' (the final state) rather than the 'how' (the steps to achieve it).

Separating the source code from the environment configuration allows for independent lifecycle management and improved security scoping.

ArgoCD core consists of the API server, the Repo Server, and the Application Controller.

Rewriting Git history invalidates the audit log and can cause synchronization issues or unexpected behaviors across distributed reconcilers that rely on immutable commit SHAs. In GitOps, secrets should be removed properly (e.g., using secret management tools like Sealed Secrets or SOPS) and rotated immediately rather than altering historical commits.

Pull-based systems are more secure as they don't require external entities to have write access to the cluster's internal credentials.

The App-of-Apps pattern simplifies management by providing a single point of visibility, enabling bulk operations, and allowing for hierarchical organization of applications.

GitOps improves auditability through Git logs and reduces the risk of manual configuration errors.

Key considerations include support for multi-cluster environments, secret management capabilities, and how well it integrates with existing CI tools.

Infrastructure as Code focuses on the underlying environment (VMs, networks), while Configuration as Code focuses on the software services and their settings.

External Secrets Operator or HashiCorp Vault integration fetches secrets from a secure, external source and injects them into the cluster, so they are never in the Git repo.

The Image Reflector Controller scans container registries and reflects image metadata into the cluster as ImageRepository objects.

GitOps relies on reconciliation. Pre-deployment tasks should be managed via Kubernetes Jobs or hooks that maintain the declarative nature of the cluster state.

Suspending a Kustomization or HelmRelease in Flux stops the reconciliation process, meaning the controller will no longer apply changes from Git to the cluster.

Helm charts allow packaging complex applications into a single templateable format, which is easier to version and manage than hundreds of individual YAML files.

If the analysis template fails despite metrics being valid, the culprit is often an incorrectly configured 'provider' field pointing to the wrong Prometheus endpoint or incorrect authentication credentials within the secret referenced by the analysis run.

The loop calculates the difference between current and desired state and applies actions to minimize that difference.

Hooks allow execution of pre/post-sync logic, such as database migrations or notifications, as part of the sync process.

Using 'latest' makes the deployment non-deterministic because the image associated with the tag can change, making it impossible to know exactly what is running in the cluster.

Making manual changes via kubectl and committing secrets in plain text are significant security and operational anti-patterns.

Rolling back involves reverting the commit in Git, which the operator then detects and reconciles to return the cluster to the previous working state.

GitOps repositories should focus on declarative config, not binary build artifacts, secrets, or transient runtime information.

If a developer manually modifies a resource using kubectl, they are bypassing the Git source of truth, which is the definition of a GitOps violation.

The namespace defines the logical boundary within the cluster where the resources should be deployed.

A loop often occurs when the GitOps operator updates the cluster, and that update triggers a process that then modifies the Git repository, creating a feedback cycle.

The controller (or operator) is the brain of the GitOps platform that manages the lifecycle of the infrastructure.

In an App-of-Apps pattern, if the parent application has 'self-heal' or 'prune' enabled, it may conflict with child applications if the sync policy is misconfigured, often caused by circular dependencies or the parent attempting to manage its own child resources.

Drift detection relies on comparing the live state against the repository state and alerting on discrepancies.

Git provides history, auditability, and collaboration features.

Using specific image tags (e.g., SHA-based, not 'latest') ensures that the deployment remains deterministic and immutable.

A GitOps platform consists of a Git repo, an operator, and a target infrastructure.

Operators run inside the cluster and act autonomously.