GitOps and ArgoCD Certification Study Guide

What is GitOps and how does ArgoCD implement it?

GitOps is an operational framework that uses Git as the single source of truth for infrastructure and application configuration, with automated reconciliation to ensure deployed state matches declared state. ArgoCD implements GitOps for Kubernetes by continuously monitoring Git repositories and applying any configuration drift back to the desired state defined in Git.

---

The Argo Project certification (offered through the CNCF and Linux Foundation) and ArgoCD expertise have become critical skills for platform engineers and DevOps engineers operating Kubernetes at scale. GitOps with ArgoCD has replaced traditional push-based CI/CD for Kubernetes deployments at thousands of organizations.

The GitOps Fundamentals and GitOps at Scale certifications from Codefresh (the primary ArgoCD enterprise sponsor) validate GitOps and ArgoCD expertise. The CNCF Argo Project Certification validates knowledge of ArgoCD, Argo Workflows, Argo Rollouts, and Argo Events as a complete platform.

---

Exam Overview

Detail	Information
Certification	GitOps Fundamentals + GitOps at Scale
Provider	Codefresh / Linux Foundation
Format	Online multiple-choice
Duration	90 minutes
Passing Score	75%
Cost	Free (Codefresh courses) / $250 (LF cert)
Prerequisites	Kubernetes familiarity recommended
Validity	2 years

The GitOps certification covers:

1. GitOps principles and patterns
2. ArgoCD architecture and installation
3. Application deployment and sync
4. App of Apps pattern and ApplicationSets
5. Argo Rollouts (progressive delivery)
6. Multi-cluster and multi-tenant GitOps

"GitOps fundamentally changes how teams think about deployment. When Git is the source of truth, 'who deployed what and when' is answered by git log rather than tribal knowledge. ArgoCD makes this practical for Kubernetes teams by automating the reconciliation loop that keeps cluster state aligned with repository state. Teams adopting GitOps report dramatically faster incident recovery because rolling back is a git revert." -- CNCF GitOps Working Group, 2024 State of GitOps

---

GitOps Principles

The Four Core Principles (OpenGitOps)

The OpenGitOps project (CNCF) defines GitOps through four declarative principles:

1. Declarative: The entire system state is described declaratively. You declare what you want (YAML manifests), not how to achieve it (imperative commands).

2. Versioned and Immutable: The desired state is stored in a version control system that enforces immutability and complete version history. Every change is a commit.

3. Pulled Automatically: Automated software agents (reconcilers) automatically pull desired state from the repository and apply it to the system.

4. Continuously Reconciled: Software agents continuously observe actual system state and reconcile it with desired state. Any configuration drift is detected and corrected.

GitOps vs. Traditional CI/CD

Aspect	Push-based CI/CD	GitOps (Pull-based)
Who triggers deployment	CI system pushes to cluster	Agent pulls from Git
Cluster credentials	CI system holds cluster access	Cluster agent holds Git access
Drift detection	No (set-and-forget)	Yes (continuous reconciliation)
Rollback mechanism	Re-run pipeline with old tag	git revert + auto-sync
Audit trail	CI system logs	Git commit history
Secret exposure	Cluster creds in CI system	Minimal external access needed

---

ArgoCD Architecture

Components

                    ┌─────────────────────────────┐
                    │         ArgoCD               │
                    │                              │
  Git Repo ────────►│ Repo Server                  │
                    │ (clones + renders manifests) │
                    │                              │
  OCI Registry ────►│ Application Controller       │──────► Kubernetes API
  (Helm charts)    │ (reconciliation loop)        │         (target clusters)
                    │                              │
  Users/CI ────────►│ API Server                   │
                    │ (REST + gRPC API, auth)      │
                    │                              │
                    │ Redis (cache/queue)          │
                    │                              │
                    │ Dex (SSO OIDC provider)      │
                    └─────────────────────────────┘

API Server: Handles REST and gRPC requests from the Web UI, CLI (argocd), and external systems. Enforces RBAC policies.

Repo Server: Clones Git repositories and renders Kubernetes manifests from Helm charts, Kustomize overlays, Jsonnet, or plain YAML.

Application Controller: The reconciliation loop. Compares desired state (from repo server) with live state (from Kubernetes API). Syncs differences.

Dex: Optional built-in OIDC provider for SSO integration (GitHub, Google, Okta, LDAP).

ArgoCD Installation

# Install ArgoCD in Kubernetes
kubectl create namespace argocd
kubectl apply -n argocd -f \
  https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Get initial admin password
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d

# Port-forward to access UI
kubectl port-forward svc/argocd-server -n argocd 8080:443

# Login via CLI
argocd login localhost:8080 --username admin --password <password>

---

ArgoCD Applications

Application Resource

The ArgoCD Application is a Kubernetes custom resource defining what to deploy and where:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-application
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/k8s-manifests
    targetRevision: HEAD
    path: apps/my-application/overlays/production
  destination:
    server: https://kubernetes.default.svc    # In-cluster
    namespace: my-application
  syncPolicy:
    automated:
      prune: true         # Delete resources removed from Git
      selfHeal: true      # Restore manually changed resources
    syncOptions:
      - CreateNamespace=true
      - PrunePropagationPolicy=foreground

Sync Strategies and Phases

Sync phases determine the order of resource application:

1. PreSync hooks: Jobs/resources to run before the sync (database migrations)
2. Sync: Apply all resource changes
3. PostSync hooks: Jobs/resources to run after sync (smoke tests, notifications)
4. SyncFail hooks: Resources to apply if sync fails (notification, cleanup)

