A single ArgoCD instance managing a single OpenShift cluster is a reasonable starting point for a new integration platform. It stops being reasonable at the point where the integration estate spans separate clusters for development, staging, and production — with production split across a primary data centre in Riyadh and a DR site in Jeddah — and where each cluster has different network policies, different Vault backends, different resource quotas, and different approval gates before a deployment can proceed. At that point, the question is not whether to use GitOps, but how to structure multi-cluster GitOps so that the platform team can manage five clusters without five times the operational burden, and so that the governance rules for each environment are enforced by the system rather than by discipline.
ArgoCD ApplicationSets are the mechanism that makes multi-cluster GitOps tractable. A single ApplicationSet generator can template deployment configurations across all registered clusters, applying environment-specific overrides through Helm values or Kustomize patches, enforcing different sync policies per environment tier, and ensuring that a change merged to the main branch is automatically applied to development while requiring a manual approval gate before reaching production. The deployment governance — who can approve a production release, what tests must pass before promotion, what the rollback procedure is — is encoded in the ApplicationSet configuration, not in a runbook that someone might forget to follow.
What the regulator expects from deployment governance
SAMA’s Technology Risk Management framework and the Cyber Security Framework both treat change management for production systems as a Tier 1 control. The examination question is: can you demonstrate that no change reaches your production payment processing environment without passing through a defined approval workflow, that the change was tested in an equivalent pre-production environment, and that you can produce an audit trail of who approved the deployment and when? A GitOps deployment model — where every production change is a pull request with a merge approval, where ArgoCD applies only what is in the Git repository, and where the ArgoCD audit log records every sync event with the Git commit hash and timestamp — answers that question completely and automatically.
A multi-cluster ArgoCD deployment also answers the DR examination question: can you demonstrate that your DR environment runs the same version of every production service and would accept live traffic within your declared RTO? A cluster pair where ArgoCD is synchronising both production and DR from the same Git source, with the same Helm chart versions, provides a continuous answer: DR is always at the same version as production because ArgoCD keeps them aligned. Without GitOps, the honest answer to the DR version question at most banks is: “we believe they are aligned, but we last verified three months ago.”
The value of GitOps for a multi-cluster environment is not faster deployments. It is making the actual state of every cluster visible, diffable, and auditable against the declared state in Git at any moment.
The decisions that determine whether multi-cluster GitOps succeeds
Three decisions require leadership input before the platform team can design a multi-cluster ArgoCD deployment that will satisfy SAMA and remain operational under pressure. First: the cluster registration model. ArgoCD can manage clusters as an administrator (with a service account that has cluster-admin privileges) or as a namespace-scoped user (with privileges restricted to specific namespaces). The cluster-admin model is simpler to configure and supports cross-namespace resources; the namespace-scoped model is more secure and enforces a tighter separation between what ArgoCD can modify and what it cannot. For a regulated bank, namespace-scoped operation with explicit RBAC grants is the correct starting point — but it requires the platform team to understand what ArgoCD needs access to, which requires a design review before the first cluster is registered.
Second: the production approval gate. ArgoCD supports automated sync for all environments, or manual sync gates for specific environments. For production, the correct choice is a manual sync gate with a defined approval process: a named approver, an approval recorded in the Git pull request, and ArgoCD configured to sync only after the merge is approved by a designated reviewer. Implementing this in a way that SAMA will accept requires the approval process to be auditable — the pull request approval, the merge timestamp, and the ArgoCD sync event must all be traceable to the same change. Without that traceability, the governance exists in spirit but not in the audit log that the examination team will review.
Third: the ApplicationSet ownership model. ApplicationSets are powerful enough to deploy to every cluster simultaneously if misconfigured. A single typo in a generator template can create a sync wave that targets production when it was intended for development. The platform team must establish a review process for ApplicationSet changes that is at least as rigorous as the review process for application code changes — ideally more rigorous, because an ApplicationSet change can affect multiple clusters simultaneously. That review process requires a designated approver with expertise in the ArgoCD data model, not just a generic code reviewer.
For the engineering depth behind this decision — ArgoCD ApplicationSet generators, cluster registration patterns, sync waves and hooks, Argo Rollouts for progressive delivery, multi-cluster Vault integration, and the production checklist — see the companion Lab article: DevOps & Platform: Multi-Cluster GitOps.