Exam Professional Cloud DevOps Engineer topic 1 question 95 discussion

Option C is not as effective as Option D because it does not enforce the network policies and DaemonSet configurations. This means that unauthorized changes could still be made to the configurations. Config Sync is a tool that can be used to synchronize Kubernetes configurations across multiple clusters. However, it does not prevent unauthorized changes from being made to the configurations. Policy Controller is a tool that can be used to enforce Kubernetes configurations. It does this by monitoring the Kubernetes API for changes to the configurations and automatically reverting unauthorized changes. Therefore, Option D is a more secure and reliable option for ensuring that the network policies and DaemonSet are enforced and installed consistently across the three environments.

Why use Cloud Build? - Cloud Build allows you to automate rendering and deploying Kubernetes manifests. - It ensures that changes are version-controlled and applied consistently across all environments. Why use Config Sync? - Config Sync ensures that your GKE clusters stay in sync with the GitHub repository (source of truth). - It automatically detects and corrects drift, enforcing the desired state. - It is Google's recommended practice for managing multi-cluster configurations.

Use Cloud Build to render and deploy the network policies and the DaemonSet. Set up Config Sync to sync the configurations for the three environments. This approach uses Cloud Build for CI/CD processes and leverages Config Sync for GitOps practices, ensuring that your GKE environments are consistent with the configurations defined in your GitHub repositories. Config Sync will continuously reconcile the cluster state with the desired state in the repository, and Policy Controller which is part of Config Sync will enforce the network policies.

I will go for C. Cloud Build: Cloud Build is excellent for building and deploying configurations. It can be used to render your network policies and DaemonSet configurations from your GitHub repository.   Config Sync: Config Sync is specifically designed for managing and synchronizing configurations across multiple Kubernetes clusters.1 It allows you to define your desired state in a Git repository (your GitHub repo) and then automatically applies those configurations to your GKE clusters (development, staging, and production).2 This ensures consistency across environments and provides version control for your infrastructure configurations.

Its a toss up here. C hits all the keywords in "https://cloud.google.com/kubernetes-engine/enterprise/config-sync/docs/overview" - source of truth, gitops, but does not talk about enforcement. However, policy controller is a subset of configsync and it does handle enforcement. "Constraints can be applied directly to your clusters using the Kubernetes API, or distributed to a set of clusters from a centralized source, like a Git repository, by using Config Sync." https://cloud.google.com/kubernetes-engine/enterprise/policy-controller/docs/overview#constraints Really seems like a trick question leading you to D when C is the right answer with the knowledge that you would configure policy controller as a sub step when setting up config sync for your gitops.

This method leverages Cloud Build for rendering and deploying configurations, and Config Sync to ensure that the desired state specified in your GitHub repositories is consistently applied across all GKE clusters. This approach provides robust management and automatic synchronization, ensuring that configurations remain consistent across development, staging, and production environments.

Should be D

Policy Controller can enforce the configurations specified in the repositories, ensuring consistency across the environments and enforcing compliance with defined policies.

Option C is the right one." Cloud Build: Ideal for building and deploying software artifacts based on your GitHub repositories, your chosen source of truth. Renders your network policies and DaemonSet configurations, ensuring consistency before deployment. Config Sync: Designed for configuration management across GKE clusters. Continuously synchronizes your rendered configurations (network policies and DaemonSet) from GitHub to all three environments (development, staging, production). Provides automated drift detection and remediation, ensuring consistency remains enforced.

Option D is the recommended approach for ensuring consistency across the three Google Kubernetes Engine (GKE) environments—development, staging, and production—while adhering to Google-recommended practices. By using Cloud Build to render and deploy network policies and a DaemonSet, and implementing Policy Controller, you can enforce configurations uniformly across environments. Policy Controller ensures that the deployed configurations align with your desired state, providing a consistent and policy-driven approach. This method leverages the declarative nature of Kubernetes configurations, facilitating configuration management. Overall, Option D combines infrastructure-as-code principles with policy enforcement to maintain consistency and enhance manageability across GKE clusters in different environments.

I would go for D as well

"Policy Controller can catch and enforce policy violations on those resources before they are deployed. " https://cloud.google.com/anthos-config-management/docs/concepts/config-controller-overview