# PreSync hook example (database migration)
apiVersion: batch/v1
kind: Job
metadata:
  name: db-migrate
  annotations:
    argocd.argoproj.io/hook: PreSync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      containers:
        - name: migrate
          image: myapp:1.5.0
          command: ["/app/migrate.sh"]
      restartPolicy: Never

Sync Waves

Sync waves control the order of resource application within a sync:

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "1"    # Lower numbers apply first

Example ordering:

• Wave -5: Namespace and CRDs
• Wave 0: ConfigMaps and Secrets
• Wave 5: Deployments and Services
• Wave 10: Ingress and HPA

---

App of Apps and ApplicationSets

App of Apps Pattern

The App of Apps pattern uses a parent ArgoCD Application to manage child Applications:

# Parent application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: apps
spec:
  source:
    path: apps/                # Directory containing child Application manifests
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd

apps/
  frontend.yaml      # Application manifest for frontend
  backend.yaml       # Application manifest for backend  
  database.yaml      # Application manifest for database
  monitoring.yaml    # Application manifest for Prometheus stack

ApplicationSets

ApplicationSets generate multiple Applications from a template, eliminating repetitive Application manifests:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: guestbook
spec:
  generators:
    - list:
        elements:
          - cluster: staging
            url: https://staging.k8s.example.com
            env: staging
          - cluster: production
            url: https://prod.k8s.example.com
            env: production
  template:
    metadata:
      name: 'guestbook-{{cluster}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/myorg/guestbook
        targetRevision: HEAD
        path: 'overlays/{{env}}'
      destination:
        server: '{{url}}'
        namespace: guestbook

ApplicationSet generators:

Generator	Use Case
List	Explicit list of clusters/environments
Cluster	All clusters registered with ArgoCD
Git	Git directory structure or files drive generation
Matrix	Combine two generators (clusters x environments)
SCM Provider	GitHub/GitLab organization repositories
Pull Request	PR-per-environment for preview environments

---

Argo Rollouts

Progressive Delivery

Argo Rollouts extends Kubernetes Deployments with advanced release strategies:

Canary deployment:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp-rollout
spec:
  replicas: 10
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: myapp:1.5.0
  strategy:
    canary:
      steps:
        - setWeight: 10         # 10% to canary
        - pause: {duration: 5m} # Wait 5 minutes
        - setWeight: 25
        - pause: {duration: 10m}
        - setWeight: 50
        - pause: {}             # Manual promotion required
        - setWeight: 100
      canaryService: myapp-canary
      stableService: myapp-stable
      trafficRouting:
        nginx:
          stableIngress: myapp-ingress

Blue-green deployment:

strategy:
  blueGreen:
    activeService: myapp-active
    previewService: myapp-preview
    autoPromotionEnabled: false    # Manual promotion
    prePromotionAnalysis:          # Run analysis before promotion
      templates:
        - templateName: error-rate

Analysis Templates

Analysis templates define metrics-based automated promotion or rollback:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: error-rate
spec:
  metrics:
    - name: error-rate
      interval: 1m
      successCondition: result[0] < 0.01    # Less than 1% error rate
      failureLimit: 3
      provider:
        prometheus:
          address: http://prometheus:9090
          query: |
            sum(rate(http_requests_total{status=~"5.."}[5m]))
            /
            sum(rate(http_requests_total[5m]))

---

Frequently Asked Questions

What is the difference between ArgoCD and Flux? ArgoCD and Flux are both CNCF GitOps tools for Kubernetes. ArgoCD provides a richer Web UI, role-based access control, multi-cluster management from a central server, and native ApplicationSet support. Flux is more lightweight, CLI-centric, and follows a microservice architecture where each component is a separate controller. ArgoCD is more popular for teams wanting visibility and multi-cluster management; Flux is preferred for teams emphasizing minimal footprint and pure GitOps principles. Both are production-ready and widely adopted.

How do I handle secrets in GitOps when I cannot store them in Git? Secrets require special handling in GitOps since they cannot be stored as plaintext in Git. Common approaches are: (1) Sealed Secrets (Bitnami) — encrypt secrets with a cluster public key before committing; only the cluster can decrypt. (2) External Secrets Operator — sync secrets from AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault into Kubernetes Secrets. (3) Vault Agent Sidecar — inject secrets directly into pods. External Secrets Operator is the most widely adopted approach for ArgoCD deployments.

Can ArgoCD manage applications across multiple Kubernetes clusters? Yes, ArgoCD is designed for multi-cluster management. Register external clusters using argocd cluster add <context-name>. Each Application specifies a destination server (cluster URL). ApplicationSets automate deploying the same application to multiple clusters simultaneously. The central ArgoCD installation in one cluster manages workloads in all registered clusters using service account credentials stored as Kubernetes secrets in the ArgoCD namespace.

References

1. Argo Project. (2025). ArgoCD Documentation. https://argo-cd.readthedocs.io/
2. OpenGitOps. (2024). GitOps Principles v1.0. https://opengitops.dev/
3. CNCF. (2024). State of GitOps Report 2024. https://codefresh.io/gitops/state-of-gitops-report/
4. Codefresh. (2025). GitOps Certifications. https://codefresh.io/learn/gitops/
5. Weaveworks. (2023). GitOps for Kubernetes. O'Reilly Media.
6. CNCF. (2025). Argo Project. https://www.cncf.io/projects/argo/