Config Connector is one of those topics that feels niche until you see how often it comes up as the right answer on the Professional Cloud Architect exam. The setup is always the same. A team is already running on GKE, they want to manage Google Cloud resources outside the cluster the same way they manage workloads inside the cluster, and the question is asking which tool fits that pattern. Config Connector is the answer the exam is looking for in that scenario, and the reason why is worth understanding rather than memorizing.
Config Connector is an open-source add-on that runs inside a Kubernetes cluster and exposes Google Cloud resources as Kubernetes objects. Once it is installed, you create a BigQuery dataset by writing a YAML manifest and running kubectl apply, the same way you would create a Deployment or a Service. The Config Connector controllers watch for those custom resources and reconcile them against the actual state in your Google Cloud project, creating, updating, or deleting the underlying GCP resource to match what you declared.
The list of resources it covers is broad enough to handle most application infrastructure. BigQuery datasets, Cloud Storage buckets, Cloud IAM bindings, Pub/Sub topics, Cloud SQL instances, and Spanner databases are all expressible as Kubernetes manifests when Config Connector is running. That coverage is what makes it interesting on the exam. A team running a GKE-based application can keep all of its infrastructure definitions in the same Git repository as its application manifests and apply them with the same tooling.
The exam loves to test whether you can match vocabulary to tools, and Config Connector has two words that show up almost every time it is the right answer. Declarative is the first one. Config Connector is declarative because you describe the desired state of a Google Cloud resource in a manifest and the controllers make reality match that manifest. You are not writing imperative commands like create this bucket, then set this label, then attach this IAM policy. You are declaring the bucket's final shape and letting the system figure out how to get there.
Infrastructure as Code is the second tell. Config Connector turns Google Cloud resource definitions into versioned text files that live in a repository alongside your application code. That is the textbook definition of Infrastructure as Code, and a question that emphasizes IaC principles inside a GKE-based architecture is almost always pointing at Config Connector.
If the question instead emphasizes Infrastructure as Code without a Kubernetes context, the answer is more likely to be Terraform or Deployment Manager. Config Connector specifically wins when the team is already invested in Kubernetes and wants a unified toolset that does not require introducing a separate IaC system on top of GKE.
One detail the exam likes to surface is how you delete a Config Connector-managed resource. The answer is that you delete the Kubernetes custom resource with kubectl, and the controller takes care of removing the underlying Google Cloud resource. You do not delete it with gcloud. That looks like a trivia point, but it has a real reason behind it. If you delete the cloud resource directly with gcloud, the Kubernetes manifest still exists and the controller will see a drift between desired and actual state. It will recreate the resource you just removed.
Treat Config Connector-managed resources the way you treat any other Kubernetes object. The manifest is the source of truth. Changes go through kubectl apply for updates and kubectl delete for removal. Out-of-band changes through gcloud or the console will fight the controller.
The pattern that points at Config Connector on the Professional Cloud Architect exam has three pieces. The team is running on GKE, they want declarative or Infrastructure as Code management of Google Cloud resources outside the cluster, and they want to do it with their existing Kubernetes tooling rather than adopting a separate system. When all three are present, Config Connector is the answer.
Distractors usually include Terraform, Deployment Manager, and gcloud scripting. Terraform is a strong answer when the team is not Kubernetes-centric or when the question does not mention GKE at all. Deployment Manager is the older Google-native option and tends to appear in questions that are clearly favoring a non-Kubernetes IaC approach. gcloud scripting is almost always wrong when the question is asking about a managed, declarative pattern, because shell scripts that wrap gcloud are imperative by nature.
The other thing to watch for is questions that describe a team wanting to apply GitOps practices to their cloud infrastructure. GitOps depends on a declarative source of truth in a Git repository, and Config Connector is what makes that work for Google Cloud resources from inside a Kubernetes cluster. If the question mentions GitOps and GKE in the same breath, Config Connector is in the running.
The compact version of what you need to know about Config Connector for the Professional Cloud Architect exam is short. It is a GKE add-on that exposes Google Cloud resources as Kubernetes custom resources, you manage those resources with kubectl using declarative manifests, and you delete them with kubectl rather than gcloud. The vocabulary cues are declarative, Infrastructure as Code, unified Kubernetes tooling, and GitOps. When those words appear in a question that already involves GKE, Config Connector is the answer the exam wants.
I cover Config Connector in my Professional Cloud Architect course alongside the rest of the advanced architecture material.
