Your organization is establishing a centralized GitOps workflow across staging and production environments to enforce policy-as-code and automatically detect and reconcile configuration drift for Google Cloud and Kubernetes resources using Google Cloud Config Sync. The team has established the following technical requirements: Manage cluster-scoped and namespace-scoped infrastructure configurations from an authoritative Git repository. Allow teams to organize resource manifests flexibly across subfolders without enforcing strict directory naming conventions (such as namespaces/ or cluster/). Configure the synchronizer in the dedicated system namespace to target the /deployments/prod directory on the main branch. Which configuration should you implement to establish this automated drift reconciliation pipeline?

Create a RootSync custom resource in the config-management-system namespace with spec.sourceFormat set to unstructured and spec.git pointing to the repository, directory /deployments/prod, and revision main.: ### What RootSync with Unstructured Format Is A **RootSync** object is a Kubernetes custom resource defined by Config Sync (`configsync.gke.io/v1beta1`) residing in the `config-management-system` namespace. It configures the root synchronizer agent responsible for pulling configurations from an authoritative version control repository (such as Git or OCI registries) and continuously reconciling cluster state against the declared manifests. ### How It Meets the Requirements - **Cluster and Namespace Scope Management**: `RootSync` operates with root-level privileges to manage both cluster-scoped resources (e.g., ClusterRoles, CRDs, Google Cloud resources via Config Connector) and namespace-scoped resources across the cluster. - **Flexible Directory Structure**: Setting `spec.sourceFormat: unstructured` enables the **unstructured repository** format. Unlike the legacy hierarchical format, unstructured repositories do not enforce rigid top-level folder conventions like `namespaces/`, `cluster/`, or `system/`, allowing teams to organize manifests by application, environment, or microservice. - **Targeting Directory and Revision**: Setting `spec.git.dir` to `/deployments/prod` and `spec.git.revision` to `main` explicitly instructs Config Sync to sync the specific environment configurations from the designated Git branch. ### Key Advantages and Capabilities - **Continuous Drift Correction**: Config Sync continuously monitors the live cluster state and automatically remediates unauthorized manual mutations back to the Git source of truth. - **Workload Identity Integration**: Authenticates securely to Google Cloud Source Repositories or external Git servers without long-lived static credentials. - **Multi-Environment Scalability**: Allows distinct branches or directories to serve as authoritative configurations for staging and production fleets. - **Config Controller Compatibility**: Integrates directly with Config Controller to manage GCP cloud resources declaratively. ### Why This Is Optimal Using a native `RootSync` resource configured with `unstructured` formatting is the Google-recommended pattern for scalable GitOps architectures. It provides root-level control while avoiding the architectural limitations of strict hierarchical directory trees.

Config Sync Rootsync Unstructured Drift Reconciliation | Professional Cloud DevOps Engineer

Config Sync Rootsync Unstructured Drift Reconciliation

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 organization is establishing a centralized GitOps workflow across staging and production environments to enforce policy-as-code and automatically detect and reconcile configuration drift for Google Cloud and Kubernetes resources using Google Cloud Config Sync.

The team has established the following technical requirements:

Manage cluster-scoped and namespace-scoped infrastructure configurations from an authoritative Git repository.
Allow teams to organize resource manifests flexibly across subfolders without enforcing strict directory naming conventions (such as namespaces/ or cluster/).
Configure the synchronizer in the dedicated system namespace to target the /deployments/prod directory on the main branch.

Which configuration should you implement to establish this automated drift reconciliation pipeline?

Create a RootSync custom resource in the config-management-system namespace with spec.sourceFormat set to unstructured and spec.git pointing to the repository, directory /deployments/prod, and revision main.

Create a RootSync custom resource in the default namespace with spec.sourceFormat set to hierarchy and spec.git.revision set to HEAD.

Deploy a ConfigManagement custom resource in the kube-system namespace with spec.sourceType set to git and spec.syncBranch set to main.

Create a RepoSync custom resource in the gatekeeper-system namespace with spec.sourceFormat set to hierarchy and spec.git pointing to directory /deployments/prod on the main branch.

Professional Cloud DevOps Engineer

Config Sync Rootsync Unstructured Drift Reconciliation

Related questions