GCP-ACE - Planning and implementing a cloud solution (30% of the exam) - Section 2.4
Plan and implement resources using tooling, including Infrastructure as Code tooling such as Config Connector, Terraform, and Helm, and AI-assisted planning and implementation with Gemini CLI and Gemini Cloud Assist.
Choose an Infrastructure as Code approach, distinguishing Terraform for declarative multi-resource provisioning, Config Connector for managing Google Cloud resources through Kubernetes, and Helm for packaging Kubernetes applications. Recognise where AI-assisted tooling such as Gemini CLI and Gemini Cloud Assist fits into planning and implementing infrastructure.
TerraformConfig ConnectorHelmGemini Cloud Assist
Practice question for this objective
lock_openFree samplePlanning and implementing a cloud solutionmedium
An engineering team already runs Google Kubernetes Engine and wants to create and reconcile Google Cloud resources, such as Pub/Sub topics and Cloud Storage buckets, by applying Kubernetes manifests with kubectl so that the cluster continuously keeps those resources in the declared state. Which tool is designed for this approach?
AConfig Connector, because it represents Google Cloud resources as Kubernetes custom resources and reconciles them from applied manifests.check_circle Correct
BHelm, because its release controller turns chart templates into live Google Cloud buckets and topics and reconciles them on drift.
CTerraform, because kubectl apply invokes the Terraform provider inside the cluster to keep Google Cloud resources reconciled.
DGemini Cloud Assist, because it watches the cluster and reissues API calls whenever a Google Cloud resource drifts from the manifest.
Identify Config Connector as the tool that manages Google Cloud resources as Kubernetes custom resources reconciled from within a cluster. Config Connector extends Kubernetes with custom resource definitions for Google Cloud services and runs controllers that reconcile the real resources to the applied manifests, so kubectl becomes the interface for managing that infrastructure.
Why A is correct: Config Connector installs custom resource definitions so Google Cloud services appear as Kubernetes objects, and its controllers continuously reconcile the actual resources to match the manifests applied to the cluster.
Why B is wrong: Helm templates and installs Kubernetes manifests as releases, but it neither models Google Cloud resources as custom resources nor runs controllers that reconcile buckets or topics against drift.
Why C is wrong: Terraform can create the same resources, but it runs as its own CLI against a state file and is not driven by kubectl apply or a reconciling controller living inside the cluster.
Why D is wrong: Gemini Cloud Assist provides AI-assisted help and recommendations, so it does not act as a Kubernetes controller and does not reconcile applied manifests into live Google Cloud resources.
Exam traps in Planning and implementing a cloud solution
Answers that look right on this material and are not. Each one is a distractor from a different question in the GCP-ACE bank for this domain.
Helm, because its charts declare and template a full estate of Google Cloud projects, networks, and databases from a single values file.
errorWhy it is wrong: Helm is tempting because charts are declarative and templated, but it packages and deploys Kubernetes objects into a cluster and does not provision project-level Google Cloud resources such as VPCs or Cloud SQL.
Gemini Cloud Assist replaces the infrastructure-as-code pipeline by owning a state file and applying the approved change to production itself.
errorWhy it is wrong: This overstates the tool: Gemini Cloud Assist does not maintain infrastructure state or apply changes, so it cannot replace a pipeline that provisions and reconciles resources.
Terraform, running terraform apply from the GitOps pipeline to create the Cloud SQL and Pub/Sub resources.
errorWhy it is wrong: Terraform can create these resources, but it manages them through its own state and apply cycle rather than as reconciled Kubernetes objects, so it does not fit the kubectl-native GitOps model the team wants.