Your enterprise manages multiple Google Kubernetes Engine (GKE) clusters grouped into staging and production fleets. Your platform engineering team needs to implement a fleet-wide GitOps architecture using Config Sync and Policy Controller that satisfies the following requirements: Enforce baseline cluster-level RBAC and Policy Controller security constraints centrally across all fleet members. Delegate application deployment lifecycle to individual application development teams within dedicated namespaces without granting them cluster-admin privileges. Structure configuration repositories according to Google-recommended GitOps best practices for multi-environment clarity, auditability, and team isolation. Eliminate static credentials by using native Google Cloud identity mechanisms. Which configuration architecture should you implement?

Configure a central unstructured Git repository managed by the platform team that deploys cluster-scoped RootSync objects for Policy Controller constraints, alongside namespace-scoped RepoSync objects pointing to dedicated application configuration repositories in WET folder structures; authenticate reconcilers using Workload Identity Federation for GKE.: ### What the Multi-Repository GitOps Architecture Is This architecture uses **Config Sync** with a multi-repository model that separates root platform configurations from delegated namespace configurations, managed through declarative Kubernetes Custom Resources (`RootSync` and `RepoSync`) across **GKE Enterprise fleets**. ### How it meets the requirements - **Centrally enforce security constraints**: A cluster-scoped `RootSync` managed by the platform team deploys cluster-wide RBAC and declarative **Policy Controller** constraints across all fleet clusters. - **Delegate application lifecycle safely**: Namespace-scoped `RepoSync` objects instantiate dedicated namespace reconcilers with limited permissions (`RoleBinding` scoped to the target namespace), allowing app teams to deploy resources without granting cluster-admin access. - **Follow GitOps best practices**: Using **unstructured repositories** provides maximum flexibility, while organizing environment variants in **WET (Write Everything Twice / fully-hydrated)** folder structures allows clear diffs, straightforward change requests, and easy auditing between staging and production. - **Eliminate static credentials**: Leveraging **Workload Identity Federation for GKE** allows Kubernetes reconciler service accounts to securely authenticate to Google Cloud and source repositories via IAM without storing long-lived keys or secrets in clusters. ### Key advantages and capabilities - **Security boundaries**: Separates security/platform concerns from application development. - **Unstructured format**: Enables reuse of Kustomize and Helm packages without strict directory hierarchies. - **Transparent state**: WET folder structures make the exact desired state visible without complex branch divergence. - **Native identity**: Eliminates token rotation overhead and credential leaks. ### Why this is optimal This approach aligns with Google Cloud recommended enterprise patterns by combining the delegated authority of multi-repo Config Sync, the declarative enforcement of Policy Controller, and IAM-based Workload Identity Federation.

Gke Fleet Config Sync Policy Controller Gitops Architecture | Professional Cloud DevOps Engineer

Gke Fleet Config Sync Policy Controller Gitops Architecture

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 manages multiple Google Kubernetes Engine (GKE) clusters grouped into staging and production fleets. Your platform engineering team needs to implement a fleet-wide GitOps architecture using Config Sync and Policy Controller that satisfies the following requirements:

Enforce baseline cluster-level RBAC and Policy Controller security constraints centrally across all fleet members.
Delegate application deployment lifecycle to individual application development teams within dedicated namespaces without granting them cluster-admin privileges.
Structure configuration repositories according to Google-recommended GitOps best practices for multi-environment clarity, auditability, and team isolation.
Eliminate static credentials by using native Google Cloud identity mechanisms.

Which configuration architecture should you implement?

Configure a central unstructured Git repository managed by the platform team that deploys cluster-scoped RootSync objects for Policy Controller constraints, alongside namespace-scoped RepoSync objects pointing to dedicated application configuration repositories in WET folder structures; authenticate reconcilers using Workload Identity Federation for GKE.

Configure a central Git repository containing application source code and deployment manifests together, define all namespace configurations using cluster-scoped RootSync objects directly, and use the client.lifecycle.config.k8s.io/mutation: ignore annotation on all Policy Controller constraints so application teams can override them locally.

Configure cluster-scoped RootSync objects to deploy Kubernetes Job resources that execute kubectl apply commands for Policy Controller constraints, use dynamic ClusterSelectors with DRY template rendering in a single monorepo for all environments, and store access tokens in cluster secrets.

Configure a single hierarchical Git repository containing abstract namespaces and CRDs in the cluster/ directory, manage both application and security configs within the same repository using long-lived Git branches (staging and prod), and authenticate the ConfigManagement Operator using Compute Engine default service accounts.

Professional Cloud DevOps Engineer

Gke Fleet Config Sync Policy Controller Gitops Architecture

Related questions