Your enterprise organization is designing an automated GitOps workflow across multi-tenant Google Kubernetes Engine (GKE) clusters to manage infrastructure configurations and Kubernetes policies. The design must satisfy the following operational requirements: Maintain strict isolation between cluster-scoped platform resources and tenant-scoped application resources. Isolate reconciler execution to prevent failure in one tenant repository from blocking deployments in others. Continuously monitor Git repositories, detect configuration drift caused by manual kubectl interventions, and automatically remediate the drift back to the declared source state. How should you configure the GitOps synchronization architecture using Config Sync?

Configure a RootSync object for cluster-wide platform resources and distinct RepoSync objects for individual tenant namespaces, enabling dedicated reconciler instances with git-sync sidecars to independently poll repositories and enforce desired state.: ### What Config Sync Multi-Instancing Is **Config Sync** is a continuous delivery and GitOps management tool for Kubernetes that automatically reconciles the state of a cluster with configurations stored in a source of truth such as a Git repository, OCI registry, or Helm repository. Its multi-instancing architecture utilizes **`RootSync`** and **`RepoSync`** Custom Resources to manage cluster-level and namespace-level resources independently. ### How It Meets the Scenario Requirements - **Tenant and Platform Isolation**: A `RootSync` object manages cluster-scoped configurations and platform foundations, while `RepoSync` objects restrict individual tenant teams to their specific Kubernetes namespaces. - **Independent Fault Domains**: In Config Sync, each `RootSync` and `RepoSync` custom resource spawns its own dedicated reconciler deployment and Pod. The reconciler includes a dedicated **`git-sync`** sidecar container that polls the assigned repository branch and directory path. If a tenant's repository fails to parse or loses authentication, other tenant reconcilers continue running unaffected. - **Automated Drift Detection and Remediation**: Config Sync reconcilers continuously monitor the live cluster state against the declared state in Git. If an operator makes manual changes using `kubectl`, Config Sync detects the discrepancy and immediately applies the version-controlled configuration, remediating the configuration drift. ### Key Advantages and Capabilities - **Decentralized Team Ownership**: Platform administrators manage the core cluster via root repositories while development teams independently control their application namespaces. - **Auditability and Rollback**: All infrastructure changes are tracked through standard Git commit histories, enabling simple rollbacks via `git revert`. - **Scalable Reconciliation**: Multi-instanced reconciler pods distribute API server traffic and isolate resource synchronization workloads. ### Why This Is Optimal Using native `RootSync` and `RepoSync` objects provides declarative, in-cluster reconciliation that runs continuously without external CI/CD push triggers, enforcing continuous compliance and automatic drift self-healing across isolated tenant boundaries.

Config Sync Gitops Rootsync Reposync Drift Remediation | Professional Cloud DevOps Engineer

Config Sync Gitops Rootsync Reposync Drift Remediation

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

Your enterprise organization is designing an automated GitOps workflow across multi-tenant Google Kubernetes Engine (GKE) clusters to manage infrastructure configurations and Kubernetes policies.

The design must satisfy the following operational requirements:

Maintain strict isolation between cluster-scoped platform resources and tenant-scoped application resources.
Isolate reconciler execution to prevent failure in one tenant repository from blocking deployments in others.
Continuously monitor Git repositories, detect configuration drift caused by manual kubectl interventions, and automatically remediate the drift back to the declared source state.

How should you configure the GitOps synchronization architecture using Config Sync?

Configure an external cron job that runs the nomos vet command against the repository and deploys manifests using Azure Pipelines service connections.

Deploy a single RootSync object configured to synchronize all cluster-level and namespace-level manifests using a monolithic Git repository structure with directory filters.

Configure a Cloud Build trigger connected to the repository that executes kubectl apply on push events whenever a commit is merged to the main branch.

Configure a RootSync object for cluster-wide platform resources and distinct RepoSync objects for individual tenant namespaces, enabling dedicated reconciler instances with git-sync sidecars to independently poll repositories and enforce desired state.

Professional Cloud DevOps Engineer

Config Sync Gitops Rootsync Reposync Drift Remediation

Related questions