Five connected GitOps domains
GitOps is not simply “YAML in Git” and it is not a reason to remove CI. CI builds and verifies artifacts and validates proposed configuration. A pull-based controller obtains reviewed desired state, compares it with the cluster, applies changes, and keeps reconciling. Security, promotion, policy, observability, and recovery determine whether that loop is safe to operate.
OpenGitOps principles and Kubernetes desired state
Week 1Learn the operating model before selecting a controller. Practice describing intent, previewing changes, identifying ownership, and distinguishing actual state from authoritative desired state.
- Explain declarative, versioned and immutable, pulled automatically, and continuously reconciled
- Distinguish application source, build artifact, configuration source, controller state, and live state
- Use Kubernetes manifests with explicit selectors, probes, rollout strategy, resources, and ownership
- Preview changes with rendering, schema checks, server-side dry run, or controlled diff
- Define what drift should self-heal and what another controller legitimately owns
- Understand pruning as a deletion operation with inventory, scope, and data consequences
- Keep emergency live changes in a break-glass process and reconcile durable fixes back to Git
- Use immutable image digests and identify exact configuration revisions
- Separate CI artifact production from CD reconciliation and cluster authorization
- Create a failure matrix for source, rendering, apply, health, authorization, and recovery
Repository design, Kustomize, Helm, and review gates
Week 2Design desired state around ownership and promotion. Render the final output rather than assuming templates and overlays combine safely.
- Choose mono- or multi-repository boundaries based on ownership, access, scale, and blast radius
- Create explicit cluster and environment paths with protected production ownership
- Use Kustomize bases for common resources and small overlays for environment differences
- Use focused patches, image transformations, generators, and name references deliberately
- Use Helm for versioned reusable packages with documented values and values schemas
- Pin chart versions or OCI digests and review chart and CRD lifecycle
- Render every overlay and Helm configuration in pull-request CI
- Validate schemas, policy, namespaces, RBAC, probes, resources, and destructive diffs
- Minimize GitHub workflow permissions and pin reviewed actions to immutable commit SHAs
- Promote the same tested image digest through reviewed environment changes
Argo CD applications and multi-environment platforms
Weeks 3-4Use Argo CD Applications as bounded delivery units, then add generation, ordering, health, and progressive rollout without turning the root application into an unrestricted control plane.
- Install a pinned supported Argo CD release and model bootstrap declaratively
- Define Application source, destination, project, sync policy, prune, and self-heal
- Use AppProjects to constrain repositories, clusters, namespaces, and resource kinds
- Map Argo CD roles and Kubernetes RBAC to distinct platform and tenant responsibilities
- Keep app-of-apps roots small, admin-owned, reviewed, and recoverable
- Generate repeated Applications with ApplicationSet and constrained templates
- Use sync phases, waves, hooks, and health checks for explicit ordering
- Make migrations idempotent or version-aware, bounded, and least privilege
- Integrate Argo Rollouts for a synthetic canary with declared analysis and abort
- Observe sync, health, operation, revision, controller, notification, and stale-state signals
Flux sources, reconciliation graph, secrets, and images
Weeks 5-6Compose a fleet from Kubernetes-native APIs. Separate source acquisition from Kustomize and Helm reconciliation, then constrain each object with dependencies, service accounts, decryption authority, and version policy.
- Use GitRepository, OCIRepository, HelmRepository, and Bucket Sources according to origin needs
- Read Source artifact revision, digest, Ready condition, and acquisition errors
- Configure Kustomization path, interval, retry, prune, wait, timeout, inventory, and health
- Use dependsOn for CRDs, controllers, policy, identities, and workload prerequisites
- Operate HelmRelease chart references, values, tests, remediation, history, and drift detection
- Set serviceAccountName and namespace RBAC for tenant reconciliation
- Enforce default impersonation and restrict cross-namespace references where appropriate
- Commit no plaintext or base64-only secrets; use SOPS ciphertext and external decryption authority
- Rotate encryption recipients or KMS authority without printing decrypted content
- Use ImageRepository, ImagePolicy, and ImageUpdateAutomation with a production review branch
Policy, progressive delivery, observability, and recovery
Weeks 7-8Operate GitOps as a delivery system. Verify artifacts and identities, alert on stale reconciliation, test controlled failures, preserve Git as authority during rollback, and prove what Git can and cannot restore.
- Apply admission policy to workload security, namespaces, trusted registries, and immutable images
- Verify Sigstore signatures or attestations against approved identity, issuer, digest, and provenance policy
- Understand SLSA provenance as build evidence that still requires an organizational verification policy
- Use Argo Rollouts or Flagger to increase exposure gradually and abort on failed analysis
- Track source freshness, last applied and attempted revisions, conditions, errors, duration, drift, and suspension
- Forward safe Events and alerts with cluster, object, revision, digest, and error category
- Diagnose from status and source through render, authorization, apply, health, and controller logs
- Rollback through a reviewed Git revert or forward change to a known-good immutable artifact
- Back up stateful data and external systems separately from declarative cluster configuration
- Rebuild a lost cluster, rehydrate secrets and identity, measure cost, and verify cleanup
PrepKloud GitOps learning surfaces
Twenty-five original scenarios across principles, Argo CD, Flux, packaging, security, delivery, troubleshooting, rollback, and recovery. GitOps flashcards
Review the operating model, controller APIs, secret boundaries, image automation, policy, and disaster recovery. Two substantial projects
Build an Argo CD multi-environment platform and a Flux multi-tenant cluster fleet. Complete Argo CD and Flux guide
Read the practical architecture, security, promotion, operations, and portfolio strategy. Cloud and platform jobs
Explore roles that use Kubernetes delivery, platform engineering, DevOps, and SRE skills. Infrastructure as code foundations
Connect declarative infrastructure provisioning with continuous in-cluster reconciliation.
Official sources
Start with the four principles and verify the graduated project context for Argo and Flux.
Open OpenGitOpsArgo at CNCF · Flux at CNCF
Review Applications, projects, automated sync, hooks, waves, ApplicationSet, health, notifications, security, and recovery.
Open Argo CD docsStudy Sources, Kustomizations, HelmReleases, image automation, SOPS decryption, multi-tenancy, monitoring, and security.
Open Flux docsGround declarations, field ownership, bases, overlays, charts, values, schemas, hooks, tests, and CRD lifecycle in official guidance.
Open Kustomize docsOpen Helm docs
Secure review automation with least-privilege tokens, protected environments, safe secrets, immutable action references, and untrusted-code isolation.
Open secure-use guidanceVerify artifact signatures, identities, issuers, digest claims, attestations, build provenance, and supply-chain policy.
Open Sigstore verificationOpen SLSA v1.2
Frequently asked questions
Is this GitOps path a certification?
No. It is an independent practical skill path. It does not invent or prepare for a GitOps exam, credential, passing score, or guaranteed outcome. Evidence comes from original scenarios and two tested projects.
Should I learn Argo CD or Flux first?
Learn OpenGitOps and Kubernetes configuration first. Argo CD provides an Application-centered model and strong operational UI. Flux provides composable Kubernetes APIs and specialized controllers. Build the smaller project that matches your environment, then implement the other to understand the trade-offs.
Does GitOps mean nobody can use kubectl?
No. kubectl is essential for reading status, Events, logs, diffs, and controlled break-glass response. The durable managed change should return to Git so the reconciler and operator have one authoritative declaration.
Can Kubernetes Secrets be committed because they are base64 encoded?
No. Base64 provides no confidentiality. Use a reviewed SOPS-style encrypted workflow or external secret source, keep decryption authority outside Git, and test rotation, revocation, RBAC, and redaction.
What projects are included?
The Argo CD project builds a multi-environment platform with app-of-apps, ApplicationSet, policy, hooks, progressive promotion, rollback, and recovery. The Flux project builds a multi-tenant fleet with Sources, Kustomizations, HelmReleases, SOPS-style decryption, image automation, observability, failure injection, and cluster restore.
Learn GitOps by operating the loop
Check design judgment, reinforce controller concepts, and build two systems that can reconcile, deny, promote, alert, roll back, restore, and clean up.