Google ACE Practice Question: Use Kustomize to manage environment-specific…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Kustomize duplicates all YAML files per environment, then applies find-and-replace on values.

  Why it's wrong here

  Kustomize's core design principle is to avoid copying entire manifest sets. Instead of duplicating YAML per environment, it references a single base directory and applies small overlay patches (strategic merge patches or JSON patches) that only carry environment-specific fields. There is no find-and-replace step; each overlay declares precisely which field values change, and the final manifest is produced by merging resources.

• ✓

  Kustomize uses overlays that patch a shared base: environment-specific differences are expressed as patches without duplicating base manifests.

  Why this is correct

  Kustomize organizes Kubernetes manifests as a shared base and environment-specific overlays. The base contains common full resource definitions (Deployment, Service, ConfigMap), while each overlay—for example, dev, staging, or production—contains only the differences to apply, such as the image tag, replica count, or a ConfigMap value. These differences are expressed as patches in the overlay's kustomization.yaml, and running `kubectl apply -k` reads the overlay, fetches the base, and merges them to produce the final, environment-specific manifests.

• ✗

  Kustomize uses Helm charts with values files per environment for templating.

  Why it's wrong here

  Kustomize is not a templating engine and does not rely on Helm charts or values files. The wrong answer conflates two distinct configuration management tools: Helm uses Go templates plus a values.yaml to inject variables, while Kustomize works directly with raw YAML and composes it using kustomization files. Kustomize expects a base and overlays; it never renders template functions or substitutes values from a chart—it merges actual Kubernetes manifests.

• ✗

  Kustomize requires a separate Git branch per environment where manifests are committed.

  Why it's wrong here

  Kustomize itself has no requirement for separate Git branches per environment; that is a version-control workflow choice rendered unnecessary by the overlay model. All overlays can coexist in the same branch, sharing one common base, with each environment's differences isolated in its own directory. A team might still choose a branch-per-environment strategy for governance, but this is unrelated to how Kustomize merges configurations, and Kustomize does not inspect or depend on Git history.

Go deeper

Related to this question