This study guide is an unofficial resource created to assist candidates preparing for the Certified GitOps Associate (CGOA) exam. Originally compiled during the beta due to the limited availability of dedicated materials for the CGOA, as such it has not been endorsed by the Linux Foundation or any other official body associated with the CGOA certification.
The Certified GitOps Associate (CGOA) is a certification offered by the Linux Foundation:
The purpose of the Certified GitOps Associate (CGOA) certification is to provide assurance that CGOAs can effectively demonstrate their understanding of GitOps principles, terminology, and best practices in setting up a GitOps managed software system in addition to related practices such as Configuration of Code, Infrastructure as Code, DevOps & DevSecOps, and CI & CD and how to map them to GitOps.
More information about the certification can be found on the official exam page.
- Certified GitOps Associate (CGOA) Study Guide
Resources:
- Introduction to DevOps and Site Reliability Engineering (LFS162) - Linux Foundation Training Course (Free)
- Introduction to GitOps (LFS169) - Linux Foundation Training Course (Free)
Continuous is intended to match the industry standard term: reconciliation continues to happen, not that it must be instantaneous.
A configuration that describes the desired operating state of a system without specifying procedures for how that state will be achieved. This separates configuration (the desired state) from the implementation (commands, API calls, scripts etc.) used to achieve that state.
The aggregate of all configuration data that is sufficient to recreate the system so that instances of the system are behaviourally indistinguishable. This configuration data generally does not include persistent application data, e.g., database contents, though often does include credentials for accessing that data, or configuration for data recovery tools running on that system.
When a system's actual state has moved or is in the process of moving away from the desired state, this is often referred to as drift.
Resources:
- You Aren't Doing GitOps Without Drift Detection - Weave Works Blog
The process of ensuring the actual state of a system matches its desired state. Contrary to traditional CI/CD where automation is generally driven by pre-set triggers, in GitOps reconciliation is triggered whenever there is a divergence. Divergence could be due to the actual state unintentionally drifting from the desired state declarations, or a new desired state declaration version having been changed intentionally. Actions are taken based on policies around feedback from the system and previous reconciliation attempts, in order to reduce deviation over time.
A software system managed by GitOps includes:
- One or more runtime environments consisting of resources under management.
- The management agents within each runtime.
- Policies for controlling access and management of repositories, deployments, runtimes.
A system for storing immutable versions of desired state declarations. This state store should provide access control and auditing on the changes to the Desired State. Git, from which GitOps derives its name, is the canonical example used as this state store but any other system that meets these criteria may be used. In all cases, these state stores must be properly configured and precautions must be taken to comply with requirements set out in the GitOps Principles.
- State Store = Single Source of Truth
Open GitOps follows control-theory and operates in a closed-loop. In control theory, feedback represents how previous attempts to apply a desired state have affected the actual state. For example, if the desired state requires more resources than exist in a system, the software agent may make attempts to add resources, to automatically rollback to a previous version, or to send alerts to human operators.
Rollback is the process of reverting a system to a previous state. In GitOps, the rollback process is often automated by changing the desired state to a previous version and allowing the reconciliation process to apply that state.
git revert is an example of a rollback operation in Git.
Resources:
- Rolling Back a Deployment - Kubernetes Docs
Resources:
- OpenGitOps Documents - OpenGitOps Docs
- GitOps Principles - Harness Blog
GitOps is a set of principles for operating and managing software systems. These principles are derived from modern software operations but are also rooted in pre-existing and widely adopted best practices.
The desired state of a GitOps managed system must be:
A system managed by GitOps must have its desired state expressed declaratively.
Desired state is stored in a way that enforces immutability, versioning and retains a complete version history.
Software agents automatically pull the desired state declarations from the source.
Software agents continuously observe actual system state and attempt to apply the desired state.
Configuration as Code (CaC) involves managing and provisioning infrastructure through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. This practice enables developers and IT operations teams to automatically manage and provision their infrastructure using code. CaC is a key component of GitOps, as it allows for the desired state of infrastructure to be described declaratively and managed alongside application code.
Resources:
- Configuration as Code - CircleCI Blog
- Comparing Infrastructure as Code and GitOps for Platform Teams - The New Stack Article
Infrastructure as Code (IaC) is a key practice within DevOps that involves managing and provisioning computing infrastructure through code instead of through manual processes. With IaC, infrastructure is provisioned and managed using code and software development techniques, such as version control and continuous integration. IaC is foundational to GitOps, enabling the automatic, consistent deployment of infrastructure alongside applications.
Resources:
- What is Infrastructure as Code? - HashiCorp Article
- Getting Started with Infrastructure as Code - Terraform Docs
- DevOps is a set of practices that combines software development (Dev) and IT operations (Ops) to shorten the development lifecycle and provide continuous delivery with high software quality. GitOps can be seen as an evolution of DevOps principles, focused on using Git as a single source of truth for declarative infrastructure and applications.
- DevSecOps extends DevOps by integrating security practices into the DevOps process, ensuring that security is built into the software development lifecycle. GitOps can be used to enforce security policies and best practices across the software development lifecycle.
Resources:
- What is DevOps? - GitLab Article
- Introduction to DevSecOps - Red Hat Article
- Trusted Delivery with GitOps and Policy as Code - Weave Works Blog
- What Is GitOps? How Git Can Make DevOps Even Better - Codefresh Article
- Continuous Integration (CI): The automated process of integrating code changes from multiple contributors into a shared repository. This process includes automated testing to validate code changes before they are merged, ensuring that the codebase remains stable and functional.
- Continuous Delivery (CD): The practice of automating the software delivery process to ensure that code changes can be deployed to production at any time. GitOps can be used to automate the continuous delivery process, ensuring that the desired state of the system is always reflected in the production environment.
Resources:
- What is Continuous Integration? - Atlassian Article
- What is Continuous Delivery? - Atlassian Article
- Recreate: This pattern involves tearing down the existing instances of an application before deploying the new version. While straightforward, the main drawback is the downtime between stopping the old version and starting the new version, making it less desirable for production environments that require high availability.
- Rolling Updates: Kubernetes supports rolling updates natively, allowing updates to be applied incrementally without taking the service down. This strategy updates pods one by one, ensuring that a certain number of old and new pods are running simultaneously, which minimizes downtime and ensures that at least part of the application remains available during the update.
- Blue-Green: Involves running two identical environments ("blue" for the current version and "green" for the new version) and switching traffic from blue to green once the new version is verified to be stable. This pattern is useful for minimizing downtime and risk during deployments.
Resources:
- Top 6 Kubernetes Deployment Strategies and How to Choose - Codefresh Article
- Blue-Green Deployment - Red Hat Article
- Canary: This involves rolling out the change to a small subset of users or servers first, monitoring the performance and stability, and then gradually increasing the rollout to more users.
- Shadow/Blue-Green Mirroring: This pattern involves deploying the new version alongside the old version in such a way that the new version processes real-world traffic in parallel without affecting the end-user experience, primarily for testing purposes.
- A/B Testing/Traffic Splitting: Similar to canary releases but focuses more on comparing user behavior between the old and new versions to make data-driven decisions on feature adoption.
Resources:
- Guide to Flagger - Weave Works Docs
- Flux Progressive Delivery - Flux Docs
- Flagger Deployment Strategies - Flagger Docs
- What are Feature Flags? - LaunchDarkly Blog
- Argo Rollouts - Argo Rollouts Docs
Principle 3 specifies the desired state must be "pulled" rather than "pushed", primarily because the software agents must be able to access the desired state from the state store at any time, not only when there is an intentional change in the state store triggering a push event. This is a prerequisite for reconciliation to happen continuously, as specified in principle 4.
Note that – in contrast to traditional CI/CD, where automation is generally driven by pre-set triggers – in GitOps, reconciliation is triggered whenever there is a divergence. Divergence could be due to the actual state unintentionally drifting from the desired state declarations – not only due to a new desired state declaration version having been changed intentionally.
-
Pull-Based: Required for GitOps, agents within the cluster continuously monitor the Git repository for changes and apply updates automatically.
-
Event-Driven: While not the primary model in GitOps, event-driven mechanisms can complement GitOps by triggering actions based on specific events.
Resources:
- GitOps: The Push and Pull Approach - Harness Blog
- Understanding Pull-Based GitOps - Weave Works Blog
- In-Cluster Reconciler: A software agent that runs within the cluster and is responsible for monitoring the state of the cluster and applying the desired state.
- External Reconciler: Similar to in-cluster reconcilers, but run outside the cluster, often used for multi-cluster management or for managing resources that are not directly accessible from within the cluster.
- State Store Management: Structuring and managing the state store to ensure immutability, versioning, and complete version history.
- Secrets Management: Managing secrets in a secure and compliant manner, often using tools like Vault, Sealed Secrets, or GitOps-specific solutions like KubeSecrets.
Resources:
- Ways of structuring your repositories - Flux Docs
- Managing the 'Git' in 'GitOps': 4 Ways to Structure Code in Your GitOps Repos - Harness Blog
- Argo CD Architectures Explained - Akuity Blog
- The Basics of GitOps Secrets Management - Harness Blog
- What is Multi-Cloud GitOps? - Red Hat Article
- Kustomize: Offers a template-free way to customize application configuration that simplifies the declaration of application manifests for Kubernetes.
- Helm: Provides packaging of Kubernetes applications into charts, making it easy to share and distribute a wide range of applications.
- Declaritive YAML/JSON: A format for expressing the desired state of a system in a way that is both human-readable and machine-readable.
Resources:
- Kustomize Documentation - Kustomize Docs
- Putting Helm at the Center of Your GitOps Pipeline - Weave Works Blog
- Git: A distributed version control system that is widely used for source code management and is the canonical example of a state store used in GitOps.
- OCI Registry: A container registry that is used to store and distribute container images.
- S3: A scalable object storage service that is used to store and retrieve data.
Resources:
- What is Git? - Atlassian Git Tutorials
- GitOps with OCI Artifacts and Config Sync - Google Cloud Blog
- GitOps Use Cases You May Not Have Considered - The New Stack Article
- Flux with Buckets: Is this still GitOps? - Ediri Blog
- Single Source of Truth Architecture - Red Hat Article
- ArgoCD: A declarative, GitOps continuous delivery tool for Kubernetes.
- Flux: A tool for keeping Kubernetes clusters in sync with sources of configuration (like Git repositories), and automating updates to configuration when there is new code to deploy.
- Jenkins X: An open-source system that provides pipeline automation, GitOps, and continuous delivery for cloud-native applications on Kubernetes.
Resources:
- ArgoCD Documentation - ArgoCD Docs
- Flux Documentation - Flux Docs
- Jenkins X Documentation - Jenkins X Docs
- DORA Metrics: Metrics that are used to measure the performance of software delivery and operational processes including:
- Deployment Frequency: The frequency of deployments to production
- Lead Time for Changes: The time it takes to go from code committed to code successfully running in production
- Change Failure Rate: The percentage of changes that result in a failure in production
- Time to Restore Service: The time it takes to restore service after a failure
- Keptn: Integrates with Flux and ArgoCD to provide automated continuous delivery and operations for cloud-native applications.
- Prometheus & Alertmanager: Used for monitoring and alerting, providing a rich set of metrics and alerting capabilities.
- Jenkins: A popular open-source automation server used to automate the building, testing, and deployment of software.
- Slack & Microsoft Teams: Popular messaging platforms used for notifications and collaboration.
Resources:
- Using the Four Keys to Measure Your DevOps Performance - Google Cloud Blog
- Keptn Core Concepts - Keptn Docs
- Flux Alerts - Flux Docs
- Flux Prometheus metrics - Flux Docs
- Prometheus Documentation - Prometheus Docs
- Jenkins Documentation - Jenkins Docs
- Slack API Documentation - Slack API Docs
- Path to GitOps - Red Hat eBook (Free)
- GitOps Guide to the Galaxy - YouTube Playlist
- GitOps Cookbook - Red Hat eBook (Free)
