This guide helps GitOps Certified Associate (CGOA) candidates connect foundational ideas to practical delivery decisions. Each concept explains a distinction or rule, works through an original example, and identifies a specific mistake. Read the foundations first, then use the patterns and tooling sections to reason through how a GitOps managed system behaves.
GitOps terminology and state
1. The boundary of a GitOps managed system
A GitOps managed software system includes declared desired state, a state store, reconciliation machinery, and the resources under its control. Define that boundary before interpreting changes. A repository can describe an application's deployment without managing its database contents, external identity service, or every underlying infrastructure component.
Worked example: A controller manages a web deployment and service. Customer records reside in an external database. Updating the deployment reconciles those two resources; it does not restore customer records.
Mistake to avoid: Assuming everything an application depends on is automatically managed by its GitOps controller.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
2. Desired state and observed state
Desired state describes the intended configuration. Observed state describes what currently exists. Reconciliation compares relevant parts of these states, while operational status explains whether resources function. A difference may reflect an unauthorized edit, an incomplete change, or a legitimate transition still in progress.
Worked example: The declaration requests four replicas, but the deployment currently has three available replicas. The desired count is four; the observation requires further inspection to distinguish scaling progress from failure.
Mistake to avoid: Treating every temporary difference as proof of an unauthorized change.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
3. Resource identity, specification, and status
A declarative resource has an identity and configurable properties; many platforms also expose controller-generated status. In Kubernetes, identity includes resource kind, name, and namespace where applicable. The specification expresses intent, while status records observations. Desired-state comparison should account for this separation and platform-managed fields.
Worked example: A deployment named storefront requests three replicas in its specification. Its status reports two available replicas. The availability report informs diagnosis; it should not be copied into the desired configuration.
Mistake to avoid: Committing generated status fields as though they were configuration inputs.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
4. The state store's role
A state store holds the authoritative desired-state descriptions that a reconciler retrieves. Git commonly provides this role through versioned files, but the role is broader than a particular product. An artifact registry stores build outputs; it becomes a desired-state source only when the system explicitly uses it that way.
Worked example: A repository specifies an image digest, while a registry stores the corresponding image. The repository answers what should run; the registry supplies the executable artifact.
Mistake to avoid: Confusing the location of application binaries with the authority for deployment configuration.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
5. State drift
State drift is a difference between declared desired state and the relevant observed configuration. It concerns managed properties, rather than every runtime fluctuation. Detection and correction are separate capabilities: a controller may report drift while awaiting approval, or automatically repair it according to its configured policy.
Worked example: Git declares two replicas, but someone changes the managed deployment to five. A comparison detects drift. Whether it returns to two immediately depends on the reconciliation policy.
Mistake to avoid: Assuming drift detection always implies automatic correction is enabled.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
6. The reconciliation loop
Reconciliation repeatedly observes the system, obtains desired state, compares relevant differences, and attempts corrective actions. The loop then observes the results again. It does not guarantee that one action will achieve the goal: permissions, dependencies, unavailable services, and invalid configuration can prevent progress.
Worked example: A controller sees a missing service and requests its creation. On its next observation, the service exists, so that corrective action is no longer necessary.
Mistake to avoid: Describing reconciliation as a one-time deployment command with no subsequent observation.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
7. Convergence and blocked progress
Convergence means repeated reconciliation moves managed state toward the declared target. It requires a reachable target and working control mechanisms. Repeated attempts without changing a blocking condition do not establish progress. Diagnose whether failure comes from the declaration, authorization, resource availability, or an external dependency.
Worked example: A workload requests an image that does not exist. Repeated reconciliation cannot make that image available. Publishing the intended artifact or correcting its reference removes the underlying blocker.
Mistake to avoid: Expecting retries alone to repair an impossible or invalid desired state.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
8. Feedback loops
A feedback loop returns observations to the process that makes decisions. Reconciliation provides machine feedback about configuration; metrics, logs, alerts, and notifications provide operational feedback to people or automation. Effective feedback identifies the affected resource and desired revision so that observations can guide a specific corrective decision.
Worked example: After a configuration change, an alert includes the application, environment, and deployed revision. The team can associate the failure with that change and investigate its effect.
Mistake to avoid: Treating a stream of uncorrelated notifications as an actionable feedback loop.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
9. Synchronization and application health
Synchronization asks whether relevant live configuration matches desired configuration. Health asks whether the resulting resources operate successfully. These are separate questions. Matching manifests can still produce a failing application, while an application can remain healthy during a temporary configuration difference or controlled deployment transition.
Worked example: The deployment uses the declared image and replica count, but its containers repeatedly crash because a dependency is unavailable. Configuration matches; application health is poor.
Mistake to avoid: Using a synchronized status as proof that users can successfully use the service.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
10. Rollback as a desired-state change
A GitOps rollback commonly restores an earlier intended configuration through a new versioned change. Reconciliation then works toward that restored target. The rollback remains visible in history and must be compatible with the current environment. Restoring configuration does not automatically reverse external side effects or data transformations.
Worked example: Revision B introduces a faulty timeout. A new commit restores revision A's timeout setting. The controller applies the restored value while preserving the record of both changes.
Mistake to avoid: Assuming a configuration rollback also reverses database migrations or completed transactions.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
11. Revision-to-environment correlation
A repository revision identifies a desired-state snapshot, but each environment may observe or apply it at a different time. Diagnosis should distinguish the latest available revision, the controller's fetched revision, and the revision successfully applied. An environment's status must be associated with its actual source selection.
Worked example: Production has applied commit P, while staging has applied commit Q. A failure reported in staging should first be investigated against Q, even if P remains production's current configuration.
Mistake to avoid: Assuming all environments run the latest commit merely because it exists in the repository.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
12. Configuration state and application data
GitOps usually manages declarations such as workload configuration, access policies, and infrastructure resources. Application data changes through runtime activity and often needs separate backup, recovery, and migration processes. Distinguish restoring the configuration of a data service from restoring the information stored by that service.
Worked example: Reverting a database deployment's memory setting restores that configuration. An order deleted earlier remains deleted unless a separate data recovery process restores it.
Mistake to avoid: Treating version-controlled infrastructure configuration as a backup of business data.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
Applying the four GitOps principles
13. Declarative intent and imperative actions
Declarative configuration states the result that should hold. Imperative instructions prescribe actions to perform. A reconciler may use imperative operations internally, but its authoritative input remains the intended result. Evaluate the interface to desired state rather than demanding that every implementation step be declarative.
Worked example: Declaring three worker instances expresses a target. Running an instruction to add one worker expresses an action whose outcome depends on the starting count.
Mistake to avoid: Calling an action script declarative simply because the script is stored in Git.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
14. Defaults and sufficiently explicit intent
A declaration must express enough intent to produce a predictable result. Omitted fields can inherit platform defaults, injected settings, or previous values depending on the system. Explicitly define properties that matter to the target outcome, while understanding which generated fields the platform owns.
Worked example: A team's deployment requires a particular resource limit. Leaving that limit unspecified allows environment defaults to affect behavior, so the team declares the required value.
Mistake to avoid: Assuming an omitted field always means zero, disabled, or removal.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
15. Idempotent corrective behavior
An idempotent operation can be repeated without accumulating additional effects once its intended result holds. Reconciliation benefits from this property because observations, retries, and event delivery may repeat. Operations with irreversible or cumulative side effects require additional controls rather than blind repetition.
Worked example: Ensuring that a named service exists leaves one service after repeated attempts. Appending a new billing record on every reconciliation would create duplicates.
Mistake to avoid: Embedding an unguarded, cumulative business action in a repeatedly executed reconciliation step.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
16. Deterministic desired-state generation
When desired state is generated from templates, equivalent pinned inputs should produce equivalent output. Hidden dependencies on time, randomness, remote changes, or unpinned packages make comparison and rollback harder. Record the inputs needed to reproduce the intended manifests, including relevant rendering dependencies.
Worked example: A template inserts the current time into a deployment annotation on every render. Its output changes without a configuration change, creating unnecessary differences. Removing that input makes rendering stable.
Mistake to avoid: Assuming versioned templates guarantee reproducibility when their dependencies remain mutable.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
17. Versioned desired-state changes
Versioning records successive desired-state snapshots so changes can be compared, attributed, and revisited. A useful change groups related configuration edits into a coherent revision. History supports investigation, but readers still need to understand the meaning of a change rather than treating its existence as validation.
Worked example: One commit updates both a service's port and the workload's matching port declaration. Reviewers can inspect the coordinated change and compare it with the preceding revision.
Mistake to avoid: Treating version history as proof that a configuration change is correct.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
18. Immutable revisions and moving references
An immutable revision identifies fixed content. A branch or movable tag identifies a reference that can point to different content over time. Both can be useful, but diagnosis and recovery require knowing which immutable revision was actually selected. Protecting references and recording resolved revisions improve traceability.
Worked example: The production branch advances from commit R to commit S. Recording only the branch name cannot distinguish the two deployments; recording R or S identifies the intended snapshot.
Mistake to avoid: Treating a branch name as a permanent identifier for one configuration.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
19. Immutable artifact references
Versioned configuration should identify the actual artifact intended to run. A mutable image tag can resolve to different content without a manifest change. A content digest identifies specific image content, although compatibility and trust still require separate checks. Configuration immutability and artifact immutability support each other.
Worked example: Two deployments both reference an image tagged stable, but the tag changes between them. Referencing the approved image digest instead keeps both deployments tied to the same artifact.
Mistake to avoid: Assuming an unchanged manifest guarantees an unchanged application when its artifact references are mutable.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
20. Reviewing changes at the source boundary
Review controls who may alter authoritative desired state and how proposed changes are evaluated. Branch protections, approvals, and automated checks can make that boundary explicit. Their value depends on coverage: alternate write paths, controller permissions, and emergency procedures must also respect the intended governance.
Worked example: A production manifest change requires an approved pull request and successful validation. A direct write by an automation account would bypass that process unless its permissions are constrained.
Mistake to avoid: Assuming a review policy protects every change path merely because developers normally use pull requests.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
21. Automatically pulling desired state
Under the pull principle, software agents automatically obtain desired state from its authoritative source. A developer or CI job need not directly apply each change to the target. The agent needs appropriate source access and target permissions, and failures in either path can stop delivery.
Worked example: CI publishes an image and updates its declared digest. A target-side agent retrieves that revision and reconciles the workload without CI holding workload-administration credentials.
Mistake to avoid: Calling a pipeline GitOps solely because it reads Git before pushing changes directly to the environment.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
22. Polling and event-triggered retrieval
Polling checks a source periodically; an event can prompt an earlier check. Trigger mechanism and transfer direction are separate design choices. A webhook can notify a reconciler that state may have changed while the reconciler still pulls authoritative content. Lost or duplicated notifications should not invalidate the state model.
Worked example: A repository webhook prompts a controller to fetch a revision. Periodic checks remain available if the notification is missed, preserving eventual discovery.
Mistake to avoid: Assuming any webhook automatically turns a pull architecture into a push deployment architecture.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
23. Selecting the intended source revision
Automatic retrieval must target the correct repository, path, and revision selection. A healthy connection can still deliver the wrong desired state if these selectors are incorrect. Distinguish authentication failure from source-selection failure by checking what content and revision the controller actually fetched.
Worked example: A controller successfully reads the staging directory while managing production. Its source access works, but its path selection is wrong; improving network connectivity would not fix the deployment.
Mistake to avoid: Diagnosing every unexpected deployment as a synchronization failure without checking source selectors.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
24. Least privilege for reconciliation
A reconciler needs permission to read its source and perform approved changes within its managed boundary. Apply least privilege separately to these capabilities. Read access to configuration, access to secrets, and write access to target resources create different risks and should not be bundled unnecessarily.
Worked example: An agent manages workloads in one namespace. Giving it authority to change unrelated cluster-wide policies expands its impact beyond the task it performs.
Mistake to avoid: Granting broad administrative rights simply to avoid diagnosing a specific missing permission.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
25. Continuous reconciliation after deployment
Continuous reconciliation keeps checking and correcting relevant differences after the initial deployment. It addresses changes caused by failures, manual edits, and other controllers according to configured ownership and policies. A successful initial application alone does not establish this principle if subsequent state is never observed.
Worked example: A managed configuration object is accidentally removed after deployment. A continuously operating controller detects its absence and can recreate it from the declared state.
Mistake to avoid: Equating a scheduled deployment job with a controller that continuously maintains desired state.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
26. Clear ownership of managed fields
Multiple controllers can legitimately cooperate, but overlapping authority can cause repeated conflicting writes. Define which mechanism owns each resource or field, and understand intentional exclusions from comparison. Dynamic controllers often need ownership of runtime-adjusted properties while Git remains authoritative for the surrounding configuration.
Worked example: An autoscaler adjusts replica count while a GitOps controller repeatedly restores a fixed count. Assigning compatible ownership prevents this oscillation.
Mistake to avoid: Letting two independent controllers enforce incompatible values for the same field.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
27. Handling emergency overrides
An emergency live change creates a temporary difference unless desired state is updated to agree. Recovery procedures should define authorization, any necessary reconciliation pause, and how the final intended configuration returns to version control. A temporary override must not silently become an undocumented permanent state.
Worked example: During an incident, an authorized responder changes a timeout. The team records the accepted value in Git before restoring normal reconciliation, preventing the controller from reinstating the failing value.
Mistake to avoid: Making a live fix without checking whether reconciliation will immediately undo it.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
28. Deletion and pruning policies
Removing a declaration expresses a change in desired state, but deletion behavior depends on controller policy, ownership, and resource characteristics. Pruning can remove resources no longer declared. Review deletions carefully, especially where persistent data or shared dependencies are involved, and verify the actual policy before predicting an outcome.
Worked example: A manifest disappears from a repository. With appropriate pruning enabled, its managed resource may be deleted; without that behavior, it may remain present.
Mistake to avoid: Assuming deleting a file always deletes its live resource safely.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
29. Dependencies and eventual consistency
Desired-state changes can involve resources that become ready at different times. A stored revision does not make target-side application atomic. Reconciliation must accommodate dependencies and readiness, often through ordering or repeated observation. Creating a dependency and confirming it is usable are separate steps.
Worked example: A workload requires a configuration object and a reachable external service. Applying its manifest successfully does not mean those dependencies are ready, so workload readiness may follow later.
Mistake to avoid: Assuming one Git commit produces an instantaneous, all-or-nothing update across all resources.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
30. Secrets within versioned systems
Version control retains historical content, making plaintext secrets especially difficult to retract once committed. Desired state can reference external secrets or contain appropriately encrypted representations, with decryption access controlled separately. Encryption protects confidentiality only within a sound key-management and access-control design.
Worked example: A manifest references a credential supplied by an authorized secret-management integration. The repository records the reference without exposing the credential value.
Mistake to avoid: Deleting a secret from the latest file and assuming it has disappeared from repository history.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
Configuration, infrastructure, and delivery practices
31. Configuration as Code and Infrastructure as Code
Configuration as Code represents settings in machine-readable, versionable form. Infrastructure as Code represents infrastructure resources and their configuration. They overlap: a network declaration is infrastructure code, while an application's feature setting is configuration code. Either can support GitOps when the complete management approach follows its principles.
Worked example: One repository stores a virtual network declaration and an application's logging setting. The first primarily describes infrastructure; the second describes application configuration.
Mistake to avoid: Assuming every version-controlled configuration or infrastructure file automatically constitutes GitOps.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
32. Infrastructure provisioning and reconciliation
Infrastructure provisioning tools may evaluate declarations through plans and explicit apply operations. A GitOps integration additionally needs authoritative versioned state, automatic retrieval, and continuing reconciliation. Some tools maintain operational state about existing resources; that bookkeeping has a different role from the repository's desired-state declarations.
Worked example: A pipeline applies a network configuration once and never checks it again. It uses Infrastructure as Code, but that behavior alone does not establish continuous GitOps reconciliation.
Mistake to avoid: Confusing a provisioning tool's state file with the complete authoritative desired-state description.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
33. Continuous integration and continuous delivery
Continuous integration combines changes and checks their correctness through builds and tests. Continuous delivery keeps changes ready for release through a reliable delivery process; continuous deployment automatically releases qualifying changes. GitOps commonly supplies the desired-state and reconciliation portion of delivery while CI produces validated artifacts.
Worked example: CI tests a service and publishes an image. A reviewed configuration change selects that image, and a reconciler deploys it. The build and deployment perform different responsibilities.
Mistake to avoid: Treating GitOps as a replacement for compilation, testing, or artifact production.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
34. Building once and promoting artifacts
Promoting an existing immutable artifact preserves the relationship between testing and deployment. Rebuilding from the same source can produce different content if dependencies or build conditions change. Environment-specific configuration can vary independently, but the application artifact should remain identifiable throughout promotion.
Worked example: Staging validates image digest D. Production's manifest is updated to D with production configuration, preserving the tested artifact rather than creating a fresh image from the same source.
Mistake to avoid: Assuming two builds from the same commit must produce identical artifacts.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
35. Layers of configuration validation
Validation has distinct layers: parsing checks structure, schema checks expected fields and types, policy checks organizational constraints, and runtime checks actual behavior. Passing one layer does not imply passing the others. Apply checks to the generated desired state when templates or overlays can change the final output.
Worked example: A manifest parses successfully and uses valid fields, but violates a policy requiring approved image sources. Syntax validation alone would not detect that policy failure.
Mistake to avoid: Using valid YAML as evidence that configuration is deployable, permitted, and operationally correct.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
36. DevOps responsibilities and feedback
DevOps connects development and operations through collaboration, automation, and feedback. GitOps supports this by making intended operational changes reviewable and observable. Shared responsibility still needs clear decision rights: application owners, platform teams, and responders may control different parts of the same delivery system.
Worked example: An application team changes a timeout, while a platform team maintains reconciliation permissions. Both review an incident using the deployed revision and controller observations.
Mistake to avoid: Assuming adopting a GitOps tool automatically establishes ownership or cross-team collaboration.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
37. DevSecOps across the change lifecycle
DevSecOps incorporates security checks and controls throughout development and operation. In GitOps, useful control points include source changes, artifact production, desired-state validation, source access, and target authorization. Each protects a different boundary; a secure repository does not establish that an artifact or runtime environment is secure.
Worked example: A change passes manifest policy checks, but its referenced image contains an unacceptable vulnerability. Artifact assessment provides information that configuration review alone cannot supply.
Mistake to avoid: Treating one security gate as protection for every stage of delivery.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
38. Merging configuration changes
Git merges combine changes to the desired-state files, but textual success does not guarantee semantic compatibility. Two edits can merge cleanly while creating an invalid combined configuration. Validate the resulting revision and its rendered output, especially where independently edited fields depend on one another.
Worked example: One change updates a service's port; another changes the workload's listening port differently. Git may combine both without a textual conflict, yet the service no longer reaches the workload.
Mistake to avoid: Assuming a conflict-free merge proves the resulting configuration is coherent.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
39. Separating CI credentials from deployment authority
A pull-based delivery design can let CI publish artifacts and propose desired-state changes without granting it direct control over the target. The reconciler holds bounded deployment authority. Protect repository write access carefully because changing authoritative desired state can indirectly affect the environment even without direct target credentials.
Worked example: A build account can publish an image and open a configuration pull request. It cannot approve that request or modify production workloads directly.
Mistake to avoid: Assuming repository write access is harmless because the account lacks cluster credentials.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
40. Traceability and artifact provenance
Traceability links source changes, builds, artifacts, desired-state revisions, and observed deployments. Provenance adds evidence about how an artifact was produced. Signatures or attestations require verification against trusted identities and policy; their presence alone does not prove that the resulting software is appropriate or free of defects.
Worked example: An incident record links deployment revision M to image digest D and the build that produced D. Investigators can distinguish the configuration change from the underlying code change.
Mistake to avoid: Treating a signed commit as proof that the deployed artifact came from that commit.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
Deployment, release, and architecture patterns
41. Deployment and release
Deployment places software into an environment. Release makes functionality available to its intended users. These events can occur together or separately. Traffic routing and feature controls can decouple them, allowing operational verification before broader exposure. Desired state should describe the relevant deployment and release controls.
Worked example: A new service version is deployed behind a disabled feature flag. Its processes run, but customers continue using the existing behavior until the flag changes.
Mistake to avoid: Assuming every deployment immediately exposes every new feature to all users.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
42. Rolling replacement
A rolling deployment gradually replaces instances of an old version with a new version. Both versions can coexist during the transition, making compatibility and readiness important. Availability depends on workload behavior, capacity, and update settings; choosing a rolling strategy does not itself guarantee uninterrupted service.
Worked example: A six-instance service replaces instances in stages. Requests may reach either version during replacement, so both versions must understand the shared request format.
Mistake to avoid: Planning a rolling deployment that requires every instance to switch formats simultaneously.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
43. Blue-green deployment
Blue-green deployment maintains separate old and new deployment groups and changes routing to select the active group. It can simplify traffic reversal while the old group remains usable. Capacity, configuration compatibility, and shared data still matter; reversing routing does not undo writes already made by the new version.
Worked example: The blue group serves customers while green undergoes verification. Routing then switches to green. If green fails, routing can return to blue if blue remains compatible and available.
Mistake to avoid: Assuming a traffic switch automatically reverses data changes made after release.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
44. Canary delivery and traffic exposure
Canary delivery exposes a new version to a limited portion of users or requests before expanding exposure. Instance count and request share are different quantities. Uneven load balancing, session affinity, and routing rules can produce different traffic distributions, so measure exposure through the actual delivery mechanism.
Worked example: One of five instances runs the new version, but a router explicitly sends it 10% of requests. Its instance share is 20%; its configured traffic share is 10%.
Mistake to avoid: Inferring canary traffic percentage solely from the fraction of new-version instances.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
45. Evaluating progressive delivery metrics
Progressive delivery decisions should compare meaningful observations against predefined criteria. Distinguish counts from rates and consider sample size, measurement windows, and relevant baselines. A small sample can hide problems, while aggregate metrics can obscure a canary's behavior. Decision criteria must suit the service rather than use a universal threshold.
Worked example: A canary has 8 failed requests out of 400, giving a 2% error rate. The stable version has 20 failures out of 2,000, giving 1%.
Mistake to avoid: Declaring the canary better because it has fewer failures without comparing request volumes.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
46. Coordinating release reversal with desired state
A progressive delivery controller may reduce exposure or restore a stable workload after failed analysis. That immediate action must remain compatible with the authoritative desired state and other controllers. Establish how the rejected version is paused, removed, or recorded so ordinary reconciliation does not repeatedly reintroduce it.
Worked example: Analysis returns traffic to the stable version. The team then records the accepted stable artifact in desired state, preventing an independent reconciler from continually requesting the rejected release.
Mistake to avoid: Assuming an automatic traffic reversal permanently changes the version selected by Git.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
47. Feature flags as release controls
Feature flags can control behavior independently of binary deployment. Their defaults, ownership, targeting rules, and failure behavior affect the release outcome. If flag state is managed outside the GitOps boundary, recognize that separate authority. A flag only protects functionality designed to respect it.
Worked example: A new checkout path is enabled for an internal user group after deployment. Other customers retain the existing path because the targeting rule excludes them.
Mistake to avoid: Assuming disabling a flag reverses background jobs or side effects already executed.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
48. In-cluster and external reconcilers
An in-cluster reconciler runs within the target cluster; an external reconciler operates outside it. Placement changes connectivity, credentials, isolation, and failure dependencies. Neither placement automatically determines whether the design follows GitOps: both can pull authoritative desired state and continuously reconcile managed resources.
Worked example: An external controller loses access to a cluster API while existing workloads continue running. Desired-state changes wait until connectivity returns, illustrating a management-path dependency.
Mistake to avoid: Assuming an external reconciler necessarily means CI pushes deployments.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
49. Bootstrapping the management loop
Bootstrapping establishes enough infrastructure, access, and controller configuration for GitOps management to begin. Avoid circular dependencies in which the controller requires a resource that only the absent controller can create. Identify the initial trust and recovery path, then hand appropriate resources into ongoing management.
Worked example: A new environment first receives a reconciler and source credentials through an authorized bootstrap process. The reconciler can then retrieve and maintain application declarations.
Mistake to avoid: Assuming a controller can install itself into an environment where nothing can yet retrieve or apply its declaration.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
50. Repository boundaries and change coordination
A single repository can simplify coordinated review across related configuration, while multiple repositories can separate access and ownership. The useful choice depends on organizational boundaries and dependency management. Neither layout guarantees atomic application across environments, and separate repositories require explicit coordination when changes depend on one another.
Worked example: Application teams own separate repositories, while a platform repository selects approved revisions. Updating the platform selection coordinates delivery without granting every team direct control over shared configuration.
Mistake to avoid: Choosing repository layout solely by assuming one repository means atomic deployment.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
51. Promotion between environments
Environment promotion changes which approved artifact and configuration an environment declares. Keep environment differences explicit and preserve the identity of the tested artifact. Promotion can use directories, repositories, or other source arrangements; its correctness depends on source selection and review rather than one mandatory branching pattern.
Worked example: Staging validates digest H. A production change selects H while retaining production's database endpoint and resource configuration. The artifact is promoted without copying staging-specific settings.
Mistake to avoid: Copying an entire staging configuration into production without checking environment-specific values.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
52. Fleet rollout and failure containment
When managing multiple clusters or environments, staged rollout limits how widely a faulty change can spread before feedback arrives. Select groups deliberately and define progression conditions. A shared source change can affect many targets, so distribution architecture and controller behavior determine the actual blast radius.
Worked example: A configuration reaches one noncritical cluster first. After its behavior is evaluated, the approved revision is selected for another group instead of changing every cluster simultaneously.
Mistake to avoid: Assuming independent cluster controllers prevent a shared bad revision from spreading across the fleet.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
Manifest packaging, state stores, and integrations
53. Plain manifests and data types
Plain manifests directly represent resource configuration, commonly in YAML or JSON. Their structure, field types, and resource identity matter more than visual formatting. A document can be syntactically valid yet supply the wrong type for a field. Review the interpretation expected by the target API.
Worked example: An application environment variable is intended to contain the text false. Representing it as a quoted string avoids confusing that text with a YAML Boolean value.
Mistake to avoid: Assuming visually similar scalar values have identical types and meanings.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
54. Kustomize bases and overlays
Kustomize composes and customizes Kubernetes manifests through bases and overlays rather than requiring every environment to duplicate complete files. Shared configuration belongs in an appropriate base; environment differences belong in explicit customization. Inspect the rendered resources because combinations of patches and transformations determine the actual desired state.
Worked example: A shared base defines a service deployment. A production overlay changes its replica count while a test overlay selects a smaller count, preserving shared resource structure.
Mistake to avoid: Reviewing an overlay alone without checking its effect on the complete rendered configuration.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
55. Helm charts, values, and rendered output
Helm packages Kubernetes configuration in charts that commonly use templates and values to produce manifests. The resulting desired state depends on the chart, supplied values, and relevant dependencies. Pin and review those inputs. Chart defaults can change between versions, so a chart upgrade deserves inspection beyond the application's image.
Worked example: A team upgrades a chart while preserving its values file. Rendering reveals a changed service setting from the new chart default, prompting review before deployment.
Mistake to avoid: Assuming unchanged values guarantee unchanged manifests after a chart upgrade.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
56. Git and alternative state stores
Git is a common state store, but evaluate alternatives against the required properties rather than their names. A suitable design needs declarative state with identifiable immutable versions, automatic retrieval, and continuous reconciliation. Content addressing can identify an artifact, while access controls and metadata support its trustworthy use.
Worked example: A reconciler retrieves a packaged desired-state artifact by digest from a registry. The fixed digest identifies content, but the overall system still needs authorization and continuous reconciliation.
Mistake to avoid: Assuming any file server or artifact registry automatically satisfies all GitOps principles.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
57. Argo CD's source-to-destination model
Argo CD is a GitOps reconciliation engine for Kubernetes applications. Understand the relationship between source configuration, manifest generation, destination selection, and synchronization policy. Diagnosis starts by identifying what was rendered and where it was intended to apply, rather than assuming every unexpected result is a workload failure.
Worked example: An application renders the correct resources but targets the wrong namespace. Correcting destination configuration addresses the delivery error; rebuilding the container image would not.
Mistake to avoid: Checking only application code when source, rendering, or destination selection is wrong.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
58. Flux's composed reconciliation responsibilities
Flux provides controllers that cooperate across source retrieval and the reconciliation of Kubernetes configuration or packaged releases. Understand the responsibility of each stage rather than viewing delivery as one opaque action. A successfully retrieved source does not establish that downstream rendering, authorization, or application succeeded.
Worked example: Flux retrieves a new source revision, but a configuration reconciliation fails because the rendered resource is invalid. Investigation moves to the failing stage rather than repository connectivity.
Mistake to avoid: Treating source-fetch success as proof that the environment has applied the revision.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
59. Observability for diagnosing reconciliation
Use controller events and logs to inspect attempted actions, metrics to identify trends, and resource status to assess outcomes. Correlate observations with the target and source revision. Distinguish management-plane failure from application failure so that the corrective action addresses the layer where progress stopped.
Worked example: Controller logs report an authorization rejection when creating a resource. Existing application metrics remain normal. The immediate problem is reconciliation permission, not evidence of a failing application.
Mistake to avoid: Using healthy application metrics to conclude that the delivery control plane is functioning.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
60. Notifications and CI interoperability
Integrations should exchange meaningful events while preserving authoritative desired state. CI can propose changes, source events can prompt retrieval, and notifications can report reconciliation outcomes. Consumers should handle repeated events safely and verify current state before acting. Event receipt alone is neither approval nor proof of successful deployment.
Worked example: A deployment notification arrives twice. An incident integration updates the same record using the application and revision identity instead of creating two unrelated incidents.
Mistake to avoid: Triggering an unreviewed target mutation merely because a notification was received.
Reference: Certified GitOps Associate (CGOA) - Linux Foundation - Education
Sources
Source verification:
All study guides