Professional Cloud DevOps Engineer
Prepare and test your skills
Prepare and test your skills
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.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
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:
namespaces/ or cluster/)./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.
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.
Create a RootSync custom resource in the default namespace with spec.sourceFormat set to hierarchy and spec.git.revision set to HEAD.
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.
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.
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.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.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.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.
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.
Create a RootSync custom resource in the default namespace with spec.sourceFormat set to hierarchy and spec.git.revision set to HEAD.