Your DevOps engineering team is designing a continuous delivery pipeline using Google Cloud Deploy and Skaffold to deploy microservices onto Google Kubernetes Engine (GKE) clusters across development, staging, and production environments. You need to implement declarative configuration management using Kustomize that satisfies the following technical requirements: Maintain common Kubernetes resource specifications (Deployments, Services, ConfigMaps) in a single centralized location to avoid code duplication. Apply environment-specific configuration variances—such as replica counts, CPU/memory resource allocations, namespace assignments, and metadata labels—without mutating common files. Ensure native compatibility with GitOps workflows and continuous delivery rendering stages. How should you structure and configure the Kustomize manifests?

Create a `base/` directory containing common resource manifests declared in a `kustomization.yaml` file, and create dedicated `overlays/{dev,staging,prod}/` directories where each environment's `kustomization.yaml` references `../../base` under `resources` and applies declarative patches and transformers.: ### What the Base and Overlay Architecture Is In **Kustomize**, the **base and overlay pattern** is the standard declarative configuration pattern for managing Kubernetes manifests across multiple targets. The `base/` directory contains standard, environment-agnostic Kubernetes manifests (such as Deployments, Services, and ServiceAccounts) declared inside a `kustomization.yaml` file. The `overlays/` directory contains subdirectories for each deployment target (e.g., `dev`, `staging`, `prod`), each containing its own `kustomization.yaml` referencing the base. ### How It Meets the Requirements - **Single Centralized Base**: Common workload configurations are defined once in the `base/` directory. Updates to shared architecture (such as adding a container port or updating a health check) occur in one place without duplication. - **Environment-Specific Customization**: Overlays modify base manifests using declarative **strategic merge patches**, **JSON 6902 patches**, and built-in transformers (`namespace`, `namePrefix`, `commonLabels`, `replicas`, and `resources`). - **GitOps and CI/CD Compatibility**: Tools like Google Cloud Deploy and Skaffold natively understand Kustomize overlays, generating fully rendered YAML artifacts per target environment during pipeline execution. ### Key Advantages and Capabilities - **DRY (Don't Repeat Yourself) Principles**: Eliminates redundant copy-pasted YAML across environments. - **Template-Free Customization**: Preserves native, valid Kubernetes YAML specifications without template delimiters (`{{ .Values }}`). - **Granular Patching**: Allows precise targeting of fields (such as scaling replica counts or tuning memory limits for production) without altering core specs. - **Auditable Declarative State**: Ensures that the final rendered state is predictable and reproducible via `kustomize build`. ### Why This Is Optimal This directory structure represents the core architectural design pattern of Kustomize. It cleanly isolates shared application architecture from environment-specific configuration drift while providing continuous delivery engines like Cloud Deploy with deterministic, reviewable rendering boundaries.

Kustomize Base Overlays Declarative Configuration Gke | Professional Cloud DevOps Engineer

Kustomize Base Overlays Declarative Configuration Gke

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

Your DevOps engineering team is designing a continuous delivery pipeline using Google Cloud Deploy and Skaffold to deploy microservices onto Google Kubernetes Engine (GKE) clusters across development, staging, and production environments.

You need to implement declarative configuration management using Kustomize that satisfies the following technical requirements:

Maintain common Kubernetes resource specifications (Deployments, Services, ConfigMaps) in a single centralized location to avoid code duplication.
Apply environment-specific configuration variances—such as replica counts, CPU/memory resource allocations, namespace assignments, and metadata labels—without mutating common files.
Ensure native compatibility with GitOps workflows and continuous delivery rendering stages.

How should you structure and configure the Kustomize manifests?

Create a base/ directory containing common resource manifests declared in a kustomization.yaml file, and create dedicated overlays/{dev,staging,prod}/ directories where each environment's kustomization.yaml references ../../base under resources and applies declarative patches and transformers.

Store parameterized Helm chart templates under the base/ directory and execute kustomize build directly against standalone Helm values.yaml files located in each environment directory.

Maintain a single root kustomization.yaml file without overlays, and inject environment differences dynamically at deployment time using Kustomize CLI flags like --set inside the Cloud Deploy pipeline definition.

Create standalone, duplicated directories for dev/, staging/, and prod/ containing full Kubernetes manifests, and use custom shell scripts with envsubst or sed during pipeline execution to inject environment variables.

Professional Cloud DevOps Engineer

Kustomize Base Overlays Declarative Configuration Gke

Related questions