The blueprint
A mock exam here has 60 questions in 90 minutes, split across the domains in the same proportions as the official exam guide. The official pass mark is 75%. FixOps scores practice against a target of 75%.
-
01
GitOps Terminology
-
02
GitOps Principles
-
03
Related Practices
-
04
GitOps Patterns
-
05
Tooling
Sample questions
Three of the 10 questions in the free diagnostic. Open one to see the answer and why.
The fourth GitOps principle says agents continuously observe the system. What does "continuous" mean in the OpenGitOps glossary?
- Every change is applied within one second of being committed
- Reconciliation keeps happening; it does not have to be instantaneous
- Reconciliation runs once for each commit and then stops until the next
- The agent holds a permanent network connection open to the Git server
Answer: Reconciliation keeps happening; it does not have to be instantaneous. The glossary says the word matches the industry term: reconciliation continues to happen, not that it must be instantaneous. An agent that compares states on an interval is continuous in this sense, while one that only acts when a commit arrives is not.
How does the OpenGitOps glossary define desired state?
- A list of the changes that operators plan to make to the system during the next release
- All configuration data sufficient to recreate the system with the same behaviour
- The most recent container image that the CI pipeline has built and pushed
- The state the system is in right now, as read from its API a moment ago
Answer: All configuration data sufficient to recreate the system with the same behaviour. Desired state is the aggregate of all configuration data sufficient to recreate the system so that instances are behaviourally indistinguishable. What the API reports now is the actual state; an image and a change plan are neither the whole configuration nor a statement of how the system should be.
Which list names the four GitOps principles of OpenGitOps v1.0.0?
- Codified; Reviewed and Approved; Built Automatically; Continuously Integrated and Tested
- Declarative; Tested and Signed; Pushed Automatically; Continuously Monitored
- Declarative; Versioned and Immutable; Pulled Automatically; Continuously Reconciled
- Imperative; Versioned and Mutable; Pulled Manually; Reconciled on Demand
Answer: Declarative; Versioned and Immutable; Pulled Automatically; Continuously Reconciled. OpenGitOps states that the desired state of a GitOps managed system must be declarative, versioned and immutable, pulled automatically, and continuously reconciled. Testing, signing, reviewing and building are good practices around these, not the principles themselves.
Revision notes: GitOps Terminology
The notes for one domain, free to read here and in the app. FixOps Pro has them for all 5 domains.
The words the OpenGitOps principles are built from: desired state and how it is described, where it is stored, how a system drifts from it and is reconciled back, and how feedback and rollback fit in.
Desired state and how it is described
- Desired state is the aggregate of all configuration data that is sufficient to recreate the system so that instances are behaviourally indistinguishable.
- Persistent application data, such as database contents, is generally not part of the desired state; credentials for reaching it and configuration for recovery tools often are.
- A declarative description says what the operating state should be without specifying the procedures for getting there.
- Declarative separates the configuration (the desired state) from the implementation: the commands, API calls and scripts that achieve it.
- Argo CD calls the desired state the target state and the actual state the live state.
Drift and reconciliation
- Drift is the actual state having moved, or moving, away from the desired state.
- Reconciliation is the process of ensuring the actual state of a system matches its desired state.
- Reconciliation is triggered whenever there is a divergence: unintended drift, or a new version of the desired state declared on purpose.
- Continuous means that reconciliation keeps happening, not that it is instantaneous.
- Agents attempt to apply the desired state: an attempt can fail, and later attempts act on what the earlier ones achieved.
State store and managed system
- A state store is a system for storing immutable versions of desired state declarations, with access control and auditing on changes.
- Git is the canonical state store, but any system that meets the criteria may be used, and it has to be configured so that the principles hold.
- A GitOps managed software system consists of one or more runtime environments, the management agents within each runtime, and policies for access and management.
- Git refers to content by its checksum, so changed content has another id and a commit names one version for good.
Feedback and rollback
- OpenGitOps follows control theory and works as a closed loop: feedback is how previous attempts to apply the desired state affected the actual state.
- Acting on feedback can mean trying to add resources, rolling back to a previous version, or alerting human operators.
- A GitOps rollback is a change of the desired state back to an earlier version, recorded as a new version in the store.
- git revert records a new commit that reverses an earlier one, which keeps the history complete.
Easy to mix up
- Drift is unintended movement of the actual state; a new commit changes the desired state on purpose. Both produce a difference that reconciliation closes.
- Sync status and health are different questions in Argo CD: OutOfSync means live differs from Git, Degraded means the application does not work.
- Desired state is configuration, not data: recreating a system from it gives the same behaviour, not the same database rows.
- Continuous is about recurrence, not speed: an agent that compares every few minutes is continuous, a pipeline that runs only on push is not.