CGOA — GitOps Certified Associate
Pausing automation does not block every change
In one line
Stopping automated sync is not a lock that forbids every change. What you stopped and what is still possible must be written into the operating procedure together with evidence.
Why this was needed
After pausing deployments for a moment, you began an important inspection. But someone pressed a manual sync and the new configuration was applied. If you assumed that because you turned off automated sync nobody could change anything, you would misexplain the cause of the incident. An automation policy decides when the reconciler acts on its own. It is not a device that removes the user's request permissions or every other deployment path.
The term maintenance mode means something different from team to team. Whether it keeps comparing Git and only stops applying, whether it also forbids manual applying, and whether it blocks user traffic are all different. If you pack all these meanings into a single button on the screen, people work while imagining different states. This lab separates and observes comparison, automated apply, and manual apply.
How it works
After turning off the child's automation in the parent template, you commit the ConfigMap value two to Git. The Application can compare the new commit and show OutOfSync, but the actual ConfigMap may still hold the previous value one. This does not mean it could not read the repository. sync.revision points to the new commit, and only the actual data has the old value, so it is a state in which comparison and apply are separated. If it were a Git read failure, you would also have to investigate the conditions and the revision separately.
| Question | Evidence to check | What this alone does not tell you |
|---|---|---|
| Did it read the new Git? | The current sync.revision | Whether the actual data was applied |
| Is automated apply off? | enabled=false and repeated observation | Whether even manual apply permission is blocked |
| Was a manual apply made? | The operation result and the actual value | Whether automated apply was turned back on afterward |
| Did it return to normal automation? | The parent and child policies and the actual reflection of the new Git | Whether every external operating path has been verified |
Next, you manually sync the same commit explicitly. If the actual data changes to two while enabled=false is kept, you have directly confirmed that stopping automation and forbidding changes are different. You look together at the operationState's revision and phase, the initiatedBy information, and the ConfigMap data and UID. The initiatedBy username is metadata that can be carried in the request, so you do not claim that the string alone proves an authenticated actor's identity. In a preliminary experiment, the earlier automated=true mark sometimes remained after a manual request. Without relying only on that mark, you link the operation receipt the API accepted, the requested revision, and the data before and after applying to judge the actual behavior.
When you request a sync of Argo CD with kubectl, the operation is a top-level field of the Application, not inside spec. This request also causes an actual apply. Do not confuse it with a dry-run or a read-only query. This lab specifies the exact commit and does not use prune or force. The UIDs of the comparison ConfigMap and the Application are kept to the end. Whether to allow the same request in production must be reviewed together with RBAC, the approval procedure, sync windows, and other deployment paths.
What it looks like in the field
Instead of stopping all children, you may need to run only a specific Application manually for a while. The ApplicationSet's ignoreApplicationDifferences is the means by which the parent declares the child fields to exclude from comparison. If you specify a name, you can limit it to a specific child, and you can narrow the target field with jsonPointers. In this lab you make only the enabled field an exception. If you carelessly exclude the whole syncPolicy or the source, you can miss a much broader drift.
This exception changes the comparison between the ApplicationSet and the Application. It is not a setting that says to ignore the Git difference between the Application and the ConfigMap. Just because a name has ignore in it does not mean every ignore-type setting has the same target. Write out in sentences which field is not looked at when who compares whom. An exception document that omits the target is more likely to create a new misunderstanding than to solve the problem.
An exception also needs an end condition. Decide who removes it, until when it stays, and which new change after removal will verify automated apply. You cannot conclude that automation has been restored simply because the current screen is Synced. A state already matched manually is also Synced. In the lab you remove the exception so that the child follows the parent's true, and then check that the third Git value, three, is reflected automatically. You do not reuse an earlier success as the basis for the new verification.
There is also a separate trap when you make a field inside a list an exception. The MergePatch used by the ApplicationSet can replace a changed list wholesale, so a value made an exception can be overwritten by a change to another item. This lab narrows the scope to a single source and the scalar enabled field. It does not generalize that every combination of changes to a multi-source array is safe, and in that case you must additionally check the limitations in the official documentation and the actual results of applying.
What you will do in the next lab
You observe three times a state in which a change in Git is not applied automatically, and compare a manual apply of the same commit. After briefly using a named narrow exception, you remove it and verify automation with a new Git change. Three short observations are a learning sample and not proof of an indefinite ban on changes. In the final report, write separately the difference between stopping automation and blocking all deployments, and between internal observation and an operational guarantee. You can learn this difference without stopping the global controller or changing other teams' permissions.
Official documentation
- Requesting a sync with kubectl: Check where the operation and result fields are located.
- ApplicationSet resource modification control: Read about exceptions for a specific child and the limits of MergePatch.