{"id":687,"date":"2026-04-15T00:38:33","date_gmt":"2026-04-15T00:38:33","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-config-controller-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-distributed-hybrid-and-multicloud\/"},"modified":"2026-04-15T00:38:33","modified_gmt":"2026-04-15T00:38:33","slug":"google-cloud-config-controller-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-distributed-hybrid-and-multicloud","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-config-controller-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-distributed-hybrid-and-multicloud\/","title":{"rendered":"Google Cloud Config Controller Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Distributed, hybrid, and multicloud"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Distributed, hybrid, and multicloud<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Config Controller is a Google Cloud managed service that provides a hosted Kubernetes control plane specifically designed to manage Google Cloud resources using Kubernetes-style APIs and workflows.<\/p>\n\n\n\n<p>In simple terms: you create a Config Controller instance, connect to it with <code>kubectl<\/code>, and apply Kubernetes manifests that represent Google Cloud resources (such as Cloud Storage buckets or Pub\/Sub topics). The service then continuously reconciles those manifests into real Google Cloud resources.<\/p>\n\n\n\n<p>Technically, Config Controller runs Google-supported controllers (most importantly <strong>Config Connector<\/strong>) in a Google-managed Kubernetes environment. Config Connector exposes Google Cloud resources as Kubernetes Custom Resource Definitions (CRDs). When you apply a custom resource (CR) to the cluster, Config Connector calls Google Cloud APIs to create\/update\/delete the corresponding infrastructure and continuously keeps it aligned with the desired state you declared.<\/p>\n\n\n\n<p>The main problem it solves is <strong>standardizing infrastructure management<\/strong> around Kubernetes and GitOps practices\u2014especially for distributed, hybrid, and multicloud platform teams that already operate Kubernetes heavily and want consistent, policy-governed, auditable infrastructure-as-code (IaC) for Google Cloud.<\/p>\n\n\n\n<blockquote>\n<p>Naming note: Some older materials may refer to \u201cAnthos Config Controller\u201d. The current product name in Google Cloud documentation is <strong>Config Controller<\/strong>. Verify current naming and packaging in the official docs if you\u2019re reading older blog posts or labs.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Config Controller?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>Config Controller\u2019s purpose is to provide a <strong>managed control plane<\/strong> for declaratively managing Google Cloud resources using Kubernetes APIs (via Config Connector), enabling GitOps-style workflows, policy enforcement, and consistent operational patterns.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Declarative management of Google Cloud resources<\/strong> using Kubernetes CRDs (via Config Connector).<\/li>\n<li><strong>Continuous reconciliation<\/strong>: desired state in Kubernetes manifests is kept in sync with actual Google Cloud state.<\/li>\n<li><strong>Kubernetes-native tooling<\/strong>: use <code>kubectl<\/code>, Kubernetes RBAC, namespaces, and (optionally) GitOps tooling patterns.<\/li>\n<li><strong>Separation of concerns<\/strong>: run a \u201cmanagement cluster\u201d for infrastructure configuration, separate from application clusters.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (conceptual)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Config Controller instance<\/strong>: the managed Kubernetes control plane you create in a project\/region.<\/li>\n<li><strong>Config Connector<\/strong>: controllers + CRDs that model Google Cloud resources (e.g., <code>StorageBucket<\/code>, <code>PubSubTopic<\/code>, IAM policies).<\/li>\n<li><strong>IAM identity used by controllers<\/strong>: a Google Cloud service account (or managed identity) that Config Connector uses to call Google Cloud APIs.<\/li>\n<li><strong>Kubernetes API endpoint<\/strong>: where you apply manifests and read reconciliation status.<\/li>\n<\/ul>\n\n\n\n<p>Depending on how Google packages the service at the time you deploy, Config Controller may also support integration with policy and GitOps components commonly used with Anthos Config Management. Only enable\/assume components that are explicitly documented for your version\u2014<strong>verify in official docs<\/strong> if you expect built-in Policy Controller or Config Sync functionality.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed control plane \/ managed Kubernetes-based configuration service<\/strong><\/li>\n<li>It is not a general-purpose application runtime like GKE; it is designed for infrastructure configuration and reconciliation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (how it\u2019s scoped)<\/h3>\n\n\n\n<p>Config Controller is typically:\n&#8211; <strong>Project-scoped<\/strong> (created inside a Google Cloud project)\n&#8211; <strong>Region-scoped<\/strong> (you choose a region for the instance)<\/p>\n\n\n\n<p>Exact region availability and feature set can vary\u2014<strong>verify in official docs<\/strong>:\n&#8211; Docs: https:\/\/cloud.google.com\/config-controller\/docs<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Fit in the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Config Controller sits at the intersection of:\n&#8211; <strong>Google Cloud infrastructure APIs<\/strong> (what ultimately gets created\/modified)\n&#8211; <strong>Kubernetes APIs<\/strong> (how you declare desired state)\n&#8211; <strong>Distributed, hybrid, and multicloud operating models<\/strong> (where central platform teams want consistent configuration workflows)<\/p>\n\n\n\n<p>It complements (not replaces) other IaC tools like Terraform:\n&#8211; Terraform is imperative\/planned execution based on state files.\n&#8211; Config Controller is Kubernetes-style desired state with ongoing reconciliation.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Config Controller?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Standardize provisioning<\/strong>: consistent workflows across teams, especially if teams already know Kubernetes.<\/li>\n<li><strong>Improve auditability<\/strong>: changes are visible as Kubernetes object changes (and often through Git history if using GitOps).<\/li>\n<li><strong>Reduce configuration drift<\/strong>: reconciliation continuously corrects drift from the declared state.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Kubernetes-native IaC<\/strong>: use <code>kubectl<\/code>, namespaces, RBAC, admission controls, and familiar patterns.<\/li>\n<li><strong>Model cloud resources as APIs<\/strong>: Google Cloud resources become objects you can validate, template, and manage systematically.<\/li>\n<li><strong>Separation of config and apps<\/strong>: run a dedicated config control plane instead of granting app clusters broad infra permissions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Continuous reconciliation<\/strong> helps keep infra correct even when manual console changes happen (depending on resource and permissions).<\/li>\n<li><strong>Kubernetes-style status and events<\/strong>: you can inspect conditions, last reconcile status, and errors using standard tooling.<\/li>\n<li><strong>Easier multi-team delegation<\/strong>: use Kubernetes namespaces + RBAC to delegate resource management boundaries.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Centralize IAM<\/strong>: restrict who can create what via Kubernetes RBAC and controlled service accounts used by controllers.<\/li>\n<li><strong>Policy-based guardrails<\/strong> (where supported): enforce requirements like labels, encryption settings, allowed locations, or naming conventions.<\/li>\n<li><strong>Change control<\/strong>: tie changes to Git PRs and approvals (GitOps), and track applied objects.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Works well for organizations that manage <strong>many resources<\/strong> across teams and want a consistent interface and drift control.<\/li>\n<li>Offloads control plane management to Google (you manage fewer moving parts).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Config Controller if you:\n&#8211; Operate Kubernetes broadly and want <strong>Kubernetes-native infrastructure management<\/strong>.\n&#8211; Want a <strong>dedicated management control plane<\/strong> for Google Cloud resources.\n&#8211; Need <strong>drift reconciliation<\/strong> and (optionally) policy enforcement for infra.\n&#8211; Want to build a platform where teams self-serve infrastructure through Kubernetes APIs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Avoid or reconsider Config Controller if you:\n&#8211; Need a <strong>simple one-time provisioning<\/strong> workflow and already have mature Terraform pipelines\u2014Config Controller adds another control plane.\n&#8211; Need to manage many <strong>non\u2013Google Cloud<\/strong> resources (Config Controller is focused on Google Cloud resources via Config Connector).\n&#8211; Don\u2019t want to adopt Kubernetes operational patterns for infra management.\n&#8211; Have strict network constraints that prevent required API connectivity (for example, restricted egress requirements without an approved design). Verify networking requirements in official docs.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Config Controller used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Regulated industries (finance, healthcare, public sector) that need auditable, policy-controlled infrastructure provisioning.<\/li>\n<li>SaaS and tech companies with platform engineering teams and Kubernetes-heavy operations.<\/li>\n<li>Retail, media, and gaming with multi-team environments and frequent environment creation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams building \u201cinternal developer platforms\u201d.<\/li>\n<li>DevOps\/SRE teams standardizing provisioning and reducing drift.<\/li>\n<li>Cloud Center of Excellence (CCoE) teams enforcing governance.<\/li>\n<li>Security engineering teams implementing guardrails for resource creation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads and architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Kubernetes-centric organizations using GitOps.<\/li>\n<li>Organizations running many application clusters (GKE, on-prem Kubernetes, other clouds) that want consistent infra provisioning patterns.<\/li>\n<li>Hybrid environments where a centralized config plane manages cloud resources for multiple environments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A central project hosting a Config Controller instance managing shared infrastructure (networking, IAM, logging sinks).<\/li>\n<li>One Config Controller per environment (dev\/stage\/prod) to isolate permissions and blast radius.<\/li>\n<li>One Config Controller per business unit, with strict namespace and RBAC boundaries.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Dev\/test<\/strong>: prototyping IaC and CRD-based provisioning; learning Kubernetes-style infra.<\/li>\n<li><strong>Production<\/strong>: central governance, drift control, consistent self-service provisioning with strong IAM boundaries and audit.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Config Controller is a strong fit.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) GitOps for Google Cloud infrastructure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams want PR-based review and automated rollout of Google Cloud resources.<\/li>\n<li><strong>Why Config Controller fits<\/strong>: Manifests can live in Git; reconciler applies desired state continuously.<\/li>\n<li><strong>Scenario<\/strong>: A platform repo defines Storage buckets, Pub\/Sub topics, and IAM bindings. A merge to <code>main<\/code> triggers sync to Config Controller.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Centralized \u201cinfra management cluster\u201d pattern<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Application clusters should not have broad IAM to create cloud resources.<\/li>\n<li><strong>Why it fits<\/strong>: Config Controller is a dedicated control plane for provisioning.<\/li>\n<li><strong>Scenario<\/strong>: App clusters run workloads only; Config Controller provisions Cloud SQL, buckets, and Pub\/Sub topics per namespace\/team.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Self-service resource provisioning for product teams<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Platform team is overloaded with ticket-based provisioning requests.<\/li>\n<li><strong>Why it fits<\/strong>: Kubernetes RBAC + namespaces can delegate resource creation safely.<\/li>\n<li><strong>Scenario<\/strong>: Team A gets a namespace and permissions to create Pub\/Sub topics and subscriptions within approved constraints.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Drift control and reconciliation for critical infra<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Manual console edits cause drift and outages.<\/li>\n<li><strong>Why it fits<\/strong>: Continuous reconciliation detects and attempts to correct drift.<\/li>\n<li><strong>Scenario<\/strong>: A logging sink must always exist with specific filters. If someone deletes it, it is recreated (depending on the resource and permissions).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Policy guardrails for compliant resource creation (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams create resources without required labels, encryption, or approved regions.<\/li>\n<li><strong>Why it fits<\/strong>: Policy frameworks can prevent non-compliant manifests from being accepted.<\/li>\n<li><strong>Scenario<\/strong>: Prevent creation of buckets without retention policy and CMEK (if required by policy), enforced at admission time.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Multi-environment standardization (dev\/stage\/prod)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Environments drift because each is provisioned differently.<\/li>\n<li><strong>Why it fits<\/strong>: Same manifest templates applied to each environment\u2019s Config Controller.<\/li>\n<li><strong>Scenario<\/strong>: A standardized set of resources (topics, service accounts, buckets) is applied with environment-specific parameters.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Namespace-based tenancy for shared platform services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Multiple teams share a platform but need isolation and least privilege.<\/li>\n<li><strong>Why it fits<\/strong>: Kubernetes namespaces + RBAC segment who can manage which resources.<\/li>\n<li><strong>Scenario<\/strong>: Each team has a namespace with only the CRDs and permissions they need.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Infrastructure provisioning as part of CI pipelines (Kubernetes-native)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: CI needs to provision ephemeral environments quickly and consistently.<\/li>\n<li><strong>Why it fits<\/strong>: CI can apply manifests to Config Controller using standard Kubernetes authentication.<\/li>\n<li><strong>Scenario<\/strong>: PR validation creates a short-lived Pub\/Sub topic and bucket; cleanup deletes Kubernetes resources which deletes cloud resources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Standardizing IAM and service accounts declaratively<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: IAM changes are hard to track and review.<\/li>\n<li><strong>Why it fits<\/strong>: IAM bindings can be managed as CRs (verify which IAM resources are supported in Config Connector).<\/li>\n<li><strong>Scenario<\/strong>: Platform team manages project-level IAM bindings and workload identities through manifests reviewed in Git.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Managing shared networking and security resources<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Networking resources must follow strict patterns and be repeatable.<\/li>\n<li><strong>Why it fits<\/strong>: Declarative definitions reduce variability.<\/li>\n<li><strong>Scenario<\/strong>: Provision Cloud DNS zones, firewall rules, or load balancing components (only if supported by Config Connector resource coverage).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Controlled resource lifecycle tied to Kubernetes objects<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Orphaned resources accumulate and increase cost.<\/li>\n<li><strong>Why it fits<\/strong>: Deleting the Kubernetes object can delete the cloud resource (subject to deletion policy and finalizers).<\/li>\n<li><strong>Scenario<\/strong>: Delete a <code>StorageBucket<\/code> CR and the bucket is deleted, reducing leftovers.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Platform blueprint as reusable manifests<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: New teams need a secure \u201cstarter kit\u201d of cloud resources.<\/li>\n<li><strong>Why it fits<\/strong>: Provide a repo with pre-approved manifests and policies.<\/li>\n<li><strong>Scenario<\/strong>: A new microservice team applies a \u201cblueprint\u201d directory and gets standardized storage, topics, and IAM bindings.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<blockquote>\n<p>Feature availability can vary by release and configuration. Always cross-check with the official Config Controller and Config Connector docs.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">6.1 Managed Config Controller instance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides a Google-managed Kubernetes control plane dedicated to configuration management.<\/li>\n<li><strong>Why it matters<\/strong>: You avoid managing your own \u201cmanagement cluster\u201d lifecycle.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster onboarding and fewer operational tasks compared to self-managed Kubernetes.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: It is not intended as a general workload cluster; treat it as a control plane for infrastructure.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.2 Config Connector CRDs for Google Cloud resources<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Exposes Google Cloud resources as Kubernetes APIs (CRDs).<\/li>\n<li><strong>Why it matters<\/strong>: Infrastructure can be managed with the same tooling and patterns as Kubernetes resources.<\/li>\n<li><strong>Practical benefit<\/strong>: Declarative provisioning with <code>kubectl apply<\/code>, status conditions, and event-driven troubleshooting.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Not all Google Cloud services\/resources may be supported. Coverage varies by Config Connector version\u2014verify supported resources in docs:<\/li>\n<li>https:\/\/cloud.google.com\/config-connector\/docs\/reference\/overview<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.3 Continuous reconciliation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Continuously compares desired state (Kubernetes objects) to actual state (Google Cloud) and reconciles differences.<\/li>\n<li><strong>Why it matters<\/strong>: Reduces drift and helps enforce standards.<\/li>\n<li><strong>Practical benefit<\/strong>: Infrastructure stays consistent even with manual changes (within what the controllers can correct).<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Some changes may be rejected by APIs, blocked by IAM, or require replacement; reconciliation might loop on errors until fixed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.4 Kubernetes RBAC and namespace isolation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Uses Kubernetes-native RBAC to control who can create\/modify which objects.<\/li>\n<li><strong>Why it matters<\/strong>: Enables platform teams to delegate safely.<\/li>\n<li><strong>Practical benefit<\/strong>: Fine-grained access control for different teams\/environments.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: RBAC controls Kubernetes objects; the controller\u2019s Google Cloud IAM still determines what can actually be created in Google Cloud.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.5 Status reporting and observability via Kubernetes objects<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Writes reconcile status, conditions, and events into Kubernetes resources.<\/li>\n<li><strong>Why it matters<\/strong>: Troubleshooting becomes <code>kubectl describe<\/code> instead of digging through ad-hoc scripts.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster diagnosis of IAM\/API\/quota errors.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: For deeper root cause, you still need Google Cloud logs and audit logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.6 Integration with Google Cloud IAM<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Controllers authenticate to Google Cloud APIs using a configured identity (service account).<\/li>\n<li><strong>Why it matters<\/strong>: Least privilege can be implemented centrally.<\/li>\n<li><strong>Practical benefit<\/strong>: One well-governed identity can manage approved resource types.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Mis-scoped permissions are a common failure point; start narrow and expand based on observed needs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.7 Deletion lifecycle control (finalizers, deletion policies)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Ensures safe deletion of resources by coordinating Kubernetes deletion with cloud deletion.<\/li>\n<li><strong>Why it matters<\/strong>: Prevents accidental orphaning or unintended deletion.<\/li>\n<li><strong>Practical benefit<\/strong>: Predictable cleanup tied to Kubernetes workflows.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Deletion behavior can be controlled by annotations\/policies; verify current behavior in Config Connector docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.8 Compatibility with GitOps workflows (pattern)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Enables a GitOps model where Git is the source of truth and the cluster reconciles to it.<\/li>\n<li><strong>Why it matters<\/strong>: Repeatable, auditable changes.<\/li>\n<li><strong>Practical benefit<\/strong>: PR reviews, rollbacks, and environment promotion.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: The GitOps engine (e.g., Config Sync or third-party controllers) is a separate component. If you rely on built-in integration, <strong>verify in official docs<\/strong> what is included with Config Controller.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>At a high level, Config Controller works like this:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>You create a <strong>Config Controller instance<\/strong> in a Google Cloud project and region.<\/li>\n<li>You connect to its Kubernetes API endpoint (typically with <code>kubectl<\/code>).<\/li>\n<li>You apply Kubernetes manifests that include Config Connector CRDs (for example, a <code>StorageBucket<\/code> object).<\/li>\n<li>Config Connector controllers watch these objects and call the relevant <strong>Google Cloud APIs<\/strong>.<\/li>\n<li>The controller updates Kubernetes object <strong>status<\/strong> fields (conditions, errors, reconcile state).<\/li>\n<li>If drift occurs, reconciliation attempts to bring the real resource back to the declared desired state.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control flow<\/strong>: <code>kubectl apply<\/code> \u2192 Kubernetes API server \u2192 etcd\/state \u2192 controller watch loop \u2192 Google Cloud API calls \u2192 status updates.<\/li>\n<li><strong>Data plane<\/strong>: The actual data (bucket contents, Pub\/Sub messages) is not part of Config Controller. Config Controller manages control-plane resources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>Common integrations in Google Cloud environments include:\n&#8211; <strong>IAM<\/strong>: service accounts and roles used for resource creation.\n&#8211; <strong>Cloud Audit Logs<\/strong>: track API calls made by Config Connector identity.\n&#8211; <strong>Cloud Logging\/Monitoring<\/strong>: observe controller logs and resource-level operations (exact integration depends on managed environment and configured sinks).\n&#8211; <strong>VPC networking<\/strong>: endpoint access patterns (private\/public) depend on instance configuration\u2014verify networking options in docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>Config Controller depends on:\n&#8211; Google Cloud APIs for the resources you manage (e.g., <code>storage.googleapis.com<\/code>, <code>pubsub.googleapis.com<\/code>).\n&#8211; IAM permissions for the controller identity.\n&#8211; Underlying managed Kubernetes components (operated by Google).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Admin access<\/strong>: typically via Google Cloud IAM to get cluster credentials and Kubernetes RBAC to perform actions in the cluster.<\/li>\n<li><strong>Controller access to Google Cloud<\/strong>: a Google Cloud identity (service account) authorized with least privilege for the resources you want to manage.<\/li>\n<li><strong>Audit<\/strong>: Google Cloud audit logs record API calls made by the controller identity; Kubernetes audit logs availability depends on the managed offering\u2014verify.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<p>Config Controller is created in a region and typically attaches to a VPC\/subnet you provide or select, depending on provisioning mode.\nKey networking considerations:\n&#8211; The controller must reach Google Cloud APIs (either through public endpoints or Private Google Access patterns).\n&#8211; Your operator machine\/CI runner must reach the Kubernetes API endpoint (possibly via VPN, bastion, or private access).\nBecause networking options can evolve, <strong>verify current networking requirements<\/strong>:\n&#8211; https:\/\/cloud.google.com\/config-controller\/docs<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use Kubernetes events and object status for first-level troubleshooting.<\/li>\n<li>Use Google Cloud Audit Logs to understand what API calls were made and denied.<\/li>\n<li>Consider organization policies, quota management, and standardized labels to keep governance consistent.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  Dev[Engineer \/ CI] --&gt;|kubectl apply| K8sAPI[Kubernetes API&lt;br\/&gt;Config Controller]\n  K8sAPI --&gt; CC[Config Connector&lt;br\/&gt;controllers]\n  CC --&gt;|Google Cloud APIs| GCP[(Google Cloud Resources)]\n  CC --&gt;|status\/conditions| K8sAPI\n  GCP --&gt; Audit[Cloud Audit Logs]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Org[Google Cloud Organization]\n    subgraph NetProject[Shared VPC \/ Network Project]\n      VPC[VPC + Subnets]\n      VPN[VPN\/Interconnect]\n    end\n\n    subgraph PlatformProject[Platform Project]\n      CCInst[Config Controller Instance&lt;br\/&gt;Regional]\n      RBAC[Kubernetes RBAC&lt;br\/&gt;Namespaces]\n      SA[Controller Service Account&lt;br\/&gt;(least privilege)]\n      Logs[Cloud Logging \/ Monitoring]\n    end\n\n    subgraph AppProjects[Application Projects]\n      Resources[(Buckets, Topics,&lt;br\/&gt;IAM, etc.)]\n    end\n  end\n\n  Dev2[Platform Engineers \/ CI] --&gt;|Private access via VPN| CCInst\n  CCInst --&gt; RBAC\n  CCInst --&gt;|Uses SA| SA\n  SA --&gt;|Calls APIs| Resources\n  Resources --&gt; Logs\n  CCInst --&gt; Logs\n  VPC --- CCInst\n  VPN --- VPC\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/project requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Google Cloud account with a <strong>billing-enabled<\/strong> project.<\/li>\n<li>Permissions to enable APIs, create a Config Controller instance, and manage IAM.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>The exact roles can vary based on organizational policies and how Config Controller is provisioned. Typically you need:\n&#8211; Project-level permissions to create\/configure Config Controller.\n&#8211; Permissions to enable required APIs.\n&#8211; Permissions to grant IAM roles to the controller\u2019s service account.<\/p>\n\n\n\n<p>Start by reviewing official prerequisites:\n&#8211; https:\/\/cloud.google.com\/config-controller\/docs\/quickstart (verify exact URL and steps)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Billing must be enabled for the project.<\/li>\n<li>You will pay for:<\/li>\n<li>Config Controller managed components (pricing model depends on current Anthos\/Config Controller packaging).<\/li>\n<li>Any Google Cloud resources created (buckets, topics, etc.).<\/li>\n<li>Network egress, logging, and other indirect usage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>gcloud<\/code> (Google Cloud CLI): https:\/\/cloud.google.com\/sdk\/docs\/install<\/li>\n<li><code>kubectl<\/code> (often installed via <code>gcloud components install kubectl<\/code> or via your package manager)<\/li>\n<li>Git (optional but recommended for GitOps workflows)<\/li>\n<\/ul>\n\n\n\n<p>You may also need a specific <code>gcloud<\/code> component for Anthos\/Config Controller commands depending on the current tooling. Install\/update components as directed in the official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Config Controller is regional; available regions may be limited.<\/li>\n<li>Verify current regions in official docs:<\/li>\n<li>https:\/\/cloud.google.com\/config-controller\/docs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>Potential quotas\/limits to check (varies by project and org policy):\n&#8211; API rate limits for managed services (Storage, Pub\/Sub, IAM).\n&#8211; Project resource limits (number of buckets, topics, service accounts).\n&#8211; Any Config Controller instance limits per project\/region (verify in docs).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services\/APIs<\/h3>\n\n\n\n<p>The required APIs depend on what you create, but typically include:\n&#8211; Config Controller \/ Anthos-related APIs (verify exact API names in docs)\n&#8211; Kubernetes Engine \/ GKE-related APIs (if required by provisioning flow)\n&#8211; Resource Manager API\n&#8211; IAM API\n&#8211; Service Usage API\n&#8211; APIs for the resources you will create (e.g., Cloud Storage API, Pub\/Sub API)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Config Controller pricing can change depending on Google Cloud packaging (for example, how it is bundled with Anthos offerings). Do not rely on third-party estimates.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Official pricing references<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Start with the Config Controller docs, which link to the current billing model:<\/li>\n<li>https:\/\/cloud.google.com\/config-controller\/docs<\/li>\n<li>Anthos pricing (often relevant for configuration management services):<\/li>\n<li>https:\/\/cloud.google.com\/anthos\/pricing<\/li>\n<li>Google Cloud Pricing Calculator:<\/li>\n<li>https:\/\/cloud.google.com\/products\/calculator<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (what you\u2019re typically billed for)<\/h3>\n\n\n\n<p>You should plan for these cost categories:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Config Controller managed service charges<\/strong>\n   &#8211; Could be billed per instance, per vCPU, per hour, or under an Anthos subscription model.\n   &#8211; <strong>Verify current SKUs and billing dimensions<\/strong> in official pricing pages and your Cloud Billing SKU list.<\/p>\n<\/li>\n<li>\n<p><strong>Underlying compute\/networking<\/strong>\n   &#8211; Even when Google manages the control plane, there may be billable infrastructure in your project (depending on how the service is implemented).\n   &#8211; Networking (NAT, VPN, egress) can add cost.<\/p>\n<\/li>\n<li>\n<p><strong>Resources you create<\/strong>\n   &#8211; Buckets, Pub\/Sub topics\/subscriptions, IAM, logging sinks, etc. are billed by their own service pricing.<\/p>\n<\/li>\n<li>\n<p><strong>Logging\/monitoring<\/strong>\n   &#8211; Cloud Logging ingestion\/retention and Cloud Monitoring metrics can create ongoing costs, especially at scale.<\/p>\n<\/li>\n<li>\n<p><strong>Network egress<\/strong>\n   &#8211; Egress from the region to the internet or other regions can be a meaningful cost driver.\n   &#8211; Calls to Google APIs are typically not billed as egress when staying within Google\u2019s network, but configuration and network path matter\u2014verify for your design.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Config Controller itself typically does <strong>not<\/strong> have a \u201cfree tier\u201d in the way some managed services do.<\/li>\n<li>Some resources you create may have free tiers (e.g., limited Cloud Logging, Pub\/Sub, or Storage usage), but these are service-specific and subject to change. Always verify current free-tier limits in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Key cost drivers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Number of Config Controller instances (per environment, per region, per team).<\/li>\n<li>Controller activity volume (number of managed resources and change frequency).<\/li>\n<li>Logging verbosity and retention.<\/li>\n<li>Network design (private access, NAT gateways, cross-region traffic).<\/li>\n<li>The cost of actual managed resources (often dominates total spend).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs to watch<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Logging ingestion<\/strong> from controllers and audit logs.<\/li>\n<li><strong>NAT gateway<\/strong> costs if you route outbound traffic through Cloud NAT.<\/li>\n<li><strong>Over-provisioning environments<\/strong>: multiple config planes per team can add overhead.<\/li>\n<li><strong>Orphaned resources<\/strong> if deletion is blocked by policies\/finalizers.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>one instance per environment<\/strong> (dev\/stage\/prod) instead of per team unless required.<\/li>\n<li>Reduce noisy logs and set retention appropriately (balance compliance needs).<\/li>\n<li>Use labels and budgets; alert on unexpected resource creation.<\/li>\n<li>Implement policy guardrails to prevent expensive resources from being provisioned unintentionally.<\/li>\n<li>Prefer regional designs that avoid cross-region egress where possible.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (no fabricated prices)<\/h3>\n\n\n\n<p>A low-cost starter setup typically includes:\n&#8211; 1 Config Controller instance in a single region\n&#8211; Managing a small number of low-cost resources (e.g., a couple of buckets and topics)\n&#8211; Minimal logging retention<\/p>\n\n\n\n<p>To estimate accurately:\n1. Identify whether Config Controller is billed per instance\/hour or via Anthos subscription in your org.\n2. Add costs for the resources you plan to create (Storage, Pub\/Sub).\n3. Include logging ingestion and any NAT\/egress.<\/p>\n\n\n\n<p>Use:\n&#8211; Pricing calculator: https:\/\/cloud.google.com\/products\/calculator\n&#8211; Billing export to BigQuery for ongoing cost breakdown (recommended in production).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, the main drivers are usually:\n&#8211; Multiple environments\/regions (2\u20136+ instances)\n&#8211; Hundreds to thousands of managed resources\n&#8211; High change frequency (CI-driven)\n&#8211; Governance overhead (audit logs, SIEM export)\n&#8211; Private networking (VPN\/Interconnect, NAT)<\/p>\n\n\n\n<p>A practical approach:\n&#8211; Start with one instance per environment.\n&#8211; Track total managed resources count.\n&#8211; Review logging costs monthly.\n&#8211; Set budget alerts per project and per environment.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab provisions a Config Controller instance and uses it to create Google Cloud resources declaratively using Config Connector CRDs.<\/p>\n\n\n\n<blockquote>\n<p>Important: Exact commands and API names can evolve. If a command differs in your environment, follow the current official quickstart:\nhttps:\/\/cloud.google.com\/config-controller\/docs<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create a <strong>Config Controller<\/strong> instance in a chosen region.<\/li>\n<li>Connect to it using <code>kubectl<\/code>.<\/li>\n<li>Create a Cloud Storage bucket and a Pub\/Sub topic using <strong>Config Connector<\/strong> custom resources.<\/li>\n<li>Validate that resources exist in Google Cloud.<\/li>\n<li>Clean up to avoid ongoing cost.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Prepare a project and enable APIs.\n2. Create networking prerequisites (if required).\n3. Create a Config Controller instance.\n4. Configure permissions for resource creation.\n5. Apply Config Connector manifests to create resources.\n6. Validate and troubleshoot.\n7. Clean up resources and the instance.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set up your environment (project, auth, defaults)<\/h3>\n\n\n\n<p>1) Install and initialize the Google Cloud CLI:\n&#8211; Install: https:\/\/cloud.google.com\/sdk\/docs\/install\n&#8211; Authenticate:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud auth login\ngcloud auth application-default login\n<\/code><\/pre>\n\n\n\n<p>2) Choose (or create) a project:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_ID=\"cc-lab-$(date +%Y%m%d-%H%M%S)\"\ngcloud projects create \"$PROJECT_ID\"\ngcloud billing projects link \"$PROJECT_ID\" --billing-account=\"YOUR_BILLING_ACCOUNT_ID\"\n<\/code><\/pre>\n\n\n\n<p>If you already have a billing-enabled project, set it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_ID=\"YOUR_PROJECT_ID\"\ngcloud config set project \"$PROJECT_ID\"\n<\/code><\/pre>\n\n\n\n<p>3) Pick a region supported by Config Controller (verify supported regions in docs). Example:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export REGION=\"us-central1\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: <code>gcloud config get-value project<\/code> returns your project, and billing is enabled.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Enable required APIs<\/h3>\n\n\n\n<p>Enable baseline APIs (some may already be enabled). API requirements vary; follow the official docs if additional services are required:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable \\\n  serviceusage.googleapis.com \\\n  cloudresourcemanager.googleapis.com \\\n  iam.googleapis.com \\\n  storage.googleapis.com \\\n  pubsub.googleapis.com\n<\/code><\/pre>\n\n\n\n<p>Now enable the API(s) specifically required for Config Controller. The exact service name can change; consult the official docs for the current list:\n&#8211; https:\/\/cloud.google.com\/config-controller\/docs<\/p>\n\n\n\n<p>If the docs specify an API like <code>configcontroller.googleapis.com<\/code> (example only), enable it:<\/p>\n\n\n\n<pre><code class=\"language-bash\"># Example: verify the exact API name in official docs\ngcloud services enable configcontroller.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: <code>gcloud services list --enabled<\/code> includes the required services; no errors like \u201cSERVICE_DISABLED\u201d.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create or choose networking (VPC\/subnet) as required<\/h3>\n\n\n\n<p>Config Controller provisioning typically requires selecting or creating a VPC and subnet (details vary by current product behavior). If you need a dedicated VPC, create one:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export NETWORK=\"cc-network\"\nexport SUBNET=\"cc-subnet\"\nexport SUBNET_RANGE=\"10.10.0.0\/24\"\n\ngcloud compute networks create \"$NETWORK\" --subnet-mode=custom\n\ngcloud compute networks subnets create \"$SUBNET\" \\\n  --network=\"$NETWORK\" \\\n  --region=\"$REGION\" \\\n  --range=\"$SUBNET_RANGE\"\n<\/code><\/pre>\n\n\n\n<p>If your org requires Private Google Access for API connectivity, enable it on the subnet:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute networks subnets update \"$SUBNET\" \\\n  --region=\"$REGION\" \\\n  --enable-private-ip-google-access\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: VPC and subnet exist and are visible in:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute networks list\ngcloud compute networks subnets list --regions=\"$REGION\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create the Config Controller instance<\/h3>\n\n\n\n<p>Follow the official creation method for your environment (Console or <code>gcloud<\/code>). Many environments use a <code>gcloud<\/code> command group for Config Controller under Anthos tooling.<\/p>\n\n\n\n<p>1) Ensure your <code>gcloud<\/code> components are updated:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud components update\n<\/code><\/pre>\n\n\n\n<p>2) Create the instance using the official command pattern from docs:\n&#8211; https:\/\/cloud.google.com\/config-controller\/docs<\/p>\n\n\n\n<p>Example pattern (command and flags may differ; <strong>verify in official docs<\/strong>):<\/p>\n\n\n\n<pre><code class=\"language-bash\">export CC_NAME=\"cc-lab\"\n\n# Example only: verify exact command group and flags\ngcloud anthos config controller create \"$CC_NAME\" \\\n  --location=\"$REGION\" \\\n  --network=\"$NETWORK\" \\\n  --subnet=\"$SUBNET\"\n<\/code><\/pre>\n\n\n\n<p>3) Wait until the instance is ready. There is typically a \u201cdescribe\u201d or \u201clist\u201d command; verify the right one in docs:<\/p>\n\n\n\n<pre><code class=\"language-bash\"># Example only\ngcloud anthos config controller describe \"$CC_NAME\" --location=\"$REGION\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: The instance shows a READY\/RUNNING state.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Get cluster credentials and connect with kubectl<\/h3>\n\n\n\n<p>Fetch credentials (exact command depends on tooling; verify in docs):<\/p>\n\n\n\n<pre><code class=\"language-bash\"># Example only\ngcloud anthos config controller get-credentials \"$CC_NAME\" --location=\"$REGION\"\n<\/code><\/pre>\n\n\n\n<p>Test connectivity:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl version --short\nkubectl get nodes\nkubectl get namespaces\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>:\n&#8211; <code>kubectl get namespaces<\/code> returns standard namespaces.\n&#8211; You can list resources without authentication errors.<\/p>\n\n\n\n<p>Common issue:\n&#8211; If you see authorization errors, verify you have the correct Google Cloud IAM permissions and Kubernetes RBAC.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Confirm Config Connector CRDs are available<\/h3>\n\n\n\n<p>Config Controller\u2019s main value is Config Connector CRDs. Confirm CRDs exist:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get crds | grep -i cnrm | head\n<\/code><\/pre>\n\n\n\n<p>You can also check for specific CRDs (examples; actual names depend on installed version):<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get crds | grep -E \"storage|pubsub\" | head\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: You see CRDs that indicate Config Connector is installed (often CRDs containing <code>cnrm.cloud.google.com<\/code>).<\/p>\n\n\n\n<p>If you do not see CRDs, check the Config Controller docs and the instance health status. Do not proceed until CRDs are present.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Configure IAM for the controller identity (least privilege)<\/h3>\n\n\n\n<p>Config Connector needs permissions to create resources. The identity and recommended setup depend on your Config Controller provisioning model.<\/p>\n\n\n\n<p>You must determine:\n&#8211; Which Google Cloud <strong>service account<\/strong> the controller uses\n&#8211; How to grant it permissions (project-level roles vs fine-grained roles)<\/p>\n\n\n\n<p>Follow the official guidance:\n&#8211; https:\/\/cloud.google.com\/config-connector\/docs\/how-to\/install-upgrade-uninstall\n&#8211; https:\/\/cloud.google.com\/config-controller\/docs<\/p>\n\n\n\n<p>A common pattern is:\n&#8211; Use a dedicated service account, then grant roles needed to manage target resources (Storage, Pub\/Sub, etc.).<\/p>\n\n\n\n<p>Example (illustrative; <strong>verify controller SA<\/strong> and roles):<\/p>\n\n\n\n<pre><code class=\"language-bash\">export CC_SA=\"config-controller-sa@$PROJECT_ID.iam.gserviceaccount.com\"\n\n# Create a dedicated service account (if your model requires it)\ngcloud iam service-accounts create config-controller-sa \\\n  --display-name=\"Config Controller SA\"\n\n# Grant only needed roles for this lab (Storage + Pub\/Sub)\ngcloud projects add-iam-policy-binding \"$PROJECT_ID\" \\\n  --member=\"serviceAccount:$CC_SA\" \\\n  --role=\"roles\/storage.admin\"\n\ngcloud projects add-iam-policy-binding \"$PROJECT_ID\" \\\n  --member=\"serviceAccount:$CC_SA\" \\\n  --role=\"roles\/pubsub.admin\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: IAM policy bindings are added. In production, prefer narrower roles (and sometimes resource-level IAM instead of project-wide roles).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Create a namespace for the lab and apply resources<\/h3>\n\n\n\n<p>1) Create a namespace:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl create namespace infra-demo\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Namespace <code>infra-demo<\/code> exists.<\/p>\n\n\n\n<p>2) Create a Cloud Storage bucket using Config Connector.<\/p>\n\n\n\n<p>Bucket names must be globally unique. Choose a unique name:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export BUCKET_NAME=\"cc-bucket-$PROJECT_ID\"\n<\/code><\/pre>\n\n\n\n<p>Apply a Config Connector resource. The exact API version\/kind can vary by Config Connector version; verify the correct manifest format in the reference:\n&#8211; https:\/\/cloud.google.com\/config-connector\/docs\/reference\/overview\n&#8211; Storage bucket resource reference: verify in docs.<\/p>\n\n\n\n<p>Example manifest (verify <code>apiVersion<\/code>\/<code>kind<\/code> fields in your environment before applying):<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; bucket.yaml &lt;&lt;EOF\napiVersion: storage.cnrm.cloud.google.com\/v1beta1\nkind: StorageBucket\nmetadata:\n  name: ${BUCKET_NAME}\n  namespace: infra-demo\nspec:\n  location: ${REGION}\n  uniformBucketLevelAccess: true\nEOF\n\nkubectl apply -f bucket.yaml\n<\/code><\/pre>\n\n\n\n<p>3) Create a Pub\/Sub topic:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export TOPIC_NAME=\"cc-topic-$PROJECT_ID\"\n\ncat &gt; topic.yaml &lt;&lt;EOF\napiVersion: pubsub.cnrm.cloud.google.com\/v1beta1\nkind: PubSubTopic\nmetadata:\n  name: ${TOPIC_NAME}\n  namespace: infra-demo\nspec: {}\nEOF\n\nkubectl apply -f topic.yaml\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>:\n&#8211; Kubernetes objects are created immediately.\n&#8211; Within a short time, their <code>status<\/code> should indicate reconciliation succeeded.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: Watch reconciliation status<\/h3>\n\n\n\n<p>Check the objects:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n infra-demo get storagebucket\nkubectl -n infra-demo get pubsubtopic\n<\/code><\/pre>\n\n\n\n<p>Describe them to see conditions\/events:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n infra-demo describe storagebucket \"${BUCKET_NAME}\"\nkubectl -n infra-demo describe pubsubtopic \"${TOPIC_NAME}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Look for conditions such as \u201cReady=True\u201d (exact condition names vary). If not ready, you should see an error message indicating missing permissions, invalid fields, or quota issues.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Validate in Google Cloud that resources exist.<\/p>\n\n\n\n<p>1) Cloud Storage bucket exists:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud storage buckets describe \"gs:\/\/${BUCKET_NAME}\"\n<\/code><\/pre>\n\n\n\n<p>2) Pub\/Sub topic exists:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud pubsub topics describe \"${TOPIC_NAME}\"\n<\/code><\/pre>\n\n\n\n<p>Also validate that the resources are managed by Config Connector by checking annotations\/labels in the Kubernetes objects:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n infra-demo get storagebucket \"${BUCKET_NAME}\" -o yaml | sed -n '1,120p'\nkubectl -n infra-demo get pubsubtopic \"${TOPIC_NAME}\" -o yaml | sed -n '1,120p'\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: The resources exist in Google Cloud and show reconciliation metadata in Kubernetes.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and fixes:<\/p>\n\n\n\n<p>1) <strong>CRDs not found \/ \u201cno matches for kind \u2026\u201d<\/strong>\n&#8211; Cause: Config Connector CRDs not installed\/ready.\n&#8211; Fix:\n  &#8211; Confirm Config Controller instance is healthy\/ready.\n  &#8211; Re-check CRDs: <code>kubectl get crds | grep cnrm<\/code>\n  &#8211; Follow official docs to confirm components.<\/p>\n\n\n\n<p>2) <strong>Permission denied errors in status\/conditions<\/strong>\n&#8211; Cause: Controller identity lacks required IAM roles.\n&#8211; Fix:\n  &#8211; Identify the exact service account used by the controller (per docs).\n  &#8211; Grant least-privilege roles for the resource type.\n  &#8211; Re-check after reconciliation.<\/p>\n\n\n\n<p>3) <strong>Bucket name already exists<\/strong>\n&#8211; Cause: Bucket names are globally unique.\n&#8211; Fix: Change <code>metadata.name<\/code> to a unique value.<\/p>\n\n\n\n<p>4) <strong>Org Policy blocks resource creation<\/strong>\n&#8211; Cause: Organization Policy Service constraints (allowed locations, restricted services, etc.).\n&#8211; Fix:\n  &#8211; Review org policies in the project\/folder\/org.\n  &#8211; Adjust policy or choose compliant settings (e.g., allowed regions).<\/p>\n\n\n\n<p>5) <strong>Quota exceeded<\/strong>\n&#8211; Cause: Service quotas exceeded for Storage\/PubSub\/etc.\n&#8211; Fix:\n  &#8211; Check quotas in Cloud Console.\n  &#8211; Request increases or reduce resources.<\/p>\n\n\n\n<p>6) <strong>Networking \/ API access issues<\/strong>\n&#8211; Cause: The instance cannot reach Google APIs due to restricted egress.\n&#8211; Fix:\n  &#8211; Verify VPC\/subnet configuration.\n  &#8211; Ensure Private Google Access (if required).\n  &#8211; Follow documented networking prerequisites for Config Controller.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing costs, delete the resources and the Config Controller instance.<\/p>\n\n\n\n<p>1) Delete Kubernetes-managed resources:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl delete -f topic.yaml\nkubectl delete -f bucket.yaml\nkubectl delete namespace infra-demo\n<\/code><\/pre>\n\n\n\n<p>2) Verify they are gone from Google Cloud:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud pubsub topics list | grep \"${TOPIC_NAME}\" || true\ngcloud storage buckets describe \"gs:\/\/${BUCKET_NAME}\" 2&gt;\/dev\/null || echo \"Bucket deleted\"\n<\/code><\/pre>\n\n\n\n<p>3) Delete the Config Controller instance (command varies; verify in docs):<\/p>\n\n\n\n<pre><code class=\"language-bash\"># Example only\ngcloud anthos config controller delete \"$CC_NAME\" --location=\"$REGION\"\n<\/code><\/pre>\n\n\n\n<p>4) Optional: delete the network resources if you created a dedicated VPC:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute networks subnets delete \"$SUBNET\" --region=\"$REGION\" --quiet\ngcloud compute networks delete \"$NETWORK\" --quiet\n<\/code><\/pre>\n\n\n\n<p>5) Optional: delete the project (fastest way to ensure no lingering resources):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud projects delete \"$PROJECT_ID\" --quiet\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Use a dedicated \u201cconfig plane\u201d<\/strong> (Config Controller) separate from application clusters to reduce blast radius.<\/li>\n<li><strong>Design for environment isolation<\/strong>: at minimum, separate dev and prod control planes.<\/li>\n<li><strong>Use a clear resource hierarchy<\/strong> (org \u2192 folders \u2192 projects) and decide where resources should live before modeling them as CRs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Least privilege for controller identity<\/strong>:<\/li>\n<li>Prefer narrowly scoped roles over broad <code>admin<\/code> roles.<\/li>\n<li>Consider splitting identities by namespace or environment when feasible (verify supported patterns).<\/li>\n<li><strong>Use Kubernetes RBAC<\/strong> to control who can apply\/change manifests.<\/li>\n<li><strong>Avoid giving developers direct project Owner<\/strong> access; use GitOps with controlled approvals.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Start with <strong>one instance per environment<\/strong>, not per team.<\/li>\n<li>Control resource sprawl with:<\/li>\n<li>policy checks (where supported)<\/li>\n<li>budgets and alerts<\/li>\n<li>labels and inventory reporting<\/li>\n<li>Minimize excessive logging; export audit logs thoughtfully.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep manifests clean and consistent; avoid frequent no-op changes that trigger reconciliation churn.<\/li>\n<li>Batch related changes to reduce churn and API rate usage.<\/li>\n<li>Watch for API rate limits if managing very large fleets\u2014design with quotas in mind.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat Git (if used) as the source of truth; implement PR reviews and required approvals.<\/li>\n<li>Use progressive rollout patterns for sensitive infrastructure changes.<\/li>\n<li>Establish clear rollback procedures (revert commit \/ re-apply previous manifests).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standardize:<\/li>\n<li>naming conventions (resource names, namespaces)<\/li>\n<li>labels (cost center, environment, owner)<\/li>\n<li>repository structure (per environment, per team)<\/li>\n<li>Monitor:<\/li>\n<li>reconcile failures<\/li>\n<li>repeated error events<\/li>\n<li>audit log anomalies (unexpected deletions, denied operations)<\/li>\n<li>Document break-glass procedures (who can bypass GitOps in emergencies).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use consistent labels\/annotations in Kubernetes manifests to map to business ownership.<\/li>\n<li>If you rely on cloud labels, ensure the Config Connector resource supports them and that they\u2019re enforced by policy.<\/li>\n<li>Align naming with DNS\/project conventions and org policy constraints.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<p>Config Controller introduces <strong>two layers<\/strong> of access control:<\/p>\n\n\n\n<p>1) <strong>Kubernetes access<\/strong>\n&#8211; Who can connect and apply manifests is controlled by Kubernetes authentication + RBAC.<\/p>\n\n\n\n<p>2) <strong>Google Cloud API access<\/strong>\n&#8211; What can actually be created\/changed is controlled by the controller\u2019s Google Cloud identity (service account) and its IAM roles.<\/p>\n\n\n\n<p>Security design goal:\n&#8211; Developers get <strong>Kubernetes RBAC<\/strong> permissions in limited namespaces.\n&#8211; Controllers get <strong>Google Cloud IAM<\/strong> permissions that are least-privilege and environment-scoped.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud encrypts data at rest by default for most managed services.<\/li>\n<li>For specific services (Storage, etc.), you may need CMEK or retention policies.<\/li>\n<li>Use policies (where supported) to require encryption settings and block non-compliant resources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer private connectivity to the Kubernetes API endpoint where possible.<\/li>\n<li>Restrict who can reach the API endpoint (VPN\/bastion\/allowlists depending on product options).<\/li>\n<li>Ensure the controller has secure access to required Google APIs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid storing secrets in plain manifests.<\/li>\n<li>Prefer Google Cloud secret services (e.g., Secret Manager) and reference patterns supported by your runtime\/tooling.<\/li>\n<li>If you store Kubernetes Secrets in the config plane, treat that cluster as sensitive and lock down RBAC tightly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>Cloud Audit Logs<\/strong> to track the controller identity\u2019s API calls.<\/li>\n<li>Track who applied Kubernetes manifests (Kubernetes audit logs availability depends on the managed environment\u2014verify).<\/li>\n<li>Export audit logs to a central SIEM in regulated environments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enforce consistent labels, locations, retention, and encryption to meet compliance.<\/li>\n<li>Validate resource creation against org policies (some will block creation regardless of Config Controller).<\/li>\n<li>Document change management workflows (PR approvals, ticket links, CAB processes) around infrastructure changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Granting the controller service account broad roles like <code>Editor<\/code> or <code>Owner<\/code>.<\/li>\n<li>Allowing direct <code>kubectl apply<\/code> from developer laptops without approvals.<\/li>\n<li>Using one Config Controller instance to manage both dev and prod with the same identity.<\/li>\n<li>Not monitoring reconcile failures (which can hide permission or policy issues).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Separate instances per environment.<\/li>\n<li>Dedicated controller identities per environment with minimal roles.<\/li>\n<li>Restrictive Kubernetes RBAC: namespaces per team, minimal verbs\/resources.<\/li>\n<li>Network controls around Kubernetes API endpoint.<\/li>\n<li>Centralized audit log export and alerting.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<blockquote>\n<p>Treat this section as a checklist to validate in your environment, because service behavior and supported resources evolve.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations (common)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Not a general-purpose GKE cluster<\/strong>: don\u2019t plan to run application workloads on Config Controller unless explicitly documented as supported.<\/li>\n<li><strong>Supported resource coverage varies<\/strong>: Config Connector may not support every Google Cloud resource or field.<\/li>\n<li><strong>Some updates may force replacement<\/strong>: certain resource changes require recreation rather than in-place updates.<\/li>\n<li><strong>Eventual consistency<\/strong>: reconciliation is asynchronous; \u201capply\u201d does not mean \u201cresource is ready\u201d.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud service quotas for the resources you create apply (Storage, Pub\/Sub, IAM, etc.).<\/li>\n<li>There may be limits on Config Controller instances per project\/region\u2014verify in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Config Controller is regional; not all regions may be supported.<\/li>\n<li>If you have data residency requirements, ensure the region is compliant.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Multiple instances (per team\/per env) can add up quickly.<\/li>\n<li>Logging and audit log export can become significant.<\/li>\n<li>NAT and private networking can add recurring costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Your org policies may block the exact configuration you try to apply.<\/li>\n<li>Resource fields and API versions differ across Config Connector versions\u2014always use the version documented for your installation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>IAM is dual-layered (Kubernetes RBAC + Google Cloud IAM), and errors can be confusing until you know where to look.<\/li>\n<li>Some deletes may hang due to finalizers until underlying resources are deleted or the controller can complete cleanup.<\/li>\n<li>Drift correction can \u201cundo\u201d manual changes; establish a policy on whether manual changes are allowed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Migrating from Terraform to Config Controller requires rethinking state ownership and drift behavior.<\/li>\n<li>You must plan how to import existing resources into Config Connector management (import support exists for some resources; verify in docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Config Controller is deeply integrated with Google Cloud IAM and APIs; it\u2019s not a generic multi-cloud control plane by itself.<\/li>\n<li>For true multicloud resource management, you typically combine it with other tools or run separate patterns per cloud.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Config Controller is one of several ways to manage infrastructure on Google Cloud. Here\u2019s how it compares.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Key alternatives<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Config Connector on a self-managed Kubernetes cluster (e.g., GKE)<\/strong><\/li>\n<li><strong>Terraform (Google provider)<\/strong><\/li>\n<li><strong>Pulumi<\/strong><\/li>\n<li><strong>Crossplane<\/strong><\/li>\n<li><strong>Google Cloud Deployment Manager<\/strong> (legacy\/less recommended in many modern setups; verify current status in official docs)<\/li>\n<li>Other clouds:<\/li>\n<li><strong>AWS CloudFormation<\/strong><\/li>\n<li><strong>Azure ARM\/Bicep<\/strong><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Config Controller (Google Cloud)<\/td>\n<td>Kubernetes-native Google Cloud infrastructure management with a managed config control plane<\/td>\n<td>Managed control plane, Kubernetes RBAC\/namespace patterns, continuous reconciliation<\/td>\n<td>Resource coverage limits; adds a control plane; requires Kubernetes operational knowledge<\/td>\n<td>You want Kubernetes-style infra + managed config plane on Google Cloud<\/td>\n<\/tr>\n<tr>\n<td>Config Connector on GKE (self-managed)<\/td>\n<td>Teams that want Config Connector but already run their own management cluster<\/td>\n<td>Full control over cluster; integrate with existing tools<\/td>\n<td>You manage the cluster lifecycle; more ops burden<\/td>\n<td>You already operate GKE and want to host the controllers yourself<\/td>\n<\/tr>\n<tr>\n<td>Terraform (Google provider)<\/td>\n<td>Broad IaC adoption; strong ecosystem; multi-cloud<\/td>\n<td>Plan\/apply workflow, mature modules, wide service coverage<\/td>\n<td>Drift requires refresh; state management complexity<\/td>\n<td>You want broad coverage, established workflows, and strong multi-cloud story<\/td>\n<\/tr>\n<tr>\n<td>Pulumi<\/td>\n<td>IaC with general-purpose languages<\/td>\n<td>Strong developer experience; code reuse<\/td>\n<td>Still needs state; less \u201calways reconciling\u201d<\/td>\n<td>You prefer programming-language IaC over YAML\/CRDs<\/td>\n<\/tr>\n<tr>\n<td>Crossplane<\/td>\n<td>Kubernetes control plane for multi-cloud resources<\/td>\n<td>Kubernetes-native + multi-cloud; composition patterns<\/td>\n<td>Additional complexity; provider maturity varies<\/td>\n<td>You want Kubernetes-style IaC across multiple clouds and services<\/td>\n<\/tr>\n<tr>\n<td>AWS CloudFormation<\/td>\n<td>AWS-native IaC<\/td>\n<td>Deep AWS integration; change sets<\/td>\n<td>AWS-only<\/td>\n<td>You are primarily on AWS<\/td>\n<\/tr>\n<tr>\n<td>Azure ARM\/Bicep<\/td>\n<td>Azure-native IaC<\/td>\n<td>Deep Azure integration; native tooling<\/td>\n<td>Azure-only<\/td>\n<td>You are primarily on Azure<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: regulated financial services platform team<\/h3>\n\n\n\n<p><strong>Problem<\/strong>\nA bank runs dozens of product teams on GKE. Each team needs Pub\/Sub topics, buckets, service accounts, and IAM bindings. Manual provisioning through tickets is slow, and auditors require traceability and policy enforcement.<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; One Config Controller instance per environment (dev\/stage\/prod) in dedicated platform projects.\n&#8211; Namespace per product team (e.g., <code>team-payments<\/code>, <code>team-risk<\/code>).\n&#8211; Kubernetes RBAC grants teams permissions only in their namespace.\n&#8211; Controller service account has least-privilege IAM roles scoped per project\/environment.\n&#8211; Changes flow through Git PRs; approvals required for production.\n&#8211; Cloud Audit Logs exported to a central logging project and SIEM.<\/p>\n\n\n\n<p><strong>Why Config Controller was chosen<\/strong>\n&#8211; Platform already uses Kubernetes heavily; teams understand <code>kubectl<\/code> workflows.\n&#8211; Continuous reconciliation reduces drift and \u201cconfiguration entropy\u201d.\n&#8211; Strong separation between app clusters and infra provisioning plane improves security posture.<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Faster provisioning (minutes instead of days).\n&#8211; Reduced audit findings due to standardized, reviewable changes.\n&#8211; Fewer outages caused by inconsistent manual configuration.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: SaaS company standardizing environments<\/h3>\n\n\n\n<p><strong>Problem<\/strong>\nA startup deploys microservices on GKE and keeps creating inconsistent dev environments. Terraform exists but is managed by one person; drift and ad-hoc console edits cause recurring problems.<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; One Config Controller instance for dev\/stage, later another for prod.\n&#8211; A simple Git repo containing:\n  &#8211; bucket\/topic manifests per service\n  &#8211; common labels and naming conventions\n&#8211; CI applies manifests to Config Controller.\n&#8211; Minimal IAM roles for the controller identity.<\/p>\n\n\n\n<p><strong>Why Config Controller was chosen<\/strong>\n&#8211; The team already uses Kubernetes daily; using the Kubernetes API for infra reduces context switching.\n&#8211; Reconciliation reduces drift from manual changes.<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Consistent environments.\n&#8211; Reduced dependency on one Terraform expert.\n&#8211; Easier onboarding with \u201capply these manifests\u201d workflows.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">1) Is Config Controller the same as GKE?<\/h3>\n\n\n\n<p>No. Config Controller provides a managed Kubernetes control plane focused on configuration management (primarily via Config Connector). It is not positioned as a general-purpose application cluster. Verify any workload-running support in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2) What is the relationship between Config Controller and Config Connector?<\/h3>\n\n\n\n<p>Config Controller hosts and operates Config Connector so you can manage Google Cloud resources as Kubernetes objects. Config Connector provides the CRDs and controllers.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3) Do I need to know Kubernetes to use Config Controller?<\/h3>\n\n\n\n<p>Practically, yes. You\u2019ll use Kubernetes concepts like manifests, namespaces, RBAC, and <code>kubectl<\/code>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4) Can Config Controller manage resources across multiple projects?<\/h3>\n\n\n\n<p>Often yes, depending on IAM setup and supported patterns, but it requires careful IAM and org policy design. Verify cross-project management support in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5) Does Config Controller support GitOps?<\/h3>\n\n\n\n<p>Config Controller supports GitOps as a pattern because desired state lives as Kubernetes resources. Whether a GitOps engine is bundled (e.g., Config Sync) depends on current packaging\u2014verify in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6) What happens if someone changes a resource manually in the console?<\/h3>\n\n\n\n<p>If Config Connector can detect and reconcile the difference, it will attempt to restore the declared desired state. Some changes may not be reversible automatically.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">7) How do I troubleshoot failed reconciliations?<\/h3>\n\n\n\n<p>Start with:\n&#8211; <code>kubectl describe &lt;resource&gt;<\/code> to read conditions\/events\n&#8211; Cloud Audit Logs to see API errors\/denials\n&#8211; Verify IAM permissions, org policies, quotas, and manifest correctness<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">8) Can I import existing Google Cloud resources into Config Connector management?<\/h3>\n\n\n\n<p>Some resources can be imported\/adopted, but coverage varies. Check Config Connector import\/adoption docs for your resource type.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">9) Is Config Controller appropriate for production?<\/h3>\n\n\n\n<p>Yes, it can be, especially for platform teams implementing controlled provisioning. Use environment isolation, least privilege, and strong audit controls.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">10) How is access controlled?<\/h3>\n\n\n\n<p>Access is controlled by:\n&#8211; Kubernetes RBAC (who can apply\/modify manifests)\n&#8211; Google Cloud IAM permissions of the controller identity (what can actually be created\/modified)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">11) What is the biggest operational risk?<\/h3>\n\n\n\n<p>Misconfigured IAM and unclear ownership boundaries (who is allowed to create what). Another risk is relying on unsupported resource types or fields.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">12) Does Config Controller support policy enforcement?<\/h3>\n\n\n\n<p>Policy enforcement is typically done via Kubernetes admission control frameworks (often associated with Anthos Policy Controller). Whether it is built-in depends on your setup\u2014verify in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">13) How do I avoid accidental deletion of cloud resources?<\/h3>\n\n\n\n<p>Use:\n&#8211; Strict RBAC (who can delete objects)\n&#8211; GitOps approvals\n&#8211; Deletion policies\/finalizers where available\n&#8211; Separate environments and strict permissions in production<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">14) How do I estimate costs?<\/h3>\n\n\n\n<p>Use the official pricing page(s) and the Pricing Calculator:\n&#8211; https:\/\/cloud.google.com\/anthos\/pricing\n&#8211; https:\/\/cloud.google.com\/products\/calculator<br\/>\nAlso include costs of resources you create and logging\/egress.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">15) Should I replace Terraform with Config Controller?<\/h3>\n\n\n\n<p>Not necessarily. Many organizations use both:\n&#8211; Terraform for baseline foundation and shared modules\n&#8211; Config Controller for Kubernetes-native workflows and ongoing reconciliation<br\/>\nPick based on team skill sets, governance model, and resource coverage needs.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Config Controller<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Config Controller docs \u2014 https:\/\/cloud.google.com\/config-controller\/docs<\/td>\n<td>Primary source for supported regions, setup, commands, and operational guidance<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Config Connector docs \u2014 https:\/\/cloud.google.com\/config-connector\/docs<\/td>\n<td>CRD reference, supported resources, IAM patterns, troubleshooting<\/td>\n<\/tr>\n<tr>\n<td>Reference<\/td>\n<td>Config Connector resource reference overview \u2014 https:\/\/cloud.google.com\/config-connector\/docs\/reference\/overview<\/td>\n<td>Helps verify the correct <code>apiVersion<\/code>, <code>kind<\/code>, and fields for each resource<\/td>\n<\/tr>\n<tr>\n<td>Pricing<\/td>\n<td>Anthos pricing \u2014 https:\/\/cloud.google.com\/anthos\/pricing<\/td>\n<td>Config Controller billing may be connected to Anthos packaging; verify current model here<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>Google Cloud Pricing Calculator \u2014 https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Build estimates including resources created and indirect costs<\/td>\n<\/tr>\n<tr>\n<td>Governance<\/td>\n<td>Cloud Audit Logs overview \u2014 https:\/\/cloud.google.com\/logging\/docs\/audit<\/td>\n<td>Essential for tracking API calls made by controller identity<\/td>\n<\/tr>\n<tr>\n<td>Tooling<\/td>\n<td>Google Cloud SDK installation \u2014 https:\/\/cloud.google.com\/sdk\/docs\/install<\/td>\n<td><code>gcloud<\/code> installation and auth setup<\/td>\n<\/tr>\n<tr>\n<td>Community (trusted)<\/td>\n<td>Kubernetes documentation \u2014 https:\/\/kubernetes.io\/docs\/home\/<\/td>\n<td>Understanding manifests, RBAC, namespaces, and troubleshooting<\/td>\n<\/tr>\n<tr>\n<td>Community (practical)<\/td>\n<td>Gatekeeper\/OPA docs \u2014 https:\/\/open-policy-agent.github.io\/gatekeeper\/<\/td>\n<td>Useful if you implement admission control policies (verify how it\u2019s packaged with your environment)<\/td>\n<\/tr>\n<tr>\n<td>Samples (verify source)<\/td>\n<td>GoogleCloudPlatform GitHub \u2014 https:\/\/github.com\/GoogleCloudPlatform<\/td>\n<td>Search for Config Connector\/Config Controller examples; validate they match your version<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>DevOps, Kubernetes, cloud automation, GitOps foundations<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>DevOps tooling, CI\/CD, SCM, automation<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations teams<\/td>\n<td>CloudOps practices, operations, monitoring, cost awareness<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, reliability engineers<\/td>\n<td>SRE practices, observability, incident management<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops and platform teams<\/td>\n<td>AIOps concepts, automation, monitoring analytics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/Kubernetes\/cloud training content (verify current offerings)<\/td>\n<td>Beginners to advanced practitioners<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps and CI\/CD coaching (verify current offerings)<\/td>\n<td>Engineers and teams<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>DevOps freelance services\/training resources (verify current offerings)<\/td>\n<td>Teams needing practical help<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and training resources (verify current offerings)<\/td>\n<td>Operations teams, DevOps engineers<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify service catalog)<\/td>\n<td>Platform engineering, Kubernetes operations, automation<\/td>\n<td>Designing a GitOps operating model; setting up governance and CI\/CD around Config Controller<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and training (verify service catalog)<\/td>\n<td>DevOps transformations, toolchain integration<\/td>\n<td>Building an internal developer platform; implementing RBAC and IaC workflows<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify service catalog)<\/td>\n<td>CI\/CD, automation, operations<\/td>\n<td>CI integration for manifest deployment; cost and security reviews<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Config Controller<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud fundamentals:<\/li>\n<li>Projects, IAM, service accounts<\/li>\n<li>VPC basics and private access patterns<\/li>\n<li>Cloud Audit Logs and billing basics<\/li>\n<li>Kubernetes fundamentals:<\/li>\n<li>Manifests, resources, controllers<\/li>\n<li>Namespaces and RBAC<\/li>\n<li><code>kubectl<\/code> troubleshooting (<code>describe<\/code>, events, conditions)<\/li>\n<li>Infrastructure-as-Code concepts:<\/li>\n<li>Desired state vs imperative changes<\/li>\n<li>Change management and approvals<\/li>\n<li>Git workflows (branches, PRs, code review)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Config Controller<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Config Connector deep dive:<\/li>\n<li>supported resource coverage and limitations<\/li>\n<li>importing\/adopting existing resources<\/li>\n<li>composition patterns (if available)<\/li>\n<li>Policy and governance:<\/li>\n<li>OPA\/Gatekeeper concepts (if used)<\/li>\n<li>Organization Policy Service constraints<\/li>\n<li>GitOps operating model:<\/li>\n<li>repo structures, environment promotion<\/li>\n<li>CI pipelines and drift detection<\/li>\n<li>FinOps practices:<\/li>\n<li>budgets, alerts, labeling strategy<\/li>\n<li>cost attribution and chargeback\/showback<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform Engineer \/ Platform Architect<\/li>\n<li>Cloud Engineer<\/li>\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Security Engineer (cloud governance)<\/li>\n<li>Infrastructure Engineer<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>Config Controller itself is not typically a standalone certification topic, but it aligns strongly with:\n&#8211; Google Cloud Professional Cloud Architect\n&#8211; Google Cloud Professional Cloud DevOps Engineer\n&#8211; Google Cloud Associate Cloud Engineer<\/p>\n\n\n\n<p>Verify current Google Cloud certification paths:\n&#8211; https:\/\/cloud.google.com\/learn\/certification<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a \u201cteam namespace onboarding\u201d workflow:<\/li>\n<li>Create namespace + RBAC + standard resources (bucket\/topic\/service accounts) as manifests.<\/li>\n<li>Implement a cost guardrail:<\/li>\n<li>Enforce required labels on all managed resources.<\/li>\n<li>Create a multi-environment setup:<\/li>\n<li>Separate Config Controller instances for dev and prod with different IAM scopes.<\/li>\n<li>Build a drift-response runbook:<\/li>\n<li>Detect reconcile failures and alert to Slack\/email (via your monitoring stack).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Config Controller<\/strong>: A Google Cloud managed Kubernetes control plane for managing Google Cloud resources declaratively.<\/li>\n<li><strong>Config Connector<\/strong>: A set of Kubernetes CRDs and controllers that represent Google Cloud resources and reconcile them via Google Cloud APIs.<\/li>\n<li><strong>CRD (Custom Resource Definition)<\/strong>: A Kubernetes extension mechanism that defines a new resource type.<\/li>\n<li><strong>Custom Resource (CR)<\/strong>: An instance of a CRD (e.g., <code>StorageBucket<\/code>).<\/li>\n<li><strong>Reconciliation<\/strong>: The controller loop that continuously drives actual state toward desired state.<\/li>\n<li><strong>Desired state<\/strong>: The configuration defined in manifests (what you want).<\/li>\n<li><strong>Actual state<\/strong>: The real resources and settings currently in Google Cloud (what exists).<\/li>\n<li><strong>Drift<\/strong>: A mismatch between desired state and actual state.<\/li>\n<li><strong>Kubernetes RBAC<\/strong>: Role-Based Access Control in Kubernetes for controlling access to API resources.<\/li>\n<li><strong>Namespace<\/strong>: A Kubernetes mechanism for grouping and isolating resources.<\/li>\n<li><strong>Least privilege<\/strong>: Granting only the minimal permissions required to perform tasks.<\/li>\n<li><strong>Cloud Audit Logs<\/strong>: Google Cloud logs that record administrative and data access operations on resources.<\/li>\n<li><strong>Organization Policy<\/strong>: Governance constraints that can restrict resource creation or configurations across an org\/folder\/project.<\/li>\n<li><strong>GitOps<\/strong>: Operational model where Git is the source of truth and automated reconciliation applies changes.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Config Controller is a Google Cloud service in the <strong>Distributed, hybrid, and multicloud<\/strong> category that provides a managed Kubernetes-based control plane for managing Google Cloud infrastructure declaratively\u2014primarily through <strong>Config Connector<\/strong> CRDs and continuous reconciliation.<\/p>\n\n\n\n<p>It matters because it brings Kubernetes-native workflows (manifests, RBAC, namespaces, reconciliation) to Google Cloud infrastructure management, helping platform teams improve standardization, reduce drift, and strengthen governance.<\/p>\n\n\n\n<p>From a cost perspective, plan for the managed service cost model (often related to Anthos packaging), plus the cost of the resources you create, and indirect costs like logging and networking. From a security perspective, focus on least-privilege IAM for the controller identity and tight Kubernetes RBAC for users\/CI.<\/p>\n\n\n\n<p>Use Config Controller when you want Kubernetes-native IaC and a dedicated, managed config plane\u2014especially in organizations standardizing operations across teams and environments. The best next learning step is to deepen your Config Connector resource coverage knowledge and adopt a GitOps workflow with strong policy and audit controls, starting from the official docs:\nhttps:\/\/cloud.google.com\/config-controller\/docs<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Distributed, hybrid, and multicloud<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[60,51],"tags":[],"class_list":["post-687","post","type-post","status-publish","format-standard","hentry","category-distributed-hybrid-and-multicloud","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/687","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=687"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/687\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=687"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=687"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=687"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